Security model

This page describes implemented controls. Where a control is partial or a dependency is unconfigured, it says so — the security review that matters is the one where the vendor's public description survives contact with the deployment.

Tenant isolationPermalink to this section

Five independent layers, any one of which would be sufficient alone. Row-level security on the database; a tenant resolved from the request before any handler runs and set on the database session; separate credentials for distinct jobs; enforced module boundaries; and schema-per-tenant available where an institution's policy requires physical separation.

EncryptionPermalink to this section

Sensitive identifiers are encrypted with three-tier envelope encryption under a data key belonging to the subject, not to the tenant or the table. Beside each ciphertext sits an HMAC blind index, which answers exact-match lookups without the plaintext being present or searchable.

AuthorizationPermalink to this section

Authentication is delegated to an OIDC provider; authorization belongs to the platform. Every API operation declares the permission it requires in the contract, the router registers each route with that declared permission, and a route with no declared permission fails a test rather than defaulting to open. Machine and human identities are distinct, and machine credentials never fall through to the OIDC path.

Tamper-evident auditPermalink to this section

The audit table is append-only — the application role holds no UPDATE or DELETE grant — and hash-chained per tenant, so a modification by anyone, including someone with direct database access, breaks every subsequent digest. A tenant can be given its own chain export to verify independently, which is what makes the claim checkable by the party relying on it.

RefusalsPermalink to this section

Several conditions cause the platform to refuse rather than proceed, and they are controls rather than limitations: a report whose schema is unconfirmed cannot be recorded as submitted, refused independently at the handler, the service and a database constraint; an unconfigured provider returns an explicit not-configured outcome rather than a pass; startup itself refuses to come up in some misconfigurations rather than running degraded in a way an operator would not notice.

Separation of dutiesPermalink to this section

Approval is a single generic maker-checker primitive used by every surface that needs four-eyes review, rather than a bespoke flow per feature. The proposer and approver must differ, and the proposal carries the full before-and-after so a reviewer sees the change itself. What the primitive cannot do is prevent an administrator granting one person both roles across a workflow — the permission reference exists partly so that combination is visible before it is granted.