Security and audit
The isolation posture as it stands: what is implemented, what has been verified, and what is in the way of the rest.
Why
Each control states whether it is implemented, verified, or neither. Implemented and unverified is the honest description of most of this list.
Writes are validated against the engineering rules and then refused, because no database has been configured for this environment.
Controls
8
Implemented
7
Independently verified
2
Live isolation tests passing
0
8 skipped
P1 security certification is not granted
Controls
| Control | Implemented | Verified | What exists | What is missing |
|---|---|---|---|---|
| Row-level security on every tenant table | Yes | Not yet | Policies are written and forced rather than merely enabled. A test reads every migration and fails if a table is created without both. | no database to run the live isolation tests against |
| Tenant context set per transaction | Yes | Not yet | Every repository call opens a transaction and sets the three session settings locally, so a pooled connection cannot carry one request's tenant into the next. | verified against a recording executor, never against PostgreSQL |
| No privileged connection for tenant work | Yes | Yes | The session helper refuses an executor marked privileged, and a test asserts that nothing is sent when it does. | nothing |
| Append-only audit trail | Yes | Not yet | No application role is granted update or delete on the audit table and no policy permits either. | no database |
| Support access off by default | Yes | Not yet | A support principal with no unexpired grant matches no policy. Grants are capped at twenty-four hours by a check constraint. | no database |
| Secrets held outside the repository | Yes | Yes | A secrets provider interface with an AWS Secrets Manager implementation. No secret is in Git, in an environment variable on Vercel, or in this interface. | nothing |
| Separation of duties enforced by the database | Yes | Not yet | Constraints refuse an author recorded as their own checker or approver, an approval with no independent check, and a comment closed by anybody but its raiser. | no database |
| Authentication | No | Not yet | Clerk is the approved provider. The identity boundary and the tenant context it feeds are written; no instance exists and nothing has authenticated. | no Clerk instance |
Support access grants
None is active. A support principal with no grant reads nothing.
Refused attempts recorded
The audit trail holds 3 refusals. These are the rows an audit actually asks about.
- support.elevate Refused: no active support grant
- deliverable.approve Refused: the author may not approve their own deliverable
- document.process Refused: the scan was measured as unreadable
Secrets
No application secret is held in Git, in a Vercel environment variable, or anywhere this interface can read. The secrets provider resolves them at runtime from an external manager, and a provider that cannot resolve one refuses rather than falling back to a default.