Skip to content

Impersonate a member for support

PortalCLIIntermediate~5 min

When a teammate reports "I can't see that memory" and you can, guessing at gates is slow. Impersonation lets you look at Hadron as they see it — without their password, without changing anything, and without leaving the support trail.

A session is deliberately narrow:

  • Read-only. Every mutation is rejected except the one that ends the session itself (stopImpersonation), so you can always stop without switching credentials. You cannot fix anything while impersonating — you diagnose, stop, then fix as yourself.
  • Scoped to one organization. You see what the member sees inside the org you administer. Their other organizations stay invisible.
  • Blind to personal data. Their private notes, chats, mailbox, files and personal API keys are never visible. See what you can and can't see.
  • Time-limited and revocable. Sessions expire on their own (1 hour by default) and you can end one at any time.
  • Audited. Every session is recorded — who impersonated whom, in which org, when it started and ended.

Before you start

You need to be an Admin or Owner of the organization, and your target must be an active member of that same organization.

One rule to know up front: an Admin cannot impersonate an Owner. You can impersonate members at your own level or below. An Owner can impersonate anyone.

In the portal

  1. Open your organization, then the Team tab.
  2. Find the member in the table and click Impersonate in their row.
  3. Confirm the prompt.

The page reloads as that member. A persistent amber banner across the top shows whose view you're in and how long the session has left — it stays there for the whole session so the state is impossible to forget.

To finish, click Stop impersonating in the banner. Your own session is restored immediately; you don't sign in again.

You won't see the button on every row

It's hidden for yourself, hidden while you're already impersonating, and — if you're an Admin rather than an Owner — hidden on Owner rows.

From the CLI

hadron auth impersonate <user> --org <org> --reason "ticket 4213"

<user> accepts an id, handle, email, or hrn:user:<handle> URN, and must match exactly — a partial match is refused rather than silently retargeted. --reason is optional and recorded in the audit trail.

Every later command then runs read-only as that member until you stop:

hadron auth whoami          # says IMPERSONATED, names the real actor and expiry
hadron memory ls            # the member's view, inside the shared org only
hadron auth impersonate --stop

hadron auth status also reports the state, and signing out (hadron auth logout) ends the session rather than leaving it live.

Unset HADRON_TOKEN first

An exported HADRON_TOKEN takes precedence over the impersonation session, so later commands would silently run as you with full write access. The CLI refuses to start a session while it's set — unset it and retry.

What you can and can't see

The point of a session is diagnosing shared-org access, so it grants exactly that and nothing else.

Visible Not visible
Knowledge and group memories in the shared org, as that member sees them Their personal and private memories — including ones they own
The org's agents, apps and sessions they can reach Anything in their other organizations
Their org-scoped access, so you can reproduce a denial Their AI chat transcripts
The org member list, as they see it Their mailbox, calendar and Drive files
Assets they uploaded, and asset download links
Their personal API keys, secrets and delegated grants
Agents and apps they own personally (outside any org)

If a surface isn't in the left column, assume it's refused. The scope is enforced on the server, so this holds no matter which client you use — and the private-memory promise is not weakened by impersonation.

Ending a session

Three things stop a session working:

  • You stop it — the banner button, or hadron auth impersonate --stop.
  • It expires — one hour by default.
  • Authority changes — if you lose your Admin/Owner role, if the member leaves the org, if either account is deleted, or if a role change would now breach the peer-or-below rule (say the member is promoted to Owner while you're an Admin), the session ends on the very next request rather than running to expiry.

Because every request re-checks the session record and both parties' current roles, stopping takes effect immediately everywhere — not just in the client where you stopped it.

The trail records how a session ended

All three cases are distinguishable afterwards. An explicit stop records both endedAt and endedBy (the admin who stopped it). A revocation records endedAt with endedBy empty — the system ended it, not a person. A session that simply ran out has neither, just a past expiresAt.

Reviewing the audit trail

Every session is recorded whether or not anything was read. Admins and Owners can list their organization's history:

query {
  impersonationSessions(orgId: "<org>", filter: { activeOnly: false }) {
    total
    items {
      adminUser { handle }
      targetUser { handle }
      reason
      createdAt
      expiresAt
      endedAt
      endedBy
      isActive
    }
  }
}

Records are never deleted — ending a session stamps endedAt rather than removing the row, so activeOnly: true shows what is genuinely live right now. A session whose authority was revoked drops out of that list immediately, not when its hour would have been up.

What's next