The Estate
The Estate is the organisation-wide layer beneath all workspaces, reached from the System group in the workspace picker. Where a workspace is one team’s scoped view of the data, the Estate is the platform’s single set of shared catalogues: in its own words, “Every catalogue, taxonomy, and reference table managed once across the whole platform.” Register a source, host, or credential here once, and any workspace can draw on it.
flowchart LR
subgraph estate ["Estate — managed once"]
SRC["Content sources"]
HST["Database hosts"]
AIC["AI providers & models"]
DET["Categories · Analysis plans<br/>Entities · Analyzers"]
CRED["Credentials"]
end
W["Workspaces<br/>each imports what it needs"]
SRC -->|"source links"| W
HST -->|"host links"| W
AIC -->|"provider & model links"| W
DET -->|"read by every workspace"| W
CRED -.-> SRC
CRED -.-> HST
CRED -.-> AIC
Access requires at least one estate.* permission; each surface then has its own permission set. This page covers the Estate’s home and its data inventory — sources, hosts, and credentials. The detection and governance catalogues have their own page.
The Estate home
Section titled “The Estate home”/estate opens a cross-resource dashboard — “sources, hosts, chats, and library across every workspace, scored against the estate-default category weights” — with a verdict hero, per-domain cards (Content, Databases, AI, Library), and recent activity. A Configuration health badge in the header flags when the shipped catalogue (categories, analyzers) is out of sync with this installation — its checklist tells you what to sync.
Below the dashboard, the Estate management section lists every catalogue as a card, grouped into Inventory (Sources, Database hosts, Credentials), Detection (Categories, Entities, Analysis plans — plus a Discovered entities card whenever entities are waiting for review), Organisation, Global facts (Countries, Jurisdictions, Locations — seeded geographic reference data), and Reports (Baseline risk).
Content sources
Section titled “Content sources”Path: /estate/content (Overview · Sources) · Permissions: estate.content.source:*
The platform-wide source catalogue: “This page manages the Content Sources for the entire platform — every workspace draws from the same catalogue.” The Sources table ranks by effective risk, with high-risk rows striped, and filters by name, status, and kind.
Add Source opens a kind picker — each kind has its own configuration form:
| Kind | Notes |
|---|---|
| S3 Bucket & Compatible | Bucket, region, AWS credential; optional endpoint/path-style for MinIO-style stores; prefix and include/exclude filters |
| Azure Blob Storage, Google Cloud Storage | Cloud object stores |
| SharePoint, OneDrive for Business, Google Drive, Box | Document platforms |
| Gmail (OAuth) | One mailbox, connected by that user’s consent — see Connecting a Google mailbox |
| Gmail | Whole-domain access via a Google service account with domain-wide delegation |
| FTP / FTPS, SFTP (SSH), WebDAV, Network Attached Storage (SMB) | File servers |
| Active Storage | Enprivacy’s internal repository kind — used for uploads and redacted outputs |
Every source form shares the same spine: Source Details (name, description, location — or derive it from the provider region), a Discovery schedule (an incremental schedule plus an optional full-reconciliation schedule, with live cron validation), and a Health check schedule. Connection secrets are never entered on the source form — you pick an existing credential from a dropdown.
A source’s page has tabs for Overview (health, before/after risk, residency, schedules, top findings), Items, Config, Discoveries, Health checks, Tasks, and History. Header actions: Edit, Upload (for uploadable kinds), Refresh (incremental discovery), Full sync (full re-enumeration, reconciling removed items), and Run health check. Items browse in a column navigator; opening a file at estate scope shows summary details — the full document view lives in the workspaces that imported the source. Deleting a source is a soft discard, reversible from the catalogue’s Discarded filter.
Database hosts
Section titled “Database hosts”Path: /estate/database (Overview · Hosts) · Permissions: estate.database.host:*
The equivalent catalogue for structured data: “This page manages the Database Hosts for the entire platform.” Five engines are supported: PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, and Oracle.
Adding a host takes a connection string (URI form, e.g. postgres://server:5432/database) plus a Database user credential from the credential vault — a username/password on the credential overrides any embedded in the URL — and the same discovery and health-check schedules as sources.
A host’s page shows its engine, version, and schema/table counts, with a schema-tree explorer and tabs including Schemas, Schema Snapshots, Discoveries, Health checks, Tasks, and History. From here you can:
- Sync the host to re-discover its schemas.
- Sync Schema or Sample All Tables on a schema.
- Resample a table, or Upload Sample — “bring your own rows for this table without a live probe” — as CSV (header row matching column names) or JSON, up to 10,000 rows.
- Author schema snapshots by pasting or uploading DDL, for hosts you can’t probe live.
Sampled rows flow into the same analysis pipeline as documents — see The Ingestion Flow.
Credentials
Section titled “Credentials”Path: /estate/credentials · Permissions: estate.credentials:*
The estate’s secret vault: “Estate-global secrets that reach external systems. Rotate a row to update every consumer at once.” Credentials are created here and referenced everywhere else — source forms, host forms, and AI providers all pick from this vault, and one credential can serve any number of consumers. As the intro banner puts it: “Add a credential here once and attach it to as many estate-side sources, hosts, or providers as you need.”
The catalogue tracks each credential’s lifecycle — created, rotated, last used, expiry — with an expiry-horizon view and counts of credentials expiring within 30 days, never used, or never rotated. A credential’s page shows exactly which sources, hosts, and AI providers use it. Secret values are never displayed after saving; rotating replaces the secret in place so every consumer picks it up at once.
Five kinds exist: API key, AWS access key, Database user, Google OAuth client, and Google OAuth mailbox — the last one is special, below.
Connecting a Google mailbox
Section titled “Connecting a Google mailbox”The Google OAuth mailbox tile doesn’t open a form — it starts a consent flow:
- First create a Google OAuth client credential (client ID, client secret, and the Workspace domain it belongs to). Without one, the connect page prompts you to create it first.
- Choose Connect a Google mailbox, pick the client to consent under, and choose Connect with this client. You are sent to Google — “to grant read-only access to one mailbox in the client’s Workspace domain”.
- After consent, the mailbox appears as a credential (“Connected {email}”) and can be attached to a Gmail (OAuth) source.
The mailbox must belong to the client’s own Workspace domain — consent under the wrong account is rejected. Disconnecting a mailbox removes it from the catalogue and stops its use; this flow is entirely separate from how operators sign in to Enprivacy itself.
Baseline risk
Section titled “Baseline risk”Path: /estate/reports/risk · Permission: estate.reports:show
The estate-wide roll-up: every kept marker across every source and host, scored with the estate-default category weights — “the unweighted view”, as the page notes, since “each workspace’s residual risk lives under its own reports surface.” It shows the estate’s effective sensitivity with its PII/CII/Legal axes, severity distribution, a category treemap, top sources and hosts, and a geographic residency roll-up.
The Estate’s other half — categories, entities and the curation queue, analysis plans and analyzers, the AI catalogue, and organisations — is covered in Estate: Detection & Governance.