> 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/privacy-controls.md).

# Privacy controls

The per-tenant alias model behind e6data Support Users - how identities stay private, how audit history stays correct, and the security guarantees.

This page is for security reviewers and compliance teams. It explains the per-tenant alias model that keeps e6data engineer identities out of your logs, how audit history stays correct over time, and the guarantees behind blocking and revocation.

## Identity and privacy model

e6data does not expose an engineer's personal identity across customer audit logs, and does not use a shared generic "support" account (which would defeat accountability). The platform resolves this with a **per-tenant alias** that is:

* **System-assigned.** When a Support User is bound to your organization, the system picks the smallest unused integer N in your tenant and assigns the alias `support-N`. The engineer cannot choose or change it.
* **Unique within your organization.** Two Support Users in your tenant never share an alias at the same time.
* **Reused over time, with full history.** When a Support User is removed, the alias returns to the pool and may later be reassigned to a different engineer. A separate alias-history record preserves who held which alias at which point in time.

What e6data sees internally: our tooling resolves aliases back to real identities for accountability. What your organization sees - in the UI, audit logs, query attribution, and workspace records - is only the alias.

## Historical correctness

The audit log uses the alias **as it was at the time of the recorded action**. Suppose `support-2` was held by engineer Alice in March, released when she left the engagement, and reassigned to engineer Bob in June:

* An audit entry dated March showing `support-2` still resolves to Alice - the system stores the immutable user ID and looks up who held alias 2 in March through the alias-history record.
* An audit entry dated July showing `support-2` resolves to Bob.

Alias reuse is therefore safe: the alias number you see is always tied unambiguously to one engineer for any specific point in history. e6data review tooling can map the alias to the real engineer when accountability is required.

## What is not recorded

The Support User's real email never appears in any customer-facing surface - only the alias. This is intentional. If your compliance posture requires a real identity on request, contact your e6data account team; the mapping is maintained internally and can be provided under your standard support contract.

## Security guarantees

### Threat model

| Concern                                                              | Control                                                                                                    |
| -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| A non-e6data account being added as a "support" user                 | Email-domain allowlist (`@e6x.io`, `@e6data.com`) enforced when adding; other domains rejected with `400`. |
| An admin adding a Support User without permission                    | `write:invitations` check on the add call - the same control as any invitation.                            |
| An e6data engineer rejoining after being asked to leave              | The per-tenant block is checked on self-bind; blocked engineers cannot rejoin.                             |
| Privilege escalation via the support role                            | The support role is configurable per engagement; the default is Admin, but you can narrow it.              |
| Identity leakage of e6data staff into customer logs                  | Alias rendering at every customer-facing surface; the real identity never leaves the Control Plane.        |
| Stale audit entries pointing at the wrong engineer after alias reuse | Alias history preserves the immutable user-ID ↔ alias-at-timestamp mapping.                                |
| Workspace-side records leaking the engineer's email                  | Workspace records use an opaque identifier; only the alias is surfaced.                                    |
| Block bypass via cached sessions                                     | The block is checked on tenant switch and on login; existing sessions cannot switch into a blocked tenant. |

### Trust boundary

The Control Plane is the **only** component that knows the mapping between the alias and the real e6data engineer. Your workspaces (the Compute Plane) receive only the alias, an opaque user ID, and the Support User flag. Even if a workspace's audit pipeline is exported to your SIEM verbatim, no real e6data identity is leaked.

Authorization is always performed against the **real** opaque user ID, never against the alias. Aliases are render-time labels, not authentication or authorization primitives - so renaming or reusing an alias can never inadvertently grant or revoke permissions.

### Revocation guarantees

* **Block latency.** A block takes effect on the next request the user makes; the block flag is not cached.
* **Workspace propagation.** Removing a Support User propagates to every workspace within one sync cycle (about 30 seconds). The workspace access is torn down before any new alias rebind takes effect on the same workspace.
* **All-tenant block.** A user blocked in every tenant cannot log in at all - there is no default-tenant fallback.

### Tracked enhancements (not yet enforced)

The following are on the roadmap; in the interim, operational SLAs and internal e6data review cover them:

* **Time-bound bindings (TTL).** Today a Support User remains bound until removed; automatic expiry after a configurable window is planned.
* **Customer pre-approval gate on self-bind.** Today an engineer can self-bind without per-incident approval (the domain check and your post-hoc block are the controls); an approval workflow is planned.
* **Read-only default role.** Today the default support role is Admin; you can override per engagement. A read-only-by-default mode is planned.

## See also

* [Enable, audit, and block support access](/query-engine/guides/security/support-access/enable-audit-block.md) - adding, blocking, and auditing Support Users.
* [Support access overview](/query-engine/guides/security/support-access.md) - what a Support User is.


---

# 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/privacy-controls.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.