Impersonation

What impersonation is

Impersonation lets a super admin (typically a support agent) interact with the platform as if they were a specific user in your workspace. The UI looks identical to what that user sees; the impersonator can click, scroll, and read anything the user can.

When it's used

Support uses impersonation when:

• You report a UI bug ("the audit page won't load for me") and the issue can't be reproduced from a clean account.
• Customer success runs a periodic health check on enterprise accounts.
• Engineering is reproducing a complex bug that depends on workspace-specific data shape.

It's NOT used when:

• A data export or read action would suffice.
• The customer hasn't asked for hands-on help.
• The impersonator just wants to "check on" an account.

How a session starts

1. Support agent identifies the user to impersonate (usually you — the ticket opener).
2. Agent clicks Impersonate in the super-admin panel.
3. The agent enters a justification string (free text, audit-logged).
4. The session starts. The agent's browser is now logged in as the target user.

You get an in-app banner the moment impersonation starts:

> ⚠️ An AI Domination staff member is currently viewing your account.
> Agent: Jane Doe · Ticket #1234 · Started 2 minutes ago.
> [Revoke session]

You also get an email within 60 seconds confirming the session, with the agent's name and ticket ID.

What an impersonator can do

Same as the impersonated user — read-only by default. Write actions (creating content, running audits, etc.) require a separate Allow writes elevation, which prompts the user via the in-app banner ("Agent is requesting permission to make changes"). The user clicks Allow or Deny.

We never auto-grant writes. The agent must ask, you must allow, both events are logged.

What impersonators CAN'T do

Even during an impersonation session:

• Cannot view raw API key plaintext.
• Cannot decrypt integration credentials (still encrypted at rest with workspace keys).
• Cannot change billing.
• Cannot promote roles.
• Cannot delete the workspace.

These are blocked at the API layer, not the UI — they wouldn't work even if the agent crafted a custom request.

Ending the session

Three ways the session ends:

1. Agent clicks "End impersonation." Normal path.
2. You click "Revoke session" on the banner. Immediate.
3. Automatic timeout after 60 minutes.

After session end, the agent's regular super-admin session resumes.

What's audit-logged

For every impersonation session:

• Session start: actor (the agent), target (the user), justification, ticket ID, timestamp.
• Every action taken (page view, button click, API call) tagged with both actors.
• Any write elevation request and outcome.
• Session end: end reason (manual, revoked, timeout), timestamp.

Filter your audit log on session.impersonation to see every session.

Restricting access

Settings → Privacy → Impersonation:

• Off. Impersonation is allowed (default).
• Confirm each session. Every session start requires real-time approval from a workspace owner. Slows support but tightens the privacy posture.
• Disabled. No impersonation ever. Support will need to work entirely from data exports and your written explanations.

Enterprise contracts can also lock impersonation to a named list of agents.

How to verify a session is legitimate

If you're suspicious that the banner is forged (it isn't — banners are server-rendered — but it's a fair question):

1. Check the email; it comes from a verified @aidomination.app address.
2. Check the audit log; the session start is logged within 5 seconds.
3. Open the ticket referenced in the banner. The ticket itself should reference the impersonation request.

If anything doesn't add up, revoke and escalate. Misuse will be caught.