How should an acting-as session's authority be bounded when a supervisor works an adjuster's claim queue?

middlemust knowfreq 44%

answer

down, never sideways
intersection, not union
the actor's own limits still apply
denylist of actions that outlive it
no credential or role changes while acting

basics

~20 s

Give the session the intersection of the acted-for account's authority and the acting person's own — never the union — and subtract a denylist of account-takeover actions: credential changes, second-factor enrolment, recovery-address changes, role grants and bulk export.

solid answer

~50 s

Two rules. First, scope down, not sideways: the session may do what both principals may do, so it is always narrower than either of them alone. Borrowing an adjuster's account must never hand the supervisor a privilege she cannot exercise under her own name — if she needs it, she needs her own grant, through the ordinary process, with her name on it. Second, a denylist that applies however wide the acted-for account is: changing credentials, enrolling or removing a second factor, changing the recovery address, granting a role, exporting the account. Those actions outlive the session and convert a bounded, observed support visit into permanent control, so they are refused with 403 — the server knows exactly who both principals are, and the answer is still no. Do not implement any of this by writing a temporary grant onto the supervisor's own account: a standing grant is not a session.

Two rules. First, **scope down, not sideways**: the session may do what *both* principals may do, so it is always narrower than either of them alone. Borrowing an adjuster's account must never hand the supervisor a privilege she cannot exercise under her own name — if she needs it, she needs her own grant, through the ordinary process, with her name on it. Second, a **denylist that applies however wide the acted-for account is**: changing credentials, enrolling or removing a second factor, changing the recovery address, granting a role, exporting the account. Those actions outlive the session and convert a bounded, observed support visit into permanent control, so they are refused with `403` — the server knows exactly who both principals are, and the answer is still no. Do not implement any of this by writing a temporary grant onto the supervisor's own account: a standing grant is not a session.

code

pseudocode · 20 lines

pseudocode

ACTING_AS_DENYLIST = [
    "credential.change", "mfa.enroll", "mfa.remove",
    "recovery_address.change", "role.grant",
    "account.export", "acting_as.enter"
]

function authorize(principal, action, resource):
    if principal.subject == null:                 # ordinary session:
        return holds(principal.actor, action, resource)   # one principal, no denylist

    if action in ACTING_AS_DENYLIST:              # refused however wide
        return DENY                               # the acted-for account is

    if not holds(principal.subject, action, resource):
        return DENY                               # beyond what is borrowed

    if not holds(principal.actor, action, resource):
        return DENY                               # beyond her own authority

    return ALLOW

go deeper

for a junior

Remember the direction: a support session gets less than the account it borrows, never more. Naming the credential and second-factor denylist is enough at this level.

for a middle

Design it concretely: two authority checks per request against both accounts as they stand now, with a short denylist tested first and applying only while acting.

for a senior

Defend the denylist against the obvious objection — the acted-for account may do these things itself — by pointing at which effects survive the session, since the whole safety case rests on the session ending.

for a principal

Decide whether your desk needs acting-as at all, or whether a read-only reproduction of the account's view covers most of the work at a fraction of the blast radius, with borrowing reserved for the cases that genuinely must write.

Down, never sideways

The instinct when building a support console is that acting as someone means getting what they have. That is the union rule, and it turns whoever staffs the desk into the most powerful principal in the system: any authority held by any account they may act for becomes reachable.

The rule that works is the opposite. An acting-as session receives the intersection of the two principals' authority:

the action must be one the acted-for account may perform — otherwise the supervisor has reached past what borrowing can justify;
and it must be one the acting person may perform in her own name — otherwise she has escalated herself by borrowing.

So the session is strictly narrower than either principal alone. A supervisor who may not approve payouts still may not approve one while acting as an adjuster who can. The point is not that her fingerprints are on it — attribution is a separate good — but that borrowing an account is not a grant process. If she genuinely needs payout approval, she gets it as a standing grant on her own account, reviewed, with her name on the record from then on.

Computing the intersection

Resist precomputing a frozen permission set at entry and carrying it for the session's life. Express the intersection as two checks run per request, against both accounts as they are now. That way, a grant withdrawn from either account during the session takes effect on the next request rather than at the next sign-in, which matters precisely in the case where someone is removing authority in a hurry.

The denylist, and why it is not redundant

The intersection rule alone permits an obvious disaster: the adjuster may change his own password, and the supervisor may change hers, so the intersection contains "change this account's password" and a support session can lock the adjuster out of his own account and keep it.

So a small, explicit denylist sits in front of the intersection and applies only while a session is acting — an ordinary sign-in must of course still be able to change its own credentials.

Denied while acting	Why it is on the list
Change password or other sign-in credential	Survives the session; the acted-for person loses their own account
Enrol or remove a second factor	Converts a temporary visit into a durable way back in
Change the recovery address or phone	The slow version of the same takeover, and the hardest to notice
Grant a role or add a permission	Turns a bounded borrowing into a standing privilege
Bulk export or download the account's data	Leaves the boundary entirely; nothing after the exit can undo it
Enter a further acting-as session as a third account	Chains borrowings until nothing can be reasoned about

The common objection — "but the adjuster could do all of these himself" — is exactly what makes them dangerous here. The list is not about what the account may do. It is about which actions still have effect after the session ends, because those are the actions that change who controls the account, and the whole safety argument for acting-as rests on the session ending.

What happens when the denylist bites

Refuse with a status that says I know who you are and the answer is no — 403, not a challenge to authenticate. Both principals are known; nothing about identity is in doubt. Two habits make the refusal humane rather than baffling:

Say why in the response the console shows. "Credential changes are not available while acting as another user" is a sentence the supervisor can act on; a bare denial produces a support ticket about the support tool.
Give a legitimate route. The supervisor who genuinely needs the adjuster's password reset triggers the account's own recovery flow, which notifies the adjuster and proves nothing about her authority — rather than performing the change from inside his account.

Not a role grant

One implementation shortcut deserves naming because it is common and it undoes everything above: writing a temporary row that gives the supervisor the adjuster's role for half an hour. It produces a session that looks ordinary again, cannot be recognised for the denylist, does not narrow to an intersection, and — if the cleanup job ever misses — silently becomes permanent. Acting-as is a property of the session, evaluated per request, carried by the request's principal. A standing grant is a different thing with a different life cycle.

The shape to say out loud

Asked to design it, the answer is three sentences: the session is the overlap of the two principals and never the sum; a short denylist of actions that outlive the session is refused whatever the acted-for account may do; and neither rule is implemented by granting the acting person anything that survives the session.

## Down, never sideways The instinct when building a support console is that acting as someone means *getting what they have*. That is the union rule, and it turns whoever staffs the desk into the most powerful principal in the system: any authority held by any account they may act for becomes reachable. The rule that works is the opposite. An acting-as session receives the **intersection** of the two principals' authority: - the action must be one the **acted-for account** may perform — otherwise the supervisor has reached past what borrowing can justify; - *and* it must be one the **acting person** may perform in her own name — otherwise she has escalated herself by borrowing. So the session is strictly narrower than either principal alone. A supervisor who may not approve payouts still may not approve one while acting as an adjuster who can. The point is not that her fingerprints are on it — attribution is a separate good — but that borrowing an account is not a grant process. If she genuinely needs payout approval, she gets it as a standing grant on her own account, reviewed, with her name on the record from then on. ## Computing the intersection Resist precomputing a frozen permission set at entry and carrying it for the session's life. Express the intersection as two checks run per request, against both accounts as they are *now*. That way, a grant withdrawn from either account during the session takes effect on the next request rather than at the next sign-in, which matters precisely in the case where someone is removing authority in a hurry. ## The denylist, and why it is not redundant The intersection rule alone permits an obvious disaster: the adjuster may change his own password, and the supervisor may change hers, so the intersection contains "change this account's password" and a support session can lock the adjuster out of his own account and keep it. So a small, explicit denylist sits in front of the intersection and applies **only** while a session is acting — an ordinary sign-in must of course still be able to change its own credentials. | Denied while acting | Why it is on the list | |---|---| | Change password or other sign-in credential | Survives the session; the acted-for person loses their own account | | Enrol or remove a second factor | Converts a temporary visit into a durable way back in | | Change the recovery address or phone | The slow version of the same takeover, and the hardest to notice | | Grant a role or add a permission | Turns a bounded borrowing into a standing privilege | | Bulk export or download the account's data | Leaves the boundary entirely; nothing after the exit can undo it | | Enter a further acting-as session as a third account | Chains borrowings until nothing can be reasoned about | The common objection — "but the adjuster could do all of these himself" — is exactly what makes them dangerous here. The list is not about what the account may do. It is about which actions still have effect **after** the session ends, because those are the actions that change who controls the account, and the whole safety argument for acting-as rests on the session ending. ## What happens when the denylist bites Refuse with a status that says *I know who you are and the answer is no* — `403`, not a challenge to authenticate. Both principals are known; nothing about identity is in doubt. Two habits make the refusal humane rather than baffling: 1. **Say why in the response the console shows.** "Credential changes are not available while acting as another user" is a sentence the supervisor can act on; a bare denial produces a support ticket about the support tool. 2. **Give a legitimate route.** The supervisor who genuinely needs the adjuster's password reset triggers the account's own recovery flow, which notifies the adjuster and proves nothing about her authority — rather than performing the change from inside his account. ## Not a role grant One implementation shortcut deserves naming because it is common and it undoes everything above: writing a temporary row that gives the supervisor the adjuster's role for half an hour. It produces a session that looks ordinary again, cannot be recognised for the denylist, does not narrow to an intersection, and — if the cleanup job ever misses — silently becomes permanent. Acting-as is a property of the *session*, evaluated per request, carried by the request's principal. A standing grant is a different thing with a different life cycle. ## The shape to say out loud Asked to design it, the answer is three sentences: the session is the overlap of the two principals and never the sum; a short denylist of actions that outlive the session is refused whatever the acted-for account may do; and neither rule is implemented by granting the acting person anything that survives the session.

The adjuster may approve payouts and the supervisor may not. May the acting-as session approve one?
No. The session may only do what both principals may do, so a privilege the acting person cannot exercise in her own name is not reachable by borrowing an account that holds it. If she genuinely needs it, the answer is a grant on her own account through the ordinary process — reviewed, durable, and recorded under her name from then on.
Why deny "change the recovery address" when the adjuster could change it himself at any time?
Because its effect outlives the session. The safety case for acting-as rests entirely on the session ending; credential changes, second-factor enrolment, recovery-address changes, role grants and exports all leave something behind that ending the session does not undo. Those are the actions that turn a bounded support visit into permanent control, so they are refused whatever the acted-for account may do alone.
How do you stop a scoped-down session widening itself by acting as a third account?
Put entering another acting-as session on the denylist. Chained borrowings compose authority in a way nobody can reason about, and the trail stops being readable after the second hop. One session, one subject, and a fresh entry — with its own reason and approval — if a different account is genuinely needed.

saying these in an interview costs you the question

Acting as someone gives you everything that person can do.
The session should allow whatever either party could do.
Implement it as a temporary role grant on the supervisor's account.
A denylist is pointless if the target could do it anyway.
Scoping down just means making the support session read-only.
Approval at entry makes per-action limits unnecessary.

How should an acting-as session's authority be bounded when a supervisor works an adjuster's claim queue?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Down, never sideways

Computing the intersection

The denylist, and why it is not redundant

What happens when the denylist bites

Not a role grant

The shape to say out loud

▾common follow-ups3 questions

▾red flags6 flags

Down, never sideways

Computing the intersection

The denylist, and why it is not redundant

What happens when the denylist bites

Not a role grant

The shape to say out loud

answer

go deeper