On a claims desk, why must an acting-as session carry both the supervisor acting and the adjuster acted for?
answer
- two principals, not one
- who acted versus whose authority
- borrowing authority, not becoming someone
- actor and subject on every check
- the trail must name the supervisor
basics
~20 sAn acting-as session has two principals: the actor doing the work and the subject whose authority is being used. Carry only the subject and every record reads as the adjuster's own work, so nothing shows who really acted.
solid answer
~40 sActing as someone is not becoming them. The session has two principals — the **actor**, the supervisor at the keyboard, and the **subject**, the adjuster whose authority is being borrowed — and both belong on the request's principal, in every authorization decision, and on every record the session writes. Mint the supervisor an ordinary session for the adjuster's account and the pair collapses: the trail says the adjuster approved the payout, the adjuster cannot dispute it, and nothing distinguishes a support session from a real sign-in, so rules that should apply only while acting cannot be applied at all. Keeping both principals also keeps the actor's own standing live: suspend the supervisor and the session must end, even though the adjuster's account is perfectly healthy.
code
json · 11 lines{
"principal": {
"actingAs": true,
"actor": { "id": "supervisor-0082", "territory": "gulf" },
"subject": { "id": "adjuster-4417", "territory": "north-coast" },
"enteredAt": "2026-09-19T09:14:02Z",
"expiresAt": "2026-09-19T09:44:02Z",
"reason": "claim file blocked, assigned adjuster on leave",
"approvedBy": "desk-lead-0031"
}
}go deeper
Recall that an acting-as session names two people: the one doing the work and the one whose authority is being used. Say both, and say that both are recorded.
Explain where the pair travels — on the request's principal, into every authorization decision, onto every record written — rather than being stitched back together from a console log afterwards.
Show what a missing actor costs during a review months later: a payout nobody can attribute, an account holder who cannot dispute it, and no way to hold support sessions to rules ordinary sessions do not obey.
Argue that the pair is a property of the session itself, not a field some code paths remember to attach. Anything optional on one path will be omitted there, and a trail is worth only what its weakest path records.
## Two principals, not one When a supervisor on an insurance claims desk opens an adjuster's queue "as him" to unblock a claim file, the request carries two identities and only one of them is obvious. - The **subject** is the account whose authority is being borrowed. Here that is the adjuster: his territory and his permissions decide which claim files are even reachable. - The **actor** is the human actually issuing the request. Here that is the supervisor: she is the one who will be asked about it afterwards, and her own authority also bounds what the session may do. An acting-as session *is* that pair. The tempting shortcut is to mint the supervisor an ordinary session for the adjuster's account — a few lines of code, works immediately, and indistinguishable from a real sign-in from that moment on. That indistinguishability is the whole defect. ## What the collapse costs you - **Attribution is gone.** Every row the session touches records the adjuster as the person who touched it. A payout approved during the session is, as far as your system knows, his. - **The account holder cannot dispute anything.** The adjuster has no way to show he was on leave, because the evidence says he was working. - **Acting-as rules become unenforceable.** A shorter lifetime, a refusal to change credentials, a banner on screen — every one of those is a rule about a *kind* of session. You cannot apply a rule to a session you cannot recognise. - **The actor's own standing stops mattering.** Disable the supervisor's account and the minted session keeps working, because nothing in it refers to her. - **The desk cannot be reviewed.** "How many times did support open this claim file, and who did it?" has no answer that a single-principal design can produce. ## Where the pair has to travel It is not enough to note the actor once at the door and move on. The pair rides the whole request: 1. **On the request's principal.** Whatever object your server resolves an incoming request to, it holds two identities and a flag saying this is an acting-as session, not one identity that happens to have been obtained unusually. 2. **Into every authorization decision.** The check takes the actor, the subject, the action and the resource — not just "the current user". This is what later lets the decision differ for an acting-as session. 3. **Onto every record the session writes.** Both the domain row's own last-changed-by field and the trail entry name the pair, so a reader sees "supervisor acting as adjuster", never "adjuster". 4. **Into the interface.** The person acting must be able to see, at any moment, whose account she is inside. Losing track is the ordinary way a well-meaning supervisor does something in someone else's name by accident. ## Reading the trail afterwards | Session shape | What the record says | Who can be held to it | |---|---|---| | One principal, minted as the adjuster | "the adjuster approved the payout" | the adjuster — wrongly | | Two principals, actor and subject | "the supervisor, acting as the adjuster, approved the payout" | the supervisor — correctly | | Actor only, with the adjuster's territory copied across | "the supervisor approved the payout" | the supervisor, but nothing says whose authority was used | The third row is worth dwelling on, because it looks like the safe option. Copying the target's reach onto the acting person's own session keeps attribution honest, but it quietly makes her permanently wider rather than temporarily borrowed, and there is nothing to end, nothing to bound, and no record that a borrowing took place at all. ## Reads count as much as writes The most common support action is looking, and looking is also the most common abuse: a curious employee reading a claim file belonging to someone they know. A trail that names the actor only on writes cannot answer the question that is actually asked after such an incident. Record the pair on reads too. ## Where this stops How the actor travels on an issued credential — there are standardised ways for a token to name an acting party alongside its subject, such as a registered `act` claim — is the credential format's concern, and a separate subject from this one. Likewise, exactly which fields a decision record carries beyond the two principals is its own design question. What belongs here is the rule that governs both: your server never collapses the pair into one identity, at any layer, on any path.
- The supervisor's own account is suspended while she is acting as an adjuster. What should happen to the session?It should end at the next request. The session's power rests on both principals, so the actor's standing is re-read every time, not only at entry. Once her authority is withdrawn there is nothing left for the borrowed half to combine with, and waiting for the session's own expiry leaves a suspended person working inside someone else's account.
- Does the actor need to be recorded on reads, or only on writes?On reads too. Reading someone else's file is the most common support action and the most common abuse, and "who opened this claim file, and when?" is usually the first question asked after a complaint. A trail that names the acting person only when something changed cannot answer it.
A duty manager signing for a delivery in her own name while quoting the shop's account, versus signing the absent cashier's name. Both get the parcel; only one tells you who to ask about it next month.
saying these in an interview costs you the question
- Acting as a user means becoming that user for a while.
- Just mint the support agent a session as the customer.
- The support console's own access log is trail enough.
- Only writes need the actor recorded; reads are harmless.
- Once the session starts, the acting person's own account state stops mattering.