Technical white paper
The control layer, in detail.
This page is written for the technical and compliance reviewers on the other side of a vendor questionnaire. It describes what's built, what's proven, and where the proof currently stops.
- Input
- Check
- Evidence
- Approval
- Record
Interception, not detection
A generated response is held in a buffer while a set of deterministic checks run against it — citation verification, fabricated-action detection, behavioral-compliance pattern checks. Deterministic checks that fail rewrite or block the response before release; if the citation check can't run, the response's citations show no verdict and the response says they could not be checked; and the model-based behavioral review is recorded in the audit trail rather than altering the response. Raw output that fails a blocking check is never returned to the caller and never persisted. This is a structural property of the request path, not a policy applied after the fact.
Tamper-evident audit ledger
Audit events for governed actions are recorded as a hash-chained sequence — each record's hash incorporates the previous record's hash, so altering or deleting a past entry breaks every hash after it. The chain's genesis value is recorded outside the database, so the chain can't be silently re-originated from within it. Approval decisions are held in a separate approvals record that standard database roles cannot edit or delete; it is not part of the hash chain. Standard database roles cannot edit or delete ledger rows; only a superuser-level credential can, and that bypass is a named, accepted exception, not a hidden one.
Control-contract coverage
The control layer is organized as 16 named controls, each evidenced against a six-dimension bar (does it work, does it fail correctly, does it fail closed, is it provably wired to what it claims to protect, and is there an audit trail for it) rather than asserted once and left unverified. As of this writing: 13 of 16 controls are fully evidenced, 2 of 16 are evidenced with a documented, founder-approved limitation on a narrow, named dimension — not silently accepted, written down — and 1 of 16 is partially evidenced.
SOC 2 criteria mapping
Designed against SOC 2 criteria; not independently audited.
The controls above are organized against the common-criteria families a SOC 2 Type II audit would examine: CC6.1 (logical access), CC6.6 (boundary protection), and CC6.7 (data-in-transit-and-at-rest protection), plus a standing audit-trail criterion. This mapping describes how the system is designed and what evidence exists internally for each control. It is not a substitute for, and does not imply, an independent SOC 2 examination of KeepWise itself. Several of the providers KeepWise runs on state that they hold a SOC 2 Type II attestation or report; they are named on Security & Trust.
Honest gaps
Two controls carry a documented limitation rather than full evidence: the crash-handling path for a simultaneous dual failure (primary action and its own audit write both failing at once) has no durable ledger record for that specific compound event, by design — writing one would risk infinite recursion; and the model's own resistance to a hijacked instruction embedded in untrusted content is backed by the deterministic control layer's effect-blocking, not by a standing, versioned adversarial test suite. Both are reviewed and accepted, on the record, rather than silently carried.
One control is only partially evidenced: negative authorization — every action that changes state checks the caller's authority first. Real, database-backed tests cover 11 of the 19 route files that change state today; the remainder is tracked as open work, not counted as proven.