> 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.md). # Support access How e6data Support Users work - scoped, aliased, fully audited e6data engineer access that you can revoke at any time. This section explains how **e6data Support Users** work in your organization: how they are added, what they can see, how they are audited, and how you stay in control of their access. This guide is for organization admins and security and compliance reviewers. ## What is a Support User? A **Support User** is an e6data engineer who has been granted scoped access to your organization to help debug an issue, validate a configuration, or assist with onboarding. Three properties distinguish a Support User from a regular member of your organization: 1. **Identity is e6data, not a third party.** Only accounts on `@e6x.io` or `@e6data.com` can ever be added as Support Users. Customer-owned emails are rejected. 2. **They are transparently labelled.** Every customer-facing surface - user list, audit log, query attribution, workspace members - marks the account as a Support User and renders it under a per-organization alias such as `support-1`, `support-2`, …, with the email shown as `support-1@redacted.e6data.com`. The engineer's real email is never exposed to your organization. 3. **You can revoke at any time.** A per-tenant **block** is honoured immediately and propagated to every workspace. A blocked Support User cannot log in to your organization and cannot self-rejoin. ## Lifecycle at a glance A Support User moves through a small set of states: * **Bound** - added to your organization, assigned an alias, and granted the configured support role. Once bound, the Support User is synced to every workspace automatically (typically within about 30 seconds). * **Blocked** - denied entry to your organization. Roles are preserved so you can restore access by unblocking later, but login and tenant access are refused immediately. * **Removed** - the alias is released back to the pool for reuse, while an alias-history record is retained so past audit entries still resolve correctly. A Support User becomes bound in one of two ways: an admin invites them (the default for planned engagements), or - for incident response - an e6data engineer self-binds. A self-bind is always rejected if your organization has blocked that engineer. See [Enable, audit, and block support access](/query-engine/guides/security/support-access/enable-audit-block.md). ## In this section * [Enable, audit, and block support access](/query-engine/guides/security/support-access/enable-audit-block.md) - add, block, unblock, and audit Support Users. * [Privacy controls](/query-engine/guides/security/support-access/privacy-controls.md) - the per-tenant alias model, what is and isn't recorded, and the security guarantees. ## FAQ **Can the e6data engineer see my data without me knowing?** No. Every action is attributed to `support-N` in your audit log, including query execution, and the Support User is surfaced in your user list and workspace member list with `isSupportUser: true`. **Can a Support User add themselves to my organization without us doing anything?** Yes, by design - for incident response, e6data engineers can self-bind. But only `@e6x.io` / `@e6data.com` accounts can; every self-bind is audited; any past or future block of that engineer rejects the self-bind; and you can block them immediately afterwards if the engagement was not authorized. **What if we want a read-only Support User?** Pass `"roles": ["viewer"]` (or any custom read-only role you've defined) when adding the Support User. Note that a self-bind currently always uses the default support role; if you require read-only by default for self-binds, contact your account team. **The same alias number was used by a different engineer a year ago. Will that confuse our audit log?** No. The audit log resolves `support-N` to the engineer who held that alias **at the timestamp of the action**, through the alias-history record. Reuse is safe - see [Privacy controls](/query-engine/guides/security/support-access/privacy-controls.md#historical-correctness). **How do I get the real identity behind a `support-N` alias if compliance requires it?** Contact your e6data account team. The mapping is preserved internally and is available under your standard support contract. --- # 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.md?ask=&goal= ``` `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.