Your support console has a "view as user" mode - an engineer enters a user id and the application serves the account exactly as that user would see it. It shipped by reusing the session-issuing code with the target user's id. The first time it is used on an account that is later disputed, what happens second by second, and what stops it?

Second by second

The engineer clicks. The auth service mints a session whose subject is user 48201. Every downstream call carries user 48201's identity, because that is the only identity in the token. The application writes an audit row: "user 48201 viewed order 7781". The engineer, trying to help, cancels the order, and the row says the user cancelled it.

Three weeks later the user disputes the cancellation. There is no record anywhere in the system that distinguishes the engineer's actions from the user's, because at the moment of the write the two were the same principal. The console's own access log is a different system, with different retention, and it records that the console was opened — not what was done inside it.

RFC 8693 (OAuth 2.0 Token Exchange, 2020) names exactly this distinction. Under impersonation the actor is indistinguishable from the subject within that rights context; under delegation the token carries an act claim naming who is acting on whose behalf. The feature was built as impersonation and needed to be delegation, and that single word is the whole of the design error.

Where it amplifies

• The user's own data-subject access request returns staff actions as the user's history, so the company asserts, in a legally meaningful document, something untrue.
• Risk and fraud models train on those events as user behaviour.
• The anomaly detector sees activity from an unfamiliar location and locks the account the user is calling about.
• If the engineer's own account is ever compromised, the attacker inherits the ability to act as any user, leaving traces that are by construction indistinguishable from legitimate use.

What stops it

• Two identities in the token. Subject is the user, actor is the staff principal, plus a grant id.
• The actor recorded on the write, not in a log. An acted_by column written in the same transaction as the row. A separate log with its own retention is not an audit trail of the change.
• Read-only by default. The impersonated session cannot make state changes; a state change needs a separate, individually approved grant.
• A time-boxed, reason-bound grant — 15 minutes, tied to a ticket id — and the grant exists as a record whether or not anything was viewed, so the absence of activity is also evidence.
• Visible to the user: "a support agent viewed your account at 14:02, ticket 44812", in the account's own activity log. This is the control that makes the others true, because it is the only one the person who might be harmed can check for themselves.

Nothing self-heals here. The actor identity is destroyed at write time and no later tool recovers it, which is why this has to be decided before the feature ships rather than after the first dispute.

What it costs: roughly a week of work on the token path plus one column and one migration per write table, and a standing price in support handling time, because every state change now needs a second grant. Choose the read-only default and pay that; it is the version of the control that survives a busy Monday, whereas a policy that relies on engineers remembering to request elevation does not.

When this is the wrong answer

For an internal tool where the "users" and the support staff are the same staff population under one audit regime, the extra identity plumbing buys little and the grant workflow will be routed around. And for genuine break-glass incident access the answer is not read-only: the engineer must be able to act. There the controls move to loudness — a session that pages someone else on creation, a fixed short expiry, and a written after-the-fact justification that a second person signs.