How to Secure Generative AI on AWS: The Audit Log Gap

The security control most teams assume they have when running generative AI on AWS, and don’t, is content-level audit logging. CloudTrail logs an InvokeModel call by default: who called it, when, from where, and which model. It never logs the prompt or the response. The feature that actually captures what was asked and what came back, model invocation logging, is disabled by default in every AWS account until someone explicitly turns it on. Teams who assume “it’s AWS, it’s logged” find out otherwise the first time they need to investigate a prompt injection or a data leak and discover there’s no record of what was actually said.

The Gap Between “Logged” and “Logged the Content”

This distinction is easy to miss because both features sit under the same umbrella and both are real AWS logging capabilities. CloudTrail proves a call happened. It does not, and architecturally cannot, hold the prompt or completion content. Model invocation logging is the separate, opt-in feature that delivers full request and response bodies to CloudWatch Logs or S3, including the IAM principal’s ARN, for every Converse and InvokeModel call. Until an administrator explicitly enables it and wires up the destination and IAM role, that content simply doesn’t exist anywhere in your account.

There’s a second coverage gap worth knowing even after you enable it: calls made through certain newer API surfaces, including Bedrock’s Mantle endpoint, aren’t captured by model invocation logging at all and require their own separate CloudTrail data-event configuration to produce any record. A security review that confirms invocation logging is “on” without checking which API surfaces your application actually calls can still leave a real gap in coverage.

Why This Isn’t a Turn-It-On-and-Done Fix

The logs you enable become a sensitive asset themselves

Enabling model invocation logging doesn’t just solve a visibility problem, it creates a new one. These logs contain pre-guardrail content, the raw user input before any content filter or PII redaction ran, which means the log bucket itself is now one of the most sensitive artifacts your application produces. Treat it accordingly: encrypt with a customer-managed KMS key, restrict read access with a tiered reader model rather than blanket access, and consider a tool like Amazon Macie over the bucket to catch sensitive data landing in logs that weren’t supposed to carry it. A security team that enables invocation logging and leaves the resulting S3 bucket under a default access policy has traded one risk for a different one.

Guardrails are non-deterministic, which makes the log your only real evidence

AWS is explicit that Guardrails are non-deterministic and context-dependent, meaning the same input may or may not trigger enforcement across separate invocations. That’s a genuinely important design fact: you cannot architect a security posture that assumes a guardrail will catch a given input consistently every time. What you can do is make sure the interaction is captured, so that when a guardrail does or doesn’t fire, you have the content record needed to understand why, after the fact, rather than guessing. The content log and the guardrail are complementary controls, not redundant ones, and treating the guardrail as sufficient on its own, without the log to verify its behavior, leaves a real investigative blind spot.

The IAM Permissions That Matter More Than Broad Invoke Access

Most IAM reviews for Bedrock focus on scoping bedrock:InvokeModel to specific model ARNs, which is necessary but not sufficient. A smaller, more consequential set of permissions deserves separate scrutiny: UpdateAgent, UpdatePrompt, UpdateGuardrail, DeleteGuardrail, CreateAgentActionGroup, and UpdateFlow. Each of these lets a holder rewrite agent behavior, weaken or remove guardrail enforcement, or attach a malicious tool executor, all without deploying any new code. These permissions should never sit on an application’s runtime role. They belong exclusively to a CI/CD deployment role with its own tight conditions, separate from whatever identity your application assumes to actually serve traffic. A role that can both invoke the model and silently delete the guardrail protecting that invocation has a combined risk profile worse than either permission alone.

The Rollout Checklist

Enable model invocation logging before go-live, not after your first incident, and verify coverage across every API surface your application actually calls, not just the ones the console highlights by default. Keep CloudTrail’s metadata trail and your content-logging pipeline as two separate systems with separate retention and access policies, since they answer different questions and get audited differently. Encrypt the content logs with a customer-managed KMS key and apply a tiered reader model rather than broad access. Enforce guardrail usage through the IAM condition key that denies any invocation lacking an approved guardrail identifier, turning the guardrail from a best-effort application convention into a control IAM actually requires. And keep the handful of permissions that can rewrite agent behavior or disable guardrails entirely out of runtime roles, reserved for a narrowly scoped deployment identity instead.

At SIRAYA, the pattern that shows up most often in post-incident reviews isn’t a missing Guardrail or an over-permissive invoke policy, though both happen. It’s a security team confident their generative AI application is “logged” because CloudTrail shows activity, discovering only during the investigation that nobody ever turned on the one feature that would have told them what was actually said.