Notifications
Clear all
Topic starter
09/07/2026 1:41 pm
TL;DR: AI agent tool calls into Amazon Bedrock AgentCore can lose caller identity, leaving CloudTrail tied to a shared role and making accountability weak, according to Teleport. The core issue is not execution alone, but the assumption that downstream AWS activity still maps cleanly to a human or stable principal.
NHIMG editorial — based on content published by Teleport: When AI Agents Call AWS, Who Does AWS Think They Are?
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Teleport's analysis of identity propagation for Amazon Bedrock AgentCore →
AgentCore identity propagation: what IAM teams need to fix first?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
09/07/2026 1:45 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AWS agent identity propagation is the missing control in AgentCore
