An audit entry names an assumed-role session, not a person — how do you prove who acted?

## The problem In a modern cloud estate almost nothing acts as a named user. A person authenticates to an identity provider, receives a federated session, assumes a role, and that role assumes another role in a different account. Every audit entry after the first hop names **the role session**, not the human. As a forensic examiner you may have to defend the sentence "this named person performed this action", and the fields in front of you do not say that. ## What the identity block actually contains A typical assumed-role identity block carries: - `type`: the class of principal — an assumed role rather than a user. - `principalId`: the role's internal id joined to the **session name**, e.g. `AROA3EXAMPLEID:deploy-9f31`. - `arn`: the session ARN, which repeats the role name and session name. - `sessionContext.sessionIssuer`: the role that was assumed, by name and ARN, and the account that owns it. - `sessionContext.attributes.creationDate`: when the session was created — the key pivot. - `sessionContext.attributes.mfaAuthenticated`: whether MFA was part of the originating authentication. The same shape exists elsewhere. In Google Cloud, `protoPayload.authenticationInfo.principalEmail` may be a service account while `serviceAccountDelegationInfo` names the originating principal that impersonated it. In Azure, the caller on an activity-log entry may be an object id belonging to a service principal, with the human only visible in the directory sign-in records. ## The walk-back procedure 1. **Fix the session.** Take the principal id and session name from the entry under investigation, and the session creation time. 2. **Find the assumption event.** Search for the role-assumption call whose response produced that exact session, bounded to the creation timestamp. Its own `userIdentity` is the caller — the previous hop. 3. **Ask whether the caller is human-authenticated.** If it is another role session or a workload identity, repeat step 2 for that hop. If it is a federated login, move to the identity provider. 4. **Cross the account boundary consciously.** A role in account B is often assumed by a principal in account A, and the assumption event is recorded in the *caller's* account. If a different team, a vendor or an unowned account holds that trail, your chain has a gap you must state rather than paper over. 5. **Land on an authentication event.** Only the identity provider's sign-in record ties a session to a human, a device, a source address and whether MFA was satisfied. That record — not the cloud audit entry — is what carries the person. 6. **Bracket the session window.** Creation time plus session duration bounds every action that session could have taken, which both scopes your timeline and limits over-claiming outside the window. ## What breaks the attribution, and you must say so before the other side does - **The session name is not an authenticated field in every path.** When a principal calls assume-role directly it chooses the session name freely, so `deploy-9f31` or even `alice` proves nothing on its own. When a federated identity provider sets it from the assertion, it is attested by that provider — different provenance, different weight, and you should know which path applied. - **Shared roles collapse people together.** If ten engineers and a deployment pipeline all assume the same role, the role name attributes nothing; only the earlier hop does. - **Overlapping sessions.** Two humans holding sessions from the same role at the same time can only be separated by session name, source address and the assumption events, not by the action entries themselves. - **Chain gaps.** A missing trail in an upstream account ends the walk. The honest output is "a session created at 02:38 by a caller in account A, which I cannot resolve further". - **A credential is not a body.** Even a clean chain to a named person's federated session proves that person's credential and session were used. Session theft, a shared workstation and a token lifted from a developer machine all produce identical records. ## The one field designed for this Some platforms let the originating identity be stamped into the session as an **immutable source identity** that propagates through every subsequent assumption and appears on every downstream entry. Where that is configured, the walk-back collapses to reading one field, and because later hops cannot overwrite it, it survives chaining. Where it is not configured, the walk-back is the only method — and recommending it be turned on is the correct forward-looking half of the answer. ## How to state the finding Write the chain, not the conclusion: session S, created at time T by caller C, which was itself created by federated login L for user U, authenticated with MFA from address A. Every arrow is a record you can produce. That is a claim you can defend when the identity fields are challenged; "the logs show Alice deleted it" is not.