Topic starter
22/07/2026 4:34 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Clutch Security: “On Behalf of Whom? How AWS Broke Non-Repudiation and Shipped It as a Feature”.
Key questions
Q: What breaks when AWS impersonation lets an application act as a human identity?
A: The failure is attribution.
Q: Why does on-behalf-of access create audit and accountability risk?
A: Because it merges two different actors into one recorded identity.
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.
Practitioner guidance
- 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.
Bottom line: This AWS pattern collapses the boundary between human and application identity, which is why non-repudiation and auditability fail together.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
22/07/2026 4:40 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AWS identity center impersonation breaks non-repudiation and auditability
This post was modified 5 days ago by NHI Mgmt Group