> For the complete documentation index, see [llms.txt](https://docs.e6data.com/query-engine/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.e6data.com/query-engine/guides/security/support-access/enable-audit-block.md).

# 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":  "engineer@e6data.com",
  "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 `support-N@redacted.e6data.com`, 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](/query-engine/guides/security/identity-and-rbac/roles-and-permissions.md).

## 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](/query-engine/guides/security/support-access/privacy-controls.md).

## 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](/query-engine/guides/security/support-access/privacy-controls.md) - the alias model and security guarantees.
* [Roles and permissions](/query-engine/guides/security/identity-and-rbac/roles-and-permissions.md) - the permissions referenced here.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.e6data.com/query-engine/guides/security/support-access/enable-audit-block.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.