> ## Documentation Index
> Fetch the complete documentation index at: https://docs.enfors.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Tenancy, Privacy & PII

> How Enfors isolates data and protects personal information by default.

Enfors is built for enterprise data boundaries. Isolation and privacy are enforced at
the platform level, not left to application code.

## Tenant isolation

Every record is scoped to three identifiers:

* **Tenant** — the organization,
* **Workspace** — a workspace within the tenant,
* **User** — the owning person.

In the relational database this is enforced with **Row-Level Security (RLS)** policies,
so queries can only ever see data within their scope. In the graph database, every node
carries `tenant_id`, `workspace_id`, and `user_id`, and queries must filter by at least
`tenant_id` — preventing cross-tenant leakage by construction.

## PII removal in durable records

Personal data is **scrubbed at intake** — the same scrubbing logic runs in both the ingest
backend and the read API, so the **durable decision ledger and API responses** do not carry
raw PII.

<Frame caption="A generated report with PII redacted">
  <img src="https://mintcdn.com/enfors/EStKoMAmv9k4MqOd/images/generated-report.svg?fit=max&auto=format&n=EStKoMAmv9k4MqOd&q=85&s=f408ece45bff418d96380e12de904951" alt="Report with PII redacted" width="1200" height="750" data-path="images/generated-report.svg" />
</Frame>

<Warning>
  **Be precise about layers.** To capture a decision at all, the gateway necessarily handles
  the raw prompt and response — including any PII they contain — in transit. Raw content is
  logged at the **gateway layer** with **short, 14-day retention**, encrypted at
  rest. PII is removed when the decision is reconstructed into the **durable ledger**. So:
  raw content exists briefly at the edge; the long-lived record is scrubbed. See
  [Data captured vs. not captured](/security/data-handling) for the full breakdown.
</Warning>

## Large-payload offloading

Rather than keeping large request/response bodies inline in the database, Enfors offloads
them to secure object storage and references them by key. This keeps the ledger lean and
limits where sensitive content can live.

## Data residency, encryption & retention

| Control                            | Implementation                                                  |
| ---------------------------------- | --------------------------------------------------------------- |
| **Data residency**                 | AWS us-east-1 (N. Virginia). No cross-region replication.       |
| **Encryption in transit**          | HTTPS / TLS 1.3 for all gateway traffic.                        |
| **Encryption at rest**             | AES-256 across the session database, logs, queues, and backups. |
| **Retention — gateway logs**       | 14 days.                                                        |
| **Retention — DB backups**         | 14 days.                                                        |
| **Retention — queue (main / DLQ)** | 4 days / 14 days.                                               |
| **Access to customer data**        | Engineering on-call only                                        |

<Note>
  RLS policy definitions and a full security/IT review package are available on request — see
  [Deployment & Security](/security/overview).
</Note>

## Authentication

* **Enfors UI** authenticates users via **SSO** (with enterprise SSO — Google and
  Okta OIDC). See [SSO](/integrations/sso).
* **The MCP server** is protected by **OAuth 2.0 / SSO**. See [MCP overview](/mcp/overview).
* **Ingest endpoints** use API-key / internal authentication.

<Note>
  Privacy and isolation are defaults, not options. There is no configuration required to
  get tenant scoping or PII scrubbing — they are always on.
</Note>