01Trust boundary
The Custosa data plane runs inside your environment. Within that boundary, a request flows through the gateway, the policy engine, the decision step, and the evidence builder, and is written to encrypted storage. Systems Custosa integrates with (your identity provider, your relationship store, compliance-export tooling, monitoring, and any external key service) sit outside that boundary and are treated as external trust dependencies.
02Attacker model & assumptions
We assume Custosa runs in your VPC or a managed environment; that it reads identity from external providers (for example Okta, Azure AD, or LDAP), with relationship-store adapters (SpiceDB, OpenFGA) on the roadmap; that it produces evidence consumed by audit automation; and that its evidence ledger is content-free. The analysis below uses STRIDE across the policy engine, evidence chain, data layer, relationship resolver, and transport.
03What Custosa defends against
| Category | Mitigation |
|---|---|
| Spoofing | 256-bit API keys, cryptographic JWT/OIDC validation, identity-provider adapter isolation, and a resolver circuit breaker that fails closed. |
| Tampering | Row-level security, admin RBAC, insert-only policy versioning with rollback, and signed policy bundles. |
| Repudiation | Hash-chained ledger, HMAC-SHA256 signing with versioned keys, optional RFC 3161 timestamping, and an append-only schema. |
| Information disclosure | Content-free evidence (a content hash, never the content), verdict-only ledger entries, and logging and metrics that exclude record content. |
| Denial of service | Per-key and per-tenant rate limits, request size caps, a bounded worker pool, and per-record evaluation timeouts that fail closed. |
| Elevation of privilege | Scoped API keys and RBAC, dashboard SSO, and least-privilege database roles. |
04What is explicitly out of scope
We state our non-goals plainly so you can reason about residual risk:
- Identity-provider security. Custosa trusts the identities and relationships your IdP asserts. If your IdP is compromised, authorization is compromised. This is by design.
- Data-source and downstream security. We assume your data sources (for example FHIR or EDI systems) and your downstream applications and models are themselves secured.
- Volumetric network DDoS. Network-layer flooding is the responsibility of your cloud or ISP.
- Physical security and customer-side insider threat.
Custosa is not an end-to-end privacy guarantee: it does not address timing or side-channel attacks, or a misconfigured downstream system, and evidence is only as trustworthy as the keys used to sign it.
05Accepted trade-offs
Some deliberate trade-offs are worth knowing. By default tenants share a key-encryption key in the managed key service, with BYOK available for stronger separation. These are conscious choices, documented rather than hidden.