Security & deployment
Security reviews stall on hand-waving. This page states exactly where Clarté's boundaries sit, which layer actually enforces access, and what stays under your control — so your security, identity, and infrastructure owners can verify rather than trust.
Deployment shape
Clarté deploys as software into a Kubernetes environment you approve, with customer-controlled and European-cloud deployment paths. There is no vendor-hosted control plane: the operator, control plane, and query surface all run inside your cluster, next to your data.
Two layers of governance
Many stacks claim enforcement in the SQL layer while the storage layer quietly trusts everyone. Clarté is explicit about which layer holds.
LAYER 1 · THE REAL BOUNDARY
For every session, the credential broker mints a short-lived object-storage credential — 15-minute maximum lifetime — whose scope covers only the prefixes the session's roles permit. The engine holds nothing broader.
Enforcement happens in your object store's own access control: a read outside scope is refused by storage itself, not by a rewrite rule. Every enforcement claim is backed by a credential boundary, not a string check.
LAYER 2 · DEFENSE IN DEPTH
Session-scoped views encode row filters, column masks, and dataset denials, so queries are shaped by policy before planning. A deliberately narrow safety gate rejects mutation, external reads, and rebinding attempts before the engine prepares the statement.
This layer improves precision and ergonomics — it is not the load-bearing wall, and we do not pretend otherwise.
FAIL-CLOSEDIf the policy engine is unavailable or a policy bundle fails verification, new governed sessions are refused. There is no fallback to an ungoverned mode.
Trust boundaries
Four boundaries carry the platform. Each one is enforced with its own identity — nothing rides on ambient trust.
USER → PLATFORM
Every session authenticates with a token from your OIDC issuer. Roles come from claims you control.
QUERY SURFACE → CONTROL PLANE
The query surface authenticates with its own service identity and forwards the user's token — which the control plane independently revalidates before minting any credential.
PLATFORM → CATALOG
User sessions never touch PostgreSQL directly. Only the platform's service identity reads and writes catalog state.
PLATFORM → OBJECT STORE
Only the control plane can mint scoped credentials. Query pods hold no long-lived storage credentials at all.
04 / What you control directly
Clarté is opinionated about the governed path and deliberately unopinionated about whose infrastructure it runs on.
Operational discipline
The catalog is the most operationally important state in the platform, and it is treated that way from the first deployment.
Primary plus synchronous replica — a committed transaction is never traded for write speed.
Continuous backup with WAL archiving to a separate bucket with separate credentials.
An automated drill restores the catalog and validates it against object-store state. Failures page someone — recovery is rehearsed, not assumed.
A scheduled job reconciles storage against the catalog so failed writes cannot accumulate silently.
Deleted data files are quarantined for 14 days (configurable) before hard deletion.
Every execution attempt is recorded with identity, policy version, and credential ID — 365-day default retention.
In transit, external endpoints use TLS. At rest, data uses your object store's native encryption, with Parquet-level encryption available where per-file keys are required.
Next step
Bring your security, identity, and infrastructure owners. The evaluation walks the exact boundaries on this page against a workload you actually run.