TL;DR: AWS IAM Identity Center now lets a server-side application exchange a user’s OIDC token for that user’s AWS access, which breaks non-repudiation because actions are logged as the human even when an app initiated them, according to Clutch Security. This is not a short-lived credential win if the app inherits human identity instead of acting as itself; lineage, scope, and accountability all collapse at once.
At a glance
What this is: This analysis says AWS IAM Identity Center’s on-behalf-of flow makes a server-side application act as a human, which severs attribution and weakens auditability.
Why it matters: IAM and PAM teams should treat impersonation as an identity design failure, because audit logs, segregation of duties, and incident response all depend on clear actor identity.
Context
AWS IAM Identity Center now allows a server-side application to exchange a user’s OIDC token for that user’s AWS access and act in AWS as that person. In plain terms, the application does not merely borrow authorization, it inherits the human identity for the session, which changes how access is logged and attributed.
The governance problem is not short-lived credentials themselves. The problem is that the application stops being a distinct principal, so the environment loses a clean boundary between human and non-human identity. That boundary is what makes least privilege, non-repudiation, and forensic reconstruction workable in practice.
Key questions
Q: What breaks when AWS impersonation lets an application act as a human identity?
A: The failure is attribution. Once the application inherits the human’s AWS access, logs can show a user action even when software initiated it, which undermines non-repudiation, forensics, and separation of duties. The practical test is whether your platform can prove which principal executed the action without guessing from timestamps or correlation fields.
Q: Why does on-behalf-of access create audit and accountability risk?
A: Because it merges two different actors into one recorded identity. The human may have approved the task, but the application executed it, and if the platform cannot preserve both identities end to end, the log stops being reliable evidence. That matters most when you need to defend an incident report or reconstruct privilege use.
Q: What are the signs that delegated agent access is failing governance?
A: Common signs include missing provenance, broad permissions that outlast the task, and audit records that show what happened but not who effectively authorised it. If reviewers must reconstruct the originator, agent and target from separate logs, the governance model is already too weak for agentic workflows.
Q: Should teams treat short-lived credentials and impersonation as the same control?
A: No. Short-lived credentials can improve security when they are tied to a distinct workload identity, but impersonation copies the human identity into the session and erases actor separation. The better question is whether the application can federate as itself and keep its own scope, because that is what preserves governable access.
Technical breakdown
How AWS impersonation changes principal identity in CloudTrail
The feature creates a split identity trail: the first token exchange is recorded against the application principal, but the downstream access and role credentials are attributed to the human user. That means the platform preserves neither a consistent workload identity nor a durable chain from app to action. The onBehalfOf field helps only partially because it still names the human, not the application that initiated the sequence. In governance terms, the system converts a distinct non-human executor into a shadow of the human account, which is the opposite of attributable machine identity.
Practical implication: treat any flow that merges application activity into a human principal as a logging and attribution defect, not just an access convenience.
Why impersonation is not least privilege for non-human identities
Least privilege has to be defined by task and principal. Here, the application inherits the user’s full access ceiling, including whatever roles that user can reach across accounts, so the app’s effective scope becomes the maximum privilege of whoever logs in. That is not workload-scoped authorisation, it is delegated human privilege with an ephemeral wrapper. The app cannot be constrained below the user’s rights through the native feature, so the policy boundary moves from a controllable service identity to an uncontrolled human session.
Practical implication: keep service-specific roles separate from human access and reject any design where the app’s authority is derived only from the user’s entitlement set.
Why the audit trail cannot prove who actually acted
Non-repudiation requires that actions be attributable to a single accountable actor. In this model, CloudTrail can show an app-related token exchange, then user-attributed access, but the critical handoff to effective AWS credentials is not durably linked to the originating application. That breaks the evidentiary chain needed for investigation, compliance, and dispute resolution. Once the live credential exists, subsequent activity looks like ordinary human action, even if a service or agent initiated it. The log is no longer an honest witness to actor identity.
Practical implication: require identity models that preserve app provenance end to end, or accept that your audit evidence will not withstand attribution challenges.
Threat narrative
Attacker objective: The objective is to perform AWS actions under a human’s identity while hiding the true initiating actor from audit and incident review.
- Entry occurs when a server-side application receives a user’s OIDC token and exchanges it for AWS access under the human’s identity.
- Escalation follows because the resulting session inherits the full access available to that user, including broad account and role reach.
- Impact is the loss of non-repudiation, since CloudTrail records actions as the human even when the application initiated them.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity inheritance across an application boundary breaks the governance model. A human identity is meant to describe a person, while a service identity is meant to describe software acting within a task boundary. When AWS lets an application act as the user, the system collapses those categories and makes accountability dependent on inference instead of principal separation. The practitioner implication is that identity architecture must preserve actor type, not merely deliver access.
Non-repudiation is a control property, not an audit afterthought. If the log cannot prove whether a person or a workload performed the action, then the control failed before the investigation began. That failure matters across IAM, PAM, and NHI governance because evidence quality is part of the security model, not a downstream reporting issue. Practitioners should treat actor attribution as a first-class design requirement.
Ephemeral credentials are only useful when the workload remains a distinct principal. Short-lived access reduces exposure, but only if it is bound to a workload identity with its own scope and trail. Once the workload borrows the human’s identity, the boundary that makes ephemeral access governable disappears. The lesson is that credential lifetime and principal identity are separate controls, and both have to hold.
On-behalf-of semantics need a named governance concept: attribution collapse. The feature preserves access while removing the reliable link between initiator, credential, and action. That is not a minor logging gap, it is an identity governance failure mode that complicates incident response, compliance review, and separation-of-duties enforcement. Practitioners should classify it as a control boundary violation, not as a convenience feature.
Workload identity should remain auditable even when humans trigger it. Human initiation of an automated task is not the same thing as human execution of that task. The boundary must stay visible so the organisation can answer who approved the action, which workload performed it, and what scope that workload was allowed to use. That distinction is essential for governed automation.
From our research library:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Attribution collapse: This feature shows how an access model can remain technically functional while becoming operationally ungovernable. When the application disappears behind the human principal, the organisation loses the ability to answer the most basic question in an incident: who actually acted?
The immediate programme impact is on IAM and PAM design, not just AWS configuration. Teams should separate human approval from machine execution, because once the workload inherits user identity the audit model can no longer distinguish delegated action from direct human action.
For practitioners
- Preserve separate service principals Give internal applications their own IAM roles and policies so they remain distinct actors in CloudTrail and in your access reviews.
- Classify impersonation as a high-blast-radius pattern Treat any flow where an application can inherit a user’s AWS access as a design exception that needs explicit governance review and compensating controls.
- Require app provenance in telemetry Add application identity to logs, user-agent strings, and correlation fields so incident responders can trace which workload initiated a session.
- Separate human approval from workload execution Where humans trigger automation, keep the workload’s identity, scope, and audit trail independent from the approver’s account.
Key takeaways
- This AWS pattern collapses the boundary between human and application identity, which is why non-repudiation and auditability fail together.
- The core issue is not ephemeral access by itself, but ephemeral access bound to the wrong principal, so the log cannot preserve actor provenance.
- Teams that rely on delegated AWS access need separate workload identities, or they will not be able to defend attribution in investigations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The feature blurs authentication between the human and the application acting on their behalf. |
| NHI-10 — Human Use of NHI | The article shows a human identity being used as the execution vehicle for software actions. | |
| Recommendation — Preserve separate authentication for applications so the workload never inherits the user’s identity. Keep humans and workloads on separate principals so automated actions remain attributable. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The risk centers on how access tokens and exchanged credentials are managed and attributed. |
| Recommendation — Apply IA-5 to govern token exchange paths and prevent shared attribution across principals. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The application inherits the user’s full entitlements instead of a task-scoped authorisation set. |
| Recommendation — Align entitlements to task-scoped authorisation so a workload never inherits a user’s full permissions. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The sequence turns a token exchange into broad account reach and action under a human label. |
| Recommendation — Map delegated AWS access flows to credential access and lateral movement to spot privilege expansion. | ||
Key terms
- Non-Repudiation: Non-repudiation is the ability to prove what an identity did, when it did it, and under what authority. For autonomous agents, that evidence must include context, approvals, and tool usage so later review can reconstruct the decision path.
- Impersonation: Impersonation is a controlled administrative action that lets an authorised operator assume a user context for debugging or support. In a well-governed setup it preserves audit logging, limits exposure of credentials, and keeps production authentication separate from local troubleshooting.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Attribution Collapse: Attribution collapse occurs when shared credentials and poor logging make it impossible to determine which individual performed an action. In identity governance, this undermines investigation, accountability, and compliance because the organisation can no longer tie behaviour to a specific user or approved purpose.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.
Published by the NHIMG editorial team on July 22, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org