The downstream tool and CloudTrail record only the shared execution context, not the initiating principal. That breaks accountability, makes authorization decisions harder to defend, and leaves no reliable way to distinguish one user’s action from another’s when the same agent path serves multiple callers.
When shared execution context breaks accountability
When AgentCore does not pass the caller’s identity through to AWS, the agent and the platform collapse multiple callers into one execution context. That means the AWS-side action trail can show what happened, but not who initiated it, which weakens attribution, makes approvals harder to validate, and complicates incident reconstruction when a single agent path serves many users.
A useful way to think about the failure is that identity is no longer preserved across the trust boundary. The downstream service can still receive a valid request, but the request is detached from the original principal. In practice, that removes the evidence you need to answer basic audit questions such as whether the action was user-driven, system-driven, or shared across sessions.
That is why caller propagation is not just a logging preference. It determines whether the system can distinguish delegation from impersonation, and whether downstream authorization decisions can be defended as user-specific rather than agent-wide. Without that distinction, shared credentials or shared runtime roles become a single blast radius for many callers.
Why AWS logging and authorization become harder to trust
AWS controls and logs are only as useful as the identity context they receive. If the initiating principal is lost, CloudTrail and downstream tool logs can preserve the action but not the human or upstream agent accountable for it. That weakens non-repudiation, complicates forensic correlation, and can make access reviews or exception handling look more permissive than intended.
This is especially important where the same agent path is used for different users, tenants, or requests. In that pattern, the shared execution role may still be legitimate, but it is no longer sufficient to explain decision-making at the request level. The operational issue is not that AWS stops working, it is that the security story becomes ambiguous.
For agentic systems, that ambiguity often shows up as overbroad trust in the runtime instead of in the caller. AI Agent Observability, Audit and Incident Response Guide is useful here because attribution, traceability, and kill-switch design all depend on preserving the caller context that the AWS side needs to distinguish one action from another.
What a defensible propagation pattern needs to preserve
Caller propagation should preserve the initiating principal, the delegated actor, and the execution context as separate concepts. The point is not to duplicate the user’s credentials everywhere, but to carry enough trustworthy identity context that AWS-side logs, policies, and reviews can reconstruct who asked for the action and under what delegation rule it ran.
That is why request-level identity propagation matters more than a generic shared role. A shared role may still be acceptable for the agent runtime, but the system needs an auditable link back to the caller. When that link is missing, downstream authorization becomes coarse, because policy can only see the agent, not the specific caller or approval state behind the action.
For design guidance, the right control objective is to make the caller visible at the point where authority is consumed. AI Agent Authorisation Guide fits that model because it centres task-scoped access, per-action decisions, and delegated authority rather than unconditional use of a shared execution context.
Risk and Threat Considerations
When caller identity is stripped before AWS sees the request, the main risk is not only weaker auditability, it is also privilege ambiguity. A malicious or careless caller can hide behind a shared agent path, making it harder to separate legitimate automation from abuse, especially when the same runtime can act for many users.
Failure mechanism: the system authenticates the agent runtime but fails to preserve the upstream principal, so logs, policy evaluation, and investigation all resolve to the same shared identity instead of the initiating caller.
Impact: responders lose reliable attribution, authorization decisions become harder to defend, and a single compromise or misuse event can appear indistinguishable from normal agent traffic until deeper correlation work is done.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Caller propagation affects whether events can be tied to the initiating principal. |
| IA-2 — Identification and Authentication (Organizational Users) | The question turns on preserving authenticated caller identity into AWS. | |
| AC-6 — Least Privilege | Shared execution context can expand effective privilege beyond the caller’s intent. | |
| Recommendation — Log the initiating principal so downstream events remain attributable across the trust boundary. Preserve authenticated caller identity through the agent path rather than collapsing to one shared actor. Bind downstream access to the caller’s delegated authority, not the agent’s broad runtime role. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and services | Caller identity propagation is an identity governance and auditability issue. |
| DE.CM-09 — Network and physical environment events are monitored | Preserving identity context improves monitoring and investigation of downstream actions. | |
| Recommendation — Ensure caller identity remains auditable from issuance through downstream use. Correlate downstream events to the initiating principal in monitoring and response workflows. | ||
Practitioner Guidance
What to verify: Confirm that the identity reaching AWS is the one you expect to use for authorization and audit, not just the identity used by the agent process. If the same agent can serve multiple callers, require a request-scoped correlation path that survives into AWS-side logs and reviews.
Common mistake: Treating a valid shared execution role as sufficient evidence of control. That may be operationally convenient, but it is not enough for accountability if the action cannot be tied back to the initiating principal.
What good looks like: A reviewer can trace an action from caller to agent to AWS event without guessing which user initiated it, and an exception or incident review can separate shared runtime authority from per-request caller intent.
Practitioner takeaway: If caller identity is not propagated, the system may still execute correctly, but it stops producing security evidence strong enough to defend who was actually acting.