Enable, audit, and block support access

Add, block, unblock, and list e6data Support Users over the API, the permissions required, and how their actions appear in your audit log.

This page is for admins with the write:invitations or write:users permission. It covers adding a Support User, blocking and unblocking, listing, the permissions involved, and how Support User activity is audited.

How a Support User becomes bound

There are two ways a Support User becomes bound to your organization:

1. An admin invites them. Someone with write:invitations adds the engineer through the support-user API (below). This is the default path for planned engagements.
2. An e6data engineer self-binds. For incident response, an authenticated e6data engineer (@e6x.io / @e6data.com) can self-bind to your organization. A self-bind is rejected if your organization has previously blocked that specific engineer - your block decision is always respected.

Either path produces the same result: the user is marked as a Support User in your tenant, an alias is allocated, an audit entry records the bind, and the account syncs to every workspace automatically (typically within about 30 seconds), where it is granted the configured support role so the engineer can debug effectively.

Add a Support User

POST /api/v1/support-users
Authorization: Bearer <your-token>
Content-Type: application/json

{
  "email":  "[email protected]",
  "roles":  ["admin"]
}

Field	Required	Notes
email	Yes	Must end in @e6x.io or @e6data.com. Any other domain returns 400.
roles	No	Defaults to ["admin"]. Specify a narrower set (for example, ["viewer"] or a custom read-only role) to scope what the engineer can do.

The engineer is now bound to your tenant. The returned email is masked as [email protected], and isSupportUser is true. The same masking applies anywhere this user appears.

Block a Support User

A block is the fast revocation mechanism. It preserves the user's roles (so you can restore access by unblocking later) but immediately denies them entry to your organization.

POST /api/v1/users/{userId}/block
{
  "reason": "Engagement closed 2026-06-02"
}

• The block is per-tenant - it only affects your organization. If the same engineer supports another customer, that relationship is unaffected.
• A blocked engineer attempting to switch into your tenant is denied with 403 Forbidden.
• If a Support User is blocked in every tenant they belong to, their login fails entirely with 401 Unauthorized.
• Self-bind is rejected for any engineer your organization has blocked - even if they were never previously bound.

Unblock

POST /api/v1/users/{userId}/unblock

The user regains the roles they had at block time and the alias they previously held, if it's still available; otherwise a new one is allocated.

List and inspect

• GET /api/v1/users/me/tenants - each tenant entry carries isBlocked, so you can see where Support Users are currently active versus blocked.
• The standard user-list endpoint surfaces isSupportUser: true for every Support User in your organization, with the alias rendered in the email and name fields.

Required permissions

Action	Permission
Add a Support User	write:invitations
Block / unblock	write:users
Read the user list	read:users

These are the same permissions you already manage through your existing roles - no new role bindings are required. See Roles and permissions.

Audit and visibility

Every meaningful action a Support User performs is recorded with their alias, not their real identity:

Surface	What you see
User list	support-N (alias) with isSupportUser: true
Workspace members	support-N
Audit log / user change log	Actor rendered as support-N as of the action's timestamp
Query history / attribution	Owner shows support-N (snapshotted at query time)
Within a workspace	The support role is granted without exposing the engineer's email; only the alias is surfaced
Login / session events	Marked with the isSupportUser flag

For how aliases resolve correctly over time and what is never recorded, see Privacy controls.

End-to-end flow

When you add a Support User, the Control Plane validates the email domain (e6x.io / e6data.com), allocates the next free alias for your tenant, binds the user, writes an alias-history record, and returns a customer-facing response as support-N. The binding then syncs to each workspace automatically (within about 30 seconds), where the engineer is granted the support role and all logs and queries are attributed to support-N.

When the engagement ends and you block the user, the Control Plane marks them blocked for your tenant (preserving roles), refuses future tenant switches and self-binds, and the workspaces stop accepting the user within one sync cycle.

See also

• Privacy controls - the alias model and security guarantees.
• Roles and permissions - the permissions referenced here.