You are being asked to approve a system you cannot inspect.

1. 1Day 0

   The request lands on your desk

   A team wants to point an AI platform at the company’s meeting transcripts, documents, and possibly email. You are asked to approve it. What you have been given is a datasheet, and what you need is an architecture.

   What you have to answer

   • What categories of data does it actually ingest, and where does each one live?
   • Is there a classification model, or does everything get treated the same?
   • What is considered sensitive, and who decided?

   The layer that answers it

   Data classification

   An 18-category sensitivity taxonomy declared once in a shared package and shipped to every service with parity tests, so the same tag means the same thing everywhere. Three handling shapes per category — index and gate at read, withhold from the index entirely, or redact — configurable per category, with the most restrictive defaults reserved for board material and highly-confidential M&A.

   What changes for you

   You start the review from a published classification model instead of reverse-engineering one out of a sales call.

2. 2The review

   The question that decides everything

   Before anything else, you need to know whether one customer can ever see another’s data — and whether that guarantee survives a developer having a bad afternoon.

   What you have to answer

   • Is isolation enforced in application code, or below it?
   • What happens when someone writes a query and forgets the tenant filter?
   • Can the application’s own database role bypass the control?

   The layer that answers it

   Tenant isolation

   Isolation lives in the database, not in the application. Every domain table carries a non-null tenant id under Row-Level Security with FORCE, the runtime role is privilege-split so it cannot bypass RLS, a boot-time assertion refuses to start in production if a service connects as a superuser, and CI fails any migration that creates a domain table without RLS.

   Tenant isolation is enforced by the database, not by application code

   Live, test-pinned

   Every domain table carries tenant_id NOT NULL under Postgres Row-Level Security with FORCE ROW LEVEL SECURITY, keyed on a transaction-local GUC. A privilege split means the runtime role cannot bypass RLS, a boot-time assertion refuses to start in production if a service connects as a superuser or BYPASSRLS role, and CI fails any migration that creates a domain table without RLS.

   White paper — Tenant isolation

   The tenant claim is verified against live membership at every mint

   Live, test-pinned

   The issuer computes an eligible set from live membership data and mints the tenant claim only for a tenant in that set, re-verifying at every exchange and refresh and failing closed to invalid_grant — never to a different tenant. One tenant per token is an absolute invariant; there are no multi-tenant tokens.

   White paper — Identity & tenancy

   Every isolation decision fails closed

   Live, test-pinned

   Unset tenant context returns zero rows. Unset scope context returns zero rows. An unclassified document is not yet visible. Unestablished clearance excludes the row. A missing budget denies the run. A config read failure degrades scopes to org-only.

   White paper — Security design principles

   What changes for you

   You are reviewing a mechanism rather than a promise. The failure mode you are worried about is structurally prevented, not merely discouraged by a code review.

3. 3The harder question

   Who inside the company sees what

   Cross-tenant isolation is table stakes. The question that actually keeps you up is subtler: does a private email, or a one-to-one conversation, become visible to a colleague because the system decided it was interesting?

   What you have to answer

   • Is there a notion of ownership inside a tenant, or only sensitivity?
   • Does intelligence derived from private content inherit that privacy?
   • What is switched on today, and what is not?

   The layer that answers it

   Workspace scopes and inheritance

   Scope labels enforced by a restrictive RLS policy AND-ed beneath the tenant policy, so it can only ever narrow visibility and fails closed when unset. Derived artifacts — signals, findings, entities, rollups — inherit their evidence’s scope on a most-restrictive-wins basis and never default to organization-wide. Personal and team evidence is excluded from the shared graph outright rather than filtered inside it.

   In-tenant workspace isolation

   Built, gated off

   Scope labels enforced by an AS RESTRICTIVE RLS policy AND-ed beneath the tenant policy, so it can only ever narrow visibility and fails closed on unset context. Committed across eleven services. Derived artifacts inherit their evidence’s scope, most-restrictive-wins, and never default to organization-wide.

   White paper — Workspace isolation

   Scope isolation outside Postgres

   Partial

   The search index and graph store have no row-level security, so scope isolation there is application-layer until per-scope indices and partitions land. The interim mitigation is deliberately blunt: personal and team evidence is excluded from the shared graph entirely rather than filtered within it.

   White paper — Control status & enablement

   What changes for you

   You get the real activation status rather than a roadmap answer, so you can plan around it instead of discovering it in production.

4. 4The procurement question

   Where the data physically goes

   Legal wants the sub-processor list. Your own policy wants to know whether corpus content reaches a third-party model. Both need a straight answer, and neither will accept "it’s secure".

   What you have to answer

   • Which third parties see content, in the default configuration?
   • Can this run entirely inside our boundary — and is that the same product?
   • What is a guarantee, and what is a configuration I have to make myself?

   The layer that answers it

   Deployment models and model routing

   The data plane is identical in SaaS and on-premises — the code does not branch on deployment mode, and air-gapped operation is supported with no outbound calls at startup and offline licence validation. Sensitivity classification routes to a cloud model by default; pointing it at a local model keeps content in-boundary, and whether any cloud provider is reachable at all is a per-deployment key decision.

   The same data plane runs air-gapped

   Live, test-pinned

   A must-follow rule forbids cloud-vendor-locked primitives in the data plane: S3-compatible storage, OIDC, SMTP, Vault, OpenTelemetry, PostgreSQL, NATS JetStream. CI rejects forbidden cloud SDK imports and an air-gap startup test asserts services reach readiness with no external DNS resolution. Offline licence validation; telemetry is opt-out with no degradation.

   White paper — Deployment, residency & sub-processors

   Keeping content away from third-party models

   Partial

   Sensitivity classification routes by default to a cloud model, so in the default SaaS configuration content reaches a third-party LLM sub-processor. Overriding the model to a local one keeps content in-boundary; whether any cloud provider is reachable at all is a per-deployment key configuration. The classifier sends only content plus structural metadata and receives a schema-validated tag set.

   White paper — Deployment, residency & sub-processors

   What changes for you

   You get a decision you own, stated plainly, instead of a guarantee you would have had to take on trust and could not have verified.

5. 5Week 1

   Approved with conditions. Now you configure it.

   You have said yes, with conditions attached. What you do not want is a new identity island and a second key-custody problem to look after.

   What you have to answer

   • Does it federate with our identity provider, or invent its own?
   • Who holds the signing keys, and how often do they rotate?
   • What do we operate, and what does the vendor operate?

   The layer that answers it

   Identity and key management

   A single OIDC issuer with every service independently re-validating tokens against JWKS rather than trusting the gateway. Signing keys are EdDSA, held in Vault — your own Vault on-premises — rotated every 90 days with the previous key retained as validation-only for 30. Symmetric algorithms and hand-rolled JWT parsing are forbidden and linted out in CI.

   No service trusts the gateway

   Live, test-pinned

   Each service fetches and caches JWKS, verifies the signature by key id, validates issuer, audience and lifetime, rejects user tokens lacking a tenant claim, and checks a revocation deny-list fed by session-termination events. Hand-rolled JWT parsing is forbidden and CI-linted; symmetric signing algorithms are rejected outright.

   White paper — Architecture & trust boundaries

   Signing keys live in Vault and rotate on a schedule

   Live, test-pinned

   EdDSA signing keys held in HashiCorp Vault — the customer’s own Vault on-premises — rotated every 90 days with the previous key retained as validation-only for 30 days. Public keys are published at a JWKS endpoint. Provider and object-store credentials are Vault-issued, with a test pinning that connector tokens never reach Postgres.

   White paper — Encryption & key management

   What changes for you

   It plugs into the identity and secrets estate you already run. No new custody problem, and no service quietly trusting a header.

6. 6Day 2

   It is live. You need to know before someone tells you.

   The thing you fear now is not a dramatic breach — it is a quiet misconfiguration nobody notices for a quarter, or a credential-stuffing run that looks like ordinary login noise.

   What you have to answer

   • What is logged, and can I tell an attack from a misconfiguration?
   • Does my observability stack become a second, unprotected copy of the corpus?
   • Can a read of sensitive content ever happen without a record of it?

   The layer that answers it

   Audit and observability

   An append-only audit table with UPDATE forbidden and DELETE restricted to the retention worker. The audit event for a sensitivity-filtered read is emitted in the same transaction as the response, so the read cannot succeed without its record. Traces and logs carry IDs and counts only — never content or PII, verified by a per-service adversarial log test — and authentication failures are explicitly instrumented.

   Reads of sensitive content are audited in the same transaction

   Live, test-pinned

   Append-only audit table with UPDATE forbidden and DELETE permitted only to the retention worker. Every authentication event, authorization deny, cross-tenant admin action, and sensitivity-filtered read is recorded, with a 730-day minimum retention on intelligence reads. The audit event for a filtered read is emitted in the same transaction as the response.

   White paper — Audit & observability

   Logs and traces carry identifiers, never content

   Live, test-pinned

   One service is permitted to persist detected-PII position data; every other consumes only the derived tag set. PII text is excluded from logs, traces, and event payloads platform-wide, verified by a per-service adversarial log-output test. Trace attributes are restricted to IDs and counts.

   White paper — Audit & observability

   What changes for you

   Misconfiguration surfaces as a signal rather than as an anecdote a quarter later, and your telemetry does not become a second copy of the data you were protecting.

7. 7The audit

   Someone asks you to prove all of it

   A customer questionnaire, a regulator, or your own internal audit. They do not want assurances — they want to know who accessed what, whether a deletion request truly propagated, and whether you can demonstrate it.

   What you have to answer

   • Can I produce an access record for a specific piece of content?
   • When we delete a source, does the intelligence derived from it also go?
   • Can we service a subject-access request without a manual archaeology project?

   The layer that answers it

   Data lifecycle and evidence

   A 730-day minimum retention on intelligence-read events. Deletion cascades from source to classifications, entity references, signals, findings, and reports, pinned by a cross-service invariant test, with tombstones that suppress late-arriving derivation events so erasure is ordering-independent. Subject-access requests cascade by participant label and now reach derived intelligence through provenance back-links.

   Deleting a source retracts everything derived from it

   Live, test-pinned

   Deletion cascades from source to classifications, entity references, signals, findings, and reports, pinned by a cross-service invariant test. Tombstones recorded on the delete event suppress later-arriving derivation events, making erasure ordering-independent. Each service declares a tenant-purge SLA, with a reconciliation job that flags stragglers.

   White paper — Data lifecycle & your rights

   Cross-tenant access holds no privileged credential

   Live, test-pinned

   The parent view never holds a credential that reads children. There is no service-side spanning read path: every spanning read resolves through the requesting user’s own per-child membership and scope grants at read time, gated by a consent state machine with defined revocation semantics.

   White paper — Multi-organization access

   What changes for you

   Compliance evidence assembles continuously instead of being gathered under deadline. Audit preparation stops being a project with its own Gantt chart.

Amber marks a constraint or a decision you own, not a defect. A strict content-stays-local posture is achievable and is the on-premises target — it is configuration, and it should be confirmed per deployment rather than assumed.

What this actually looks like.