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

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.

Why This Matters for Security Teams

Preserving identity across AI agent calls into AWS is not a logging preference, it is the control that keeps autonomous activity attributable. If an agent can assume a role, chain tool calls, and reach cloud APIs without the originating principal remaining visible, the environment loses the ability to answer who requested what, under which approval, and with which downstream permissions. That is exactly how delegated access turns into unaccountable access.

Current guidance suggests treating the agent as a workload with a traceable identity chain, not as a generic application session. This aligns with the NIST AI Risk Management Framework and the operational lessons in Ultimate Guide to NHIs, where visibility, rotation, and offboarding are foundational. Without that chain, offboarding an agent, investigating a suspicious API call, or proving least privilege becomes guesswork.

NHIMG research shows why this matters: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In practice, many security teams discover identity loss only after an AWS action has already executed, rather than through intentional design of the agent path.

How It Works in Practice

The practical goal is to preserve the originating principal from the first user or system trigger through every agent hop and into AWS authorization. The agent should not “become” the cloud identity in a way that erases provenance. Instead, the identity chain should carry the original actor, the agent workload identity, and the task context, so AWS policy decisions can be evaluated with full context before the action executes.

A common pattern is to separate authentication from authorization. The agent authenticates with a workload identity, such as an OIDC-backed token or SPIFFE-style workload identity, while the original principal is propagated as a verifiable claim, session tag, or request context attribute. AWS-side controls then use that context for policy evaluation, CloudTrail correlation, and conditional access decisions. This is more reliable than static role mapping, because agent behavior is dynamic and goal-driven, not fixed to one access pattern.

• Issue short-lived credentials per task rather than long-lived static keys.
• Propagate the original user or service principal through every agent call.
• Bind authorization to request context, not just to the agent’s base role.
• Log both the agent workload identity and the originating principal for auditability.
• Revoke or expire the task credentials as soon as the workflow ends.

That approach is consistent with the threat patterns described in the OWASP Agentic AI Top 10 and the control focus in CSA MAESTRO agentic AI threat modeling framework. It also reflects the compromise patterns documented in LLMjacking: How Attackers Hijack AI Using Compromised NHIs, where exposed cloud credentials are abused quickly once discovered. These controls tend to break down in long-running multi-agent pipelines that fan out across multiple AWS accounts because context propagation is often lost at service boundaries.

Common Variations and Edge Cases

Tighter identity propagation often increases implementation overhead, requiring organisations to balance traceability against integration complexity. That tradeoff becomes sharper in event-driven systems, where a user request may trigger queues, Lambdas, and agent-to-agent handoffs before AWS is ever called.

Best practice is evolving, and there is no universal standard for this yet. Some teams encode provenance in STS session tags, some pass signed context tokens between services, and others enforce policy at an API gateway or broker before any AWS credential is minted. The important point is consistency: the original principal must remain machine-readable all the way to the AWS decision point.

Edge cases include delegated support workflows, shared service accounts, and agentic systems that call AWS on behalf of multiple tenants. In those environments, preserving identity requires stricter context separation and more granular audit records. The Ultimate Guide to NHIs is especially relevant here, because visibility and offboarding gaps are where identity chains most often fail. Where AWS services do not natively preserve upstream provenance, teams should add an authorization layer in front of the API rather than assume the downstream logs will be sufficient.

In practice, the hardest failures appear when agents cross account boundaries, because the original actor is most likely to disappear during role assumption and asynchronous retries.

Related resources from NHI Mgmt Group

• How should security teams govern machine identity credentials in agentic AI environments?
• How should security teams handle AI agent visibility?
• How should security teams monitor AI agent activity without disrupting developers?
• What is the difference between human identity governance and AI agent governance?