Topic starter
09/07/2026 1:41 pm
TL;DR: Teleport explains that AI agent tool calls into Amazon Bedrock AgentCore can lose caller identity, leaving CloudTrail tied to a shared role and weakening accountability across AWS actions. The real gap is the assumption that downstream execution still maps cleanly to the initiating principal, which breaks once the agent mediates access.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “When AI Agents Call AWS, Who Does AWS Think They Are?”.
Key questions
Q: What breaks when AgentCore does not propagate caller identity to AWS?
A: The downstream tool and CloudTrail record only the shared execution context, not the initiating principal.
Q: Why does shared-role execution increase risk in delegated AI workflows?
A: Shared-role execution forces multiple callers through the same downstream permission set, which pushes teams toward over-provisioning or blocking legitimate use.
Q: How do security teams know whether agent-mediated AWS access is governable?
A: They should verify that the initiating identity survives into the authorization decision, the tool invocation, and the cloud audit trail.
Practitioner guidance
- Implement end-to-end identity propagation Preserve the original caller identity from authentication through the agent gateway, interceptor, tool function, and AWS API call so downstream telemetry remains attributable.
- Replace shared execution roles with caller-scoped authorization Avoid one generic IAM role for all agent users when the role would blur who invoked the action.
- Validate audit correlation across all three logs Check that session logs, authorization decisions, and CloudTrail records all point to the same initiating principal so investigations do not depend on inference.
Bottom line: AI agent access to AWS becomes hard to govern when the original caller identity disappears between the gateway and the cloud action.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact JWT issuance and header-rewrite flow used to carry identity through AgentCore.
- The interceptor pattern that injects verified identity claims into tool-call arguments.
- The Cedar policy examples used for per-tool authorization decisions.
- The notebook-style setup sequence that demonstrates the full AWS configuration end to end.
👉 Read Teleport's analysis of AWS agent identity propagation in AgentCore →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 1:45 pm
Identity propagation is the control plane for delegated AI access: when an agent mediates AWS actions, the real governance question is whether the initiating principal survives the full path. If that identity drops out at the gateway, downstream permissions become shared, attribution becomes approximate, and audit evidence stops supporting accountability. Practitioners should treat propagated identity as a required control, not an implementation detail.
A few things that frame the scale:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What should teams do when an AI agent accesses AWS on behalf of users?
A: They should require request-time identity propagation, then evaluate each tool call against the caller’s verified roles before execution. That gives downstream functions a principal they can trust and prevents the agent gateway from becoming an anonymous permission broker.
👉 Read our full editorial: AWS agent identity propagation is the missing control in AgentCore