Last reviewed 7 August 2026
This page states what is implemented, what is not, and how to report a problem. Where a control is built but not switched on, that is said rather than glossed over.
Use GitHub's private vulnerability reporting on the repository — Security → Report a vulnerability. That opens a private thread with the maintainer.
| Stage | Target |
|---|---|
| Acknowledgement | 3 business days |
| Triage and severity | 7 business days |
| Fix for critical or high | typically 14 days |
| Disclosure | coordinated with the reporter after a fix exists |
Reporters are credited unless they prefer otherwise. Please allow a reasonable window before public disclosure. Full policy in SECURITY.md.
Two direct dependencies. A Postgres driver and a SAML library. Distributed tracing, TOTP and encryption at rest are implemented against the standard library rather than by adding packages — the authentication path is where a compromised dependency is worth the most to an attacker.
Releases are signed with keyless signing, and each carries an SPDX software bill of materials. Verification steps are in SECURITY.md.
Controls are pinned by tests that state the failure they prevent, not just the behaviour they expect. A benign ATT&CK-mapped validation suite runs hourly against the live deployment and alerts if any verdict changes.
Authorisation is central rather than per-handler, so a new endpoint cannot forget its own check. The tenant comes from the calling credential and is part of the database query, so another customer's record identifier resolves to not found instead of confirming that it exists. Identity is resolved on every request, so a revoked key stops working on the next call.
Agents authenticate as service accounts and can never hold an interactive session, which is what makes a second factor enforceable for people without breaking any agent.
This is the part worth reading closely, because it is the part most providers leave out.
Direct database access by the operator is announced before it is taken; the announcement enters the tamper-evident audit chain and is published to a witness outside the host. It is observed independently through the database's own connection log, by a component whose credential can do nothing but report. The two are reconciled: a session with no announcement covering it becomes an audit record and an alert.
The audit chain's head is published to that external witness, which refuses a chain that got shorter and refuses a different head for an index it already recorded. An operator with root can rewrite local history; they cannot make the witness agree.
| Technical claims | Each claim with the command that checks it |
| Threat model | What it defends against, and what it does not |
| Access control | Who can reach customer data, and what is recorded |
| Incident response | Severity, notification deadlines, recovery |
| Design decisions | Why it is built this way, including what was rejected |