AWS Bedrock AgentCore security patterns can help reduce a common risk in enterprise AI agents: an agent that can reach more data than the requesting user should be allowed to access.
In an August 2026 reference architecture, AWS demonstrates how to propagate end-user authorization context from Amazon Cognito through Amazon Bedrock AgentCore to downstream services such as DynamoDB, Amazon Bedrock Knowledge Bases, and Salesforce. The central design principle is simple: the agent should orchestrate work, but downstream systems should make the access-control decision.
Why User-Aware Authorization Matters for AI Agents
AI agents often connect to databases, document stores, SaaS platforms, and internal APIs. If every request is executed with one broad service identity, the agent may be technically capable of reaching data that the human requester is not entitled to see.
That becomes especially important when the agent behaves unexpectedly because of prompt injection, malicious tool output, software bugs, or bad reasoning. AWS recommends moving authorization decisions out of the model’s reasoning path wherever possible and enforcing them with IAM, database controls, or the downstream SaaS platform.
This does not make prompt injection harmless. It narrows the potential impact by reducing what the agent can successfully access when downstream controls are correctly configured.
How AgentCore Carries the User Identity
In the AWS example, a user authenticates through an Amazon Cognito user pool. A pre-token-generation Lambda trigger enriches the user’s JSON Web Token with authorization context such as department information and AWS session-tag metadata.
The application sends the access token with the user’s request to an agent running on Amazon Bedrock AgentCore Runtime. AgentCore Runtime validates the inbound JWT, while AgentCore Identity issues a workload access token that binds the user and agent identities before the agent is invoked.
Three Authorization Patterns AWS Demonstrates
| Downstream service | User-context pattern | Where access is enforced |
|---|---|---|
| Amazon DynamoDB | AssumeRoleWithWebIdentity with session tags | IAM ABAC policy |
| Bedrock Knowledge Bases | Department-scoped metadata filtering | Application-layer retrieval filter |
| Salesforce | RFC 8693 on-behalf-of token exchange | Salesforce sharing rules |
DynamoDB: Temporary, User-Scoped AWS Credentials
For DynamoDB, AWS demonstrates per-request credentials using AssumeRoleWithWebIdentity and session tags. IAM attribute-based access control can then evaluate the user’s attributes when deciding which partition keys or records the request is allowed to reach.
Knowledge Bases: Metadata Filtering Is Still Application-Layer Control
A useful nuance in the AWS architecture is that not every downstream service offers the same level of infrastructure-enforced authorization. For Amazon Bedrock Knowledge Bases, the example applies department metadata filters when retrieving documents.
AWS presents this as a complementary application-layer control, not as equivalent to an IAM policy that independently rejects an unauthorized request. Teams should therefore treat retrieval-filter construction and testing as security-sensitive application logic.
Salesforce: On-Behalf-Of Token Exchange
For external SaaS access, AgentCore Identity can retrieve the required credential material and perform an OAuth 2.0 token exchange using the RFC 8693 on-behalf-of pattern. The resulting token is scoped to the user, and Salesforce applies its native sharing rules when returning records.
What This Architecture Does Not Guarantee
- It does not eliminate prompt injection. A manipulated agent may still make harmful requests; authorization controls limit which of those requests succeed.
- It does not make broad IAM permissions safe. If the user-scoped role is still overprivileged, the agent can inherit that excessive access.
- It does not make every data source infrastructure-enforced. AWS explicitly uses application-layer metadata filtering for Knowledge Bases in this reference design.
- It does not remove the need for logging and monitoring. Teams still need visibility into identity, tool calls, downstream API activity, and credential use.
This distinction matters because security architecture should reduce blast radius rather than promise that a compromised or manipulated agent can never cause harm.
Newer AgentCore Identity Work Also Focuses on OAuth Consent
AWS has continued expanding AgentCore Identity. In September 2026, AWS documented managed end-user OAuth consent and session binding for three-legged OAuth integrations such as GitHub and Slack. That reduces the amount of custom callback and session-binding infrastructure teams need to build when an agent must act on a user’s behalf.
The same security principle applies: the agent should use credentials that are bound to the user and purpose of the request rather than one reusable, broadly privileged token.
Practical Security Checklist for AgentCore Deployments
- Validate the caller identity at the runtime boundary.
- Propagate authorization attributes such as department, role, business unit, or region only from trusted identity sources.
- Prefer short-lived, user-scoped credentials instead of long-lived shared secrets.
- Enforce access downstream with IAM ABAC, database controls, or SaaS-native sharing rules wherever possible.
- Treat metadata filters as application security logic when the downstream service cannot independently enforce the boundary.
- Log identity and authorization decisions so incident responders can determine who requested what and which downstream service approved it.
- Review the agent’s execution role and avoid granting direct broad data-store access simply for convenience.
The need for strong identity boundaries becomes even more important as attackers automate credential theft and cloud abuse. See our analysis of AI agents harvesting cloud credentials and our report on OpenAI AI agent security incidents involving exposed API keys and unauthorized actions.
Runtime Security: MMDSv2, Execution Roles and Secret Handling
AWS’s current AgentCore Runtime guidance adds another important layer to the authorization model: the runtime itself should be treated as a security boundary. AgentCore Runtime exposes temporary execution-role credentials through the MicroVM Metadata Service (MMDS), so any code running inside the microVM can potentially request those credentials.
That makes the execution role a critical blast-radius control. AWS recommends scoping it to only the actions and resources the agent actually needs rather than using broad managed policies in production.
- Use AgentCore Identity for outbound authentication: keep third-party OAuth credentials and API keys out of agent code and logs where possible.
- Require MMDSv2: AWS requires AgentCore Runtime deployments to use MMDSv2; runtimes without it enabled cannot be invoked.
- Minimize execution-role permissions: code inside the runtime can access role credentials, so excessive IAM permissions directly increase the damage a compromised agent could cause.
- Run custom containers as non-root: AWS recommends non-root container users for custom runtime images.
These controls complement user-context propagation. User-aware authorization limits what the requester is allowed to reach, while runtime least privilege limits what the agent process itself can do if it is manipulated or compromised.
Avoid Full-Access Policies in Production
AWS documents BedrockAgentCoreFullAccess for broad service access, but its own guidance recommends replacing broad managed permissions with custom least-privilege policies for production workloads. AWS also warns that some full-access permissions can issue workload access tokens using caller-supplied user identifiers without identity-provider token verification.
For production applications that already have JWTs, AWS recommends restricting token issuance to the JWT-validated flow and denying broader token-generation paths that are unnecessary for the application.
Bottom Line
AWS Bedrock AgentCore does not “stop” a hijacked AI agent by itself. The stronger pattern is defense in depth: keep authorization decisions outside the model, scope execution-role permissions tightly, protect outbound credentials with AgentCore Identity, and enforce access again in downstream systems.
AWS’s reference architecture propagates end-user context and uses temporary credentials, IAM policies, retrieval filters, and SaaS-native authorization so access is tied more closely to the requesting user. That can materially reduce the blast radius of prompt injection, software bugs, or unexpected agent behavior when the controls are implemented correctly.
Official Sources
- AWS Security Blog: Propagate user authorization context in AI agents with Amazon Bedrock AgentCore
- AWS: Manage end-user OAuth consent for AI agents with Amazon Bedrock AgentCore
- AWS: Security best practices for AgentCore Runtime
- AWS: IAM permissions for AgentCore Runtime
Frequently Asked Questions
Can prompt injection bypass infrastructure-level authorization?
Prompt injection can influence what an agent tries to do, but correctly configured downstream authorization can prevent requests that exceed the requesting user’s allowed access. This limits blast radius rather than eliminating prompt-injection risk.
Does AgentCore use one authorization mechanism for every data source?
No. AWS demonstrates different patterns: IAM ABAC for DynamoDB, metadata filtering for Knowledge Bases, and on-behalf-of OAuth token exchange plus Salesforce sharing rules for external SaaS access.
Should the agent’s IAM role have direct broad access to data stores?
AWS’s reference architecture is designed to avoid relying on one broadly privileged agent identity. Instead, it propagates user context and uses temporary, scoped credentials or downstream authorization controls.
