Security overview

The nine layers a request passes through, and what each one is defending.

Security here is layered rather than perimeter-based: a request is authenticated at the edge, scoped to exactly one tenant, and that scope is re-asserted at every store it touches.

The layers

LayerControl
1 — EdgeTLS 1.2/1.3, HTTP redirected to HTTPS, per-IP rate limiting, unknown hosts dropped
2 — GatewayAPI-key authentication, per-key quotas, header sanitisation, request signing
3 — IdentityOne verification chokepoint for JWTs, API keys and signed internal calls
4 — AuthorizationTenant isolation, roles, resource grants, key scopes
5 — RoutingMemory resolution with an ownership guard, read-only gating, circuit breaking
6 — StoresMandatory tenant filters on every query; TLS to managed databases
7 — PerimeterSecret and PII detection, classification, value-level masking, model gating
8 — SecretsEnvelope encryption with a separately-held master key
9 — AuditImmutable, tenant-scoped record of every privileged action

Header sanitisation

The gateway strips client-supplied trust headers and re-injects verified identity from the resolved credential. After identity is established, the middleware also removes every tenant-bearing header from the request scope.

The effect is that a handler which mistakenly reads a raw header sees nothing, rather than seeing whatever the caller sent. Spoofing a tenant is not "blocked" — it is structurally unavailable.

Credentials

KindReachesNotes
ck_live_Everything in the tenantStored hashed; shown once
ck_eph_Everything in the tenant, for 24 hoursFor CI and short-lived automation
mk_Exactly one memoryRejected everywhere else
OAuth 2 applicationWhat its scopes allowMachine-to-machine

Rotation mints the replacement before revoking the original, so a rotating client gets an overlap window rather than an outage. Revocation goes to the gateway first and the database second, so there is no window in which a revoked key still authenticates.

What is not there

Stated plainly, because a security review will find these anyway and it is better they come from us:

  • No prompt-injection or jailbreak scanning. The perimeter prevents leaks; it does not detect adversarial prompts.
  • No client-side encryption or content-blind storage. Chordian reads your content in order to index and reason over it. If you need the vendor to be unable to read it, the answer is an own-infrastructure deployment, not a cryptographic one.
  • No selective erasure. Whole-tenant purge exists; per-record deletion does not.
  • No SOC 2 or HIPAA certification. The control mapping exists and the architecture supports it; the attestations do not exist yet.
Was this page helpful?
Report an issue

On this page