Trust

Security

Last updated: June 13, 2026

Custosa sits between your data and your AI and enforces access, redaction, and evidence on every record at runtime. Its security properties are structural, not bolted on. This page describes how the system is built; for our compliance posture see the trust center, and for what we do and do not defend against see the threat model.

01Content-free by design

Custosa's evidence ledger, policy store, and metering are content-free: they hold verdict metadata, hashes, signatures, and counts, never record content. Inspection runs in memory in the data plane, which sits inside your environment, so records never leave your boundary. The managed control plane (Custosa Cloud) receives only content-free verdict evidence, never the records themselves. A short-lived decision cache holds verdicts, not content.

02Fail-closed by default

If the inspection pipeline cannot reach a verdict (a policy timeout, an unreachable relationship resolver, a pack error), the request is blocked rather than allowed through. This behavior is a core invariant and is not overridable by configuration. Safety is the default state, not an option.

03Deterministic policy

Access decisions are evaluated with a formal policy engine (Cedar), not a model or heuristic. The same inputs always produce the same decision, which means every verdict is explainable and reproducible. Custosa does not "guess" whether data is sensitive; it applies the rules you configure.

04Tamper-evident evidence

Every decision is recorded as a signed, hash-chained evidence entry. Each entry is signed with HMAC-SHA256 and carries an integrity hash that links to the previous entry, so altering or removing any entry breaks the chain. Evidence can be verified independently and offline, without contacting Custosa, and an optional RFC 3161 timestamp can anchor an entry to a trusted time source. The ledger is append-only; it stores verdicts and metadata, never record content.

05Encryption

Data in transit is protected with TLS. Data at rest is encrypted with AES-256-GCM using per-tenant data keys, with envelope encryption backed by HashiCorp Vault or a cloud KMS. Bring-your-own-key (BYOK) is available on request.

06Authentication & access control

Callers authenticate with 256-bit API keys (validated in constant time), signed JWTs, mutual TLS, or OIDC against your identity provider (for example Okta, Azure AD, or Auth0). Each verified identity carries roles that map to a five-level clearance lattice governing what that actor may see, and Custosa's own database roles follow least privilege: evidence is insert-only, with no update or delete.

07Tenant isolation & key management

Tenants are isolated at the database layer with PostgreSQL row-level security, with tenant identity enforced as the first filter on every query. Each tenant has its own encryption key and its own signing key, derived with HKDF-SHA256 and held in a bounded, time-limited in-memory cache that is zeroed on eviction. Signing keys are rotated on a 90-day schedule, and prior keys remain available so historical evidence stays verifiable.

08Deployment & data residency

Custosa ships as a single data-plane binary that always runs inside your environment. It can be delivered as Custosa Cloud (a managed control plane with the data plane running in your boundary) or fully self-managed on-premises, including air-gapped deployments. A FIPS build is available, and deployments can be region-matched to your data residency requirements. In on-premises mode, your records never leave your infrastructure.

09Reporting a vulnerability

If you believe you have found a security issue, please contact hello@custosa.com. We welcome coordinated disclosure and will work with you on timing.