AWS agent identity propagation is the missing control in AgentCore

At a glance

What this is: This is an analysis of how AI agent calls to AWS through AgentCore can drop caller identity and flatten accountability into a shared role.

Why it matters: It matters because IAM, PAM, and NHI teams need a way to preserve identity context across agent tool chains, or else access reviews, audit trails, and offboarding controls stop mapping to the real actor.

👉 Read Teleport's analysis of identity propagation for Amazon Bedrock AgentCore

Context

AI agent identity propagation is the control gap this article exposes. When a user asks an agent to perform an AWS action, the request can traverse MCP tooling, a managed gateway, a Lambda, and then AWS APIs, yet the downstream system may still only see a generic execution role rather than the originating principal.

That matters for both NHI governance and human IAM. If the chain does not preserve identity context, auditability collapses, least privilege becomes coarse-grained, and offboarding a person does not necessarily revoke the effective access their agent path still exercises.

Key questions

Q: How should security teams preserve identity across AI agent calls into AWS?

A: Security teams should propagate the originating principal through the full agent request path, then enforce policy before the AWS action executes. The key is to keep identity visible from login to cloud API so authorization, logging, and offboarding all reference the same actor. A verified identity chain is the difference between governed automation and unaccountable access.

Q: Why do shared roles become a problem in agentic AWS workflows?

A: Shared roles collapse many users into one execution identity, which forces broad permissions and weakens accountability. In agentic AWS workflows, that means CloudTrail and authorization records may no longer identify the real requester. Teams should treat role sharing as a temporary exception, not the default operating model, especially for sensitive tool paths.

Q: What breaks when identity is dropped between an agent and the cloud service?

A: The audit trail breaks first, then least privilege becomes approximate, and finally offboarding loses precision because downstream access no longer maps cleanly to a person. Once identity is stripped from the request, the organisation can still see that something happened, but not confidently who caused it or whether they should still have access.

Q: Who is accountable when an AI agent performs an AWS action under a shared role?

A: Accountability sits with the organisation that designed the delegation chain, because the shared role is a governance choice, not a technical accident. The accountable teams are usually IAM, platform engineering, and the business owner of the workflow. If the role cannot be tied back to a principal, the control design is incomplete and the record is weak.

Technical breakdown

Why identity must survive the MCP to AWS request chain

The problem is identity loss across delegation boundaries. A user authenticates, an agent invokes a tool, the tool reaches AgentCore, and AWS receives the call under infrastructure identity unless caller context is explicitly propagated. That leaves the gateway able to validate a request structurally while downstream services still cannot tell which principal initiated the action. In identity terms, this is a broken trust chain, not just a logging issue. Without context preservation, authorization becomes detached from accountability and policy evaluation happens too late in the flow.

Practical implication: preserve caller identity as a first-class parameter before the AWS API call is made.

Why shared roles and dropped claims create audit blind spots

A shared IAM role for all agent users compresses distinct principals into one execution identity. CloudTrail then records the role or service path, not the person behind the request, which makes investigations and access reviews far less precise. This is especially problematic when multiple people use the same agent path but have different entitlements. The operational failure is not that AWS cannot log activity, but that the log no longer answers the accountability question. Identity propagation is what turns a tool invocation into a traceable user action.

Practical implication: avoid relying on one role for all users when the downstream activity has security or compliance significance.

How interceptor-mediated authorization changes tool access control

The article describes a pattern where the gateway validates a JWT, then an interceptor reuses the verified claims to evaluate tool-level policy before the Lambda runs. That creates a clean separation between authentication, authorization, and execution. In practice, this means the agent tool does not need to trust a loose session context or infer identity from infrastructure metadata. Instead, the authorization decision is tied to a verified caller identity and a specific tool request, which is the only defensible pattern when agents sit in the middle of enterprise workflows.

Practical implication: enforce per-tool authorization before execution rather than trying to reconstruct identity after the fact.

NHI Mgmt Group analysis

Identity propagation, not just access control, is the decisive control plane for agent-to-cloud workflows. The article shows that an AI agent can invoke AWS actions through AgentCore while the downstream platform loses the human principal behind the request. That is a governance failure because access review, incident investigation, and offboarding all depend on durable identity context. Practitioner conclusion: if the chain cannot carry identity, the control model is incomplete.

Shared execution roles create identity blast radius in agentic AWS designs. When all users execute through the same role, privilege has to be set for the most capable user or the most dangerous action, which is the opposite of least privilege. This is a classic NHI governance problem even when the front end is human initiated. Practitioner conclusion: role sharing across agent paths should be treated as a structural exception, not a normal design choice.

Caller identity must be preserved across the request path or the audit trail becomes advisory only. CloudTrail, session logs, and authorization logs are only useful when they can be correlated back to a single actor with confidence. Without that, the programme can record events but cannot explain who actually exercised access. Practitioner conclusion: correlation design is part of identity architecture, not a post-incident reporting feature.

Identity-aware agent governance now spans human IAM and NHI controls in one flow. The user is human, the execution path is non-human, and the policy boundary sits between them. That means IAM, IGA, and NHI teams cannot operate as separate silos when AI agents mediate cloud access. Practitioner conclusion: model the agent path as a governed identity delegation chain, not as a simple API integration.

Telemetry without verified identity is not sufficient for accountable autonomy. Even when a platform can observe requests, the inability to bind those requests to a verified caller weakens the usefulness of both policy and evidence. That gap becomes more serious as agent use expands into sensitive AWS operations. Practitioner conclusion: design for attributable execution before expanding agent permissions.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• For a practical framework on governing this exposure, see OWASP Agentic Applications Top 10, which maps the control failures behind agent scope drift and tool misuse.

What this signals

Identity propagation is becoming a programme design issue, not just an implementation detail. As agent-mediated access expands, teams will need to treat verified caller context as part of the control surface for AWS, not as an optional audit enhancement. The immediate implication is that access reviews, logging strategy, and offboarding checks must all follow the same delegation chain, including the agent path.

With 52% of companies able to track and audit the data their AI agents access, the other 48% have a compliance blind spot that will not be solved by generic cloud logging. The control gap is not visibility in the abstract, but attributable visibility across identity hops. Teams should watch for drift between what the gateway validated and what the downstream service actually recorded.

Caller identity continuity is the named concept this pattern forces into view. It describes the requirement that an authenticated principal remain traceable through every tool call, policy check, and cloud execution step. In practical terms, programmes that cannot preserve caller identity continuity will keep producing logs without producing accountability.

For practitioners

• Carry verified caller identity through every agent hop Propagate the originating principal from login through the agent, gateway, Lambda, and AWS API call so downstream logs remain attributable to one actor. The goal is end-to-end identity continuity, not just authenticated entry.
• Eliminate shared execution roles for sensitive agent workflows Assign access based on the initiating principal or a tightly scoped role mapping, rather than letting all users run through the same IAM role. Shared roles force over-provisioning and make offboarding ineffective.
• Authorize tool calls before Lambda execution begins Use a pre-execution policy decision point so the tool is denied before it can touch AWS resources. If policy is evaluated after the call starts, the audit trail may remain clean while the blast radius still grows.
• Correlate session logs, authorization logs, and CloudTrail Build an investigation path that links the human session, the policy decision, and the cloud action into one record set. Without that correlation, identity evidence becomes fragmented across three systems.
• Review offboarding for agent-enabled access paths When a user leaves, revoke not only interactive access but also any agent path that still allows their former role or claims to trigger AWS activity. Offboarding has to follow the delegation chain, not just the login account.

Key takeaways

• Agentic AWS workflows fail governance tests when the downstream service cannot tell which principal initiated the request.
• The strongest evidence in the source points to a simple problem with large consequences: shared roles and dropped identity claims erode auditability, least privilege, and offboarding precision.
• Teams should treat identity propagation as a prerequisite for agent-to-cloud access, not a refinement added after deployment.

Key terms

• Identity Propagation: Identity propagation is the practice of carrying a verified caller’s identity through each system in a request chain. In agentic workflows, it prevents downstream services from seeing only shared infrastructure identity and makes authorization, logging, and offboarding trace back to the real actor.
• Caller Identity Continuity: Caller identity continuity means the originating principal remains traceable from login through every intermediate tool, gateway, and cloud service. It is the control property that keeps audit evidence, access decisions, and incident response aligned to one accountable actor rather than a generic execution role.
• Delegation Chain: A delegation chain is the sequence of identities and systems that act between the original requester and the final cloud action. In AI agent workflows, the chain can include a person, an agent, a gateway, an interceptor, and a cloud role, and each link must preserve accountability.
• Identity Blast Radius: Identity blast radius is the amount of access or impact created when multiple users or workflows are collapsed into one execution identity. The larger the blast radius, the more likely over-provisioning, weak audit trails, and ineffective offboarding become in agentic and NHI programmes.

What's in the full article

Teleport's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step AgentCore configuration for OIDC validation against Teleport identity claims.
• Example interceptor logic that injects verified user context into tool invocations.
• Cedar policy examples that map roles to specific AWS tool permissions.
• A working notebook sequence that shows the identity chain from login to CloudTrail.

👉 Teleport's full post covers the AWS request chain, interceptor pattern, and audit correlation details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.