AWS identity center impersonation breaks non-repudiation and auditability

At a glance

What this is: AWS Identity Center now allows server-side applications to act in AWS as the signed-in user, creating an impersonation model that weakens attribution and auditability.

Why it matters: IAM, PAM, and NHI teams need to treat this as a governance boundary problem because human and non-human actions become indistinguishable in logs and access scope.

By the numbers:

• 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.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read Clutch Security's analysis of AWS impersonation and non-repudiation

Context

Non-human identity governance fails when a system can act under a human principal instead of under its own workload identity. In this case, the key issue is not just federation or short-lived access, but the loss of a clean line between who initiated the action and what identity actually executed it. That makes AWS identity center impersonation an IAM and NHI governance problem, not a convenience feature.

The practical risk is that audit trails become ambiguous at the exact moment they need to be reliable. If applications can inherit a user’s permissions and leave logs that read as human activity, security teams lose the ability to separate service behavior from user behavior. That is atypical only in its packaging; the underlying trust failure is a familiar one in identity programmes that over-privilege shared or delegated access.

Key questions

Q: What breaks when applications can act as human users in AWS?

A: Non-repudiation breaks first, followed by clean attribution and workload-level least privilege. If an application can inherit a human principal, logs say a person acted even when a service drove the action. That makes incident response, audit evidence, and separation of duties much harder to defend.

Q: Why is user-borrowed access risky for cloud workloads?

A: Because the service’s effective permissions become whichever entitlements the user already has, rather than the permissions the task actually needs. That turns a workload into an extension of human privilege and expands blast radius whenever the user is over-privileged.

Q: How do security teams know whether delegated access is actually governable?

A: Look for a distinct workload identity, a separate role, and a durable event trail that preserves which application initiated the action. If the platform cannot distinguish the service from the human in logs, the delegation model is not governable at investigation time.

Q: Who is accountable when an application acts on behalf of a user?

A: The organisation is accountable for the access design, but operational accountability becomes unclear if the platform suppresses the application’s identity. That is why cloud identity models must preserve actor separation: without it, accountability shifts from evidence to inference.

Technical breakdown

Why human impersonation breaks non-repudiation in AWS

Non-repudiation depends on two properties: the action must be attributable to a specific principal, and that principal must be the actual executor. When an application exchanges a user token and then operates as that user, the platform records a human identity even though the runtime actor is a server-side service. That destroys forensic integrity because the credential path no longer preserves the distinction between initiator, broker, and executor. The problem is not that federation exists. The problem is that the application does not remain visible as a separate identity with its own scope and audit chain.

Practical implication: keep application principals distinct from human principals so logs preserve a defensible attribution chain.

Why scope follows the user instead of the workload

Least privilege only works when scope is bound to the task, not to the most privileged human who happens to authenticate. In this model, the application inherits whatever access the user already has, which means the effective blast radius is determined by human entitlements rather than service purpose. That is fundamentally different from workload identity, where the service has a defined role, bounded permissions, and an auditable lifecycle. Without application-specific scoping, the platform is delegating authorization design to the end user’s privilege level.

Practical implication: define role scope for the service itself, not for the user who launches it.

Why prompt injection becomes harder to contain when identity is borrowed

A confused deputy becomes more dangerous when it can act under a human’s credentials. If an application consuming untrusted input is steered by prompt injection or malicious content, it may execute actions that appear to originate from the user, not the app. That removes an important containment boundary because revocation, monitoring, and blame all become less precise. In NHI governance terms, the issue is not only access misuse. It is the collapse of actor separation that normally lets teams contain runtime abuse at the workload layer.

Practical implication: treat user-borrowed application sessions as high-risk and isolate them from privileged workflows.

Threat narrative

Attacker objective: The objective is to execute cloud actions while preserving plausible deniability by making those actions look like they were performed by a human user.

1. entry: A server-side application receives a user’s OIDC token and exchanges it for AWS access under that user’s identity.
2. escalation: The application inherits the user’s full permissions rather than a workload-scoped role, expanding the blast radius to whatever the user can do.
3. impact: Actions land in CloudTrail as human activity, making attribution unreliable and weakening incident response, accountability, and non-repudiation.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Human impersonation is a governance anti-pattern, not a federation feature. The core problem is that AWS is allowing an application to execute under a user principal, which breaks the identity boundary that IAM programmes rely on. Auditability depends on the actor remaining visible as itself, and that is lost here. For practitioners, the lesson is that delegation must preserve actor separation if non-repudiation is to survive.

Least privilege defined at login time is the wrong model for workload action. The permission ceiling is now set by the most privileged human who authenticates, not by the service’s actual task. That means authorization is no longer a property of the workload identity lifecycle; it is an accidental byproduct of user entitlements. Practitioners should treat this as proof that workload scope must be independently governed.

Ephemeral credentials are not the problem, identity impersonation is. Short-lived access is still preferable to static keys, but only when the application remains a distinct principal with its own lifecycle and logs. This feature fuses the benefits of federation with the liabilities of impersonation, which is exactly why the line between human and NHI must remain explicit. Security teams should refuse designs that erase that line.

Identity lineage becomes the missing control plane when applications act on behalf of people. The industry has spent years improving credential lifecycle, yet lineage from person to app to action is still treated as optional in many environments. This design shows why that assumption fails. Practitioners need to treat lineage preservation as a first-class identity requirement, not an afterthought for investigations.

Delegated access without actor-bound accountability creates a non-repudiation gap that neither IAM nor SIEM can close after the fact. Once the platform writes actions as human activity, downstream tooling can only infer context, not prove it. That is a structural failure mode, not a logging tuning issue. For identity programmes, the implication is that attribution integrity must be designed into the access model itself.

From our research:

• 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.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, which aligns with the growing pressure to separate human and non-human principals.
• That same survey found 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, reinforcing the need for a separate workload identity model.

What this signals

Identity lineage is becoming a governance requirement, not a forensic luxury. When a platform can make a service look like a user, the programme needs more than authentication and access review. It needs durable lineage from actor to action, and that means mapping service principals, app ownership, and delegated sessions together. For teams aligning to NIST SP 800-207 Zero Trust Architecture, the control question is whether the actor remains continuously identifiable.

Impersonation is the wrong abstraction for workload governance. The next phase of cloud identity will push more runtime decisions into delegated sessions, but that does not mean identity boundaries should blur. The operational signal to watch is whether your environment can still answer who acted, under what principal, and through which service path. If not, the programme is absorbing risk faster than it is governing it.

Non-repudiation debt: this is the gap that opens when the identity used for execution is no longer the identity that owns the task. The implication is broader than AWS. Any programme that lets runtime systems borrow human privilege should expect investigation quality, access review accuracy, and accountability to degrade unless a distinct service identity is preserved. Teams should evaluate that boundary now, not after an incident.

For practitioners

• Preserve separate service principals Require applications to authenticate as distinct workloads with scoped roles, even when they are invoked by users. Do not let the user principal define the service’s effective permissions.
• Treat on-behalf-of sessions as high-blast-radius events Flag every session where an application can act under a human identity as a privileged delegation path. Route these events to enhanced review because attribution is already degraded.
• Correlate action lineage outside CloudTrail alone Join identity events with application telemetry, user-agent signals, and application ownership data so investigators can reconstruct which service drove the session when platform logs stay ambiguous.
• Push for workload-level scoping controls Reassess whether your cloud identity design can constrain accounts, roles, and sessions at the application level rather than inheriting all user permissions. If not, the design is over-broad by default.

Key takeaways

• AWS-style human impersonation breaks the identity boundary that non-repudiation depends on.
• The operational risk is not only broader access, but logs that misattribute service actions to people.
• Practitioners should keep service principals distinct, preserve lineage, and reject designs that make workload identity invisible.

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.
• 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.
• Identity Lineage: Identity lineage is the traceable relationship between a human owner and the non-human identities that person creates, authorises, or depends on. It allows security teams to connect service accounts, API keys, tokens, and AI agents back to accountable ownership for review, audit, and retirement decisions.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.

What's in the full article

Clutch Security's full blog post covers the operational detail this post intentionally leaves for the source:

• CloudTrail event sequencing and how the credentialId can be used to join related actions.
• The exact places where the application disappears from the log trail and where attribution breaks down.
• Practical alerting ideas for CreateTokenWithIAM and follow-on userIdentity events.
• The missing controls AWS would need to restore application-level scope and auditability.

👉 The full Clutch Security post covers the CloudTrail chain, attribution gaps, and missing control points.

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, PAM, or NHI programme, it is worth exploring.