Safe impersonation for a multi-tenant security platform.
A feature I designed for letting one person act inside another user's account on a product whose whole job is security, without breaking that security
Give the least access the job needs. Make it impossible to forget. Log all of it
Context
A multi-tenant security platform. Operators manage many client organizations and their users. Two roles regularly need to act as a specific user:
— Support and admins — to reproduce and fix a user's problem.
— External installers — to set up a user's environment before handing it over
Both need to see and do things as that user. On a security product, that is the problem, not a convenience
The problem
Before a real feature, "helping a user" meant one of three bad options:
— Ask the user to screen-share or read out their screen — slow, and you can't reproduce the bug.
— Share credentials — no audit, no expiry, far too much access.
— Grant standing broad access — same, plus a privacy hole
Every one of these breaks the rules the product sells. So the question was narrow: let someone act as a user, and keep it safe
The access model
The design turns on who is doing the impersonating. An internal actor is trusted; an external one crosses a boundary
The more external the actor, the more the user stays in control
The access model
For external actors, "visibility after" is literal: the session also appears in the end user's own activity log — the same trail, framed in their words — so whoever consented can see exactly what was done
When the session ends, they also get a summary email — what was accessed and which categories were revealed — so the flow that opened with a consent code closes with a receipt. Internal sessions stay in the company log only
How it works
#1
Impersonation starts from where you already are — the users list
#2
A colored frame and a persistent bar make "who am I right now" impossible to miss. Sensitive data stays masked until revealed
#3
External actors only. The email code is both consent and proof of identity
#4
Every session is accountable. Internal sessions live in the company log only; external sessions also appear in the user's own log
#4
The log is a focused view of the wider activity log — impersonation gets its own lens because it's high-risk. Any row opens a session panel with the full timeline, and each session downloads as a tamper-evident JSON record: every reveal is logged by category, never by value. Failed sessions appear too — an expired external code, for example — so the consent gate is visible doing its job
Key decisions
In the process of my work, I designed several screen options to determine the most successful one
I tested the sequence of steps with my respondent. No downsides were found in the flow. Once again, I emphasize that data from one respondent would be subjective and not representative of a real product
The logic in one picture
Consent before, visibility after — both scale with distance from the company
The level of disclosure during impersonation depends on the data's sensitivity, to ensure user safety
Edge cases and error states
The interesting part of impersonation isn't the happy path — it's what happens when a session doesn't end cleanly
Outcome
Support can help without breaking least-privilege
Privacy is protected by default, opened only on purpose
Outside access is consented and fully traceable
Every session is accountable
The hardest part wasn't the interface — it was deciding how much to trust internal actors
I chose org-level accountability over per-user approval: trusted employees, every action logged
krsgromov@gmail.com