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
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
Last modified on October 1, 2026
