Skip to content

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.

/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).

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.

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.

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.

The Google OAuth mailbox tile doesn’t open a form — it starts a consent flow:

  1. 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.
  2. 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”.
  3. 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.

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.