Security & Trust
Governance runs before output reaches you, not after.
KeepWise is built around a control layer that inspects and, where needed, corrects AI output before it's released — not a policy document describing what should happen, but code that runs on every governed request.
- Input
- Check
- Evidence
- Approval
- Record
Control status
16 controls. Here is what each one has proven.
Each control is held to an evidence bar — does it work, does it fail correctly, does it fail closed, is it provably wired to what it protects, is there an audit trail — rather than asserted once. Where the proof stops, the row says so.
13 of 16 controls fully evidenced, 2 of 16 evidenced with a documented limitation, 1 of 16 partially evidenced.
Designed against SOC 2 criteria; not independently audited. The status below is our own evidence, not an auditor's opinion.
| Control | |
|---|---|
| No unverified output reaches a user | |
| GATE-01Path completenessEvidenced | Evidenced |
| GATE-02InterceptionEvidenced | Evidenced |
| GATE-03Fail-closed defaultsEvidenced | Evidenced |
| GATE-04Mutation authorizationPartial 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. | Partial |
| Proof is tamper-evident and complete | |
| GATE-05Ledger immutabilityEvidenced | Evidenced |
| GATE-06Hash-chain integrityEvidenced | Evidenced |
| GATE-07Audit completenessEvidenced | Evidenced |
| GATE-08Out-of-database genesis anchorEvidenced | Evidenced |
| Cross-cutting failure classes | |
| GATE-09ConcurrencyEvidenced | Evidenced |
| GATE-10Crash and partial-failure handlingDocumented limitation A simultaneous dual failure (the 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. Reviewed and accepted, on the record. | Documented limitation |
| GATE-11IdempotencyEvidenced | Evidenced |
| GATE-12Resource boundsEvidenced | Evidenced |
| GATE-13Migration integrityEvidenced | Evidenced |
| Meta and frontier controls | |
| GATE-14Coverage map (fails CI on any unmapped governed path)Evidenced | Evidenced |
| GATE-15Prompt-injection resistanceDocumented limitation 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. Reviewed and accepted, on the record. | Documented limitation |
| GATE-16Cross-tenant isolationEvidenced | Evidenced |
How each control is built and evidenced, and how they map to SOC 2 criteria: technical white paper.
What the controls do
What the controls protect, in plain terms.
Check
Checked before release
Responses are held in a buffer while automatic checks run — citation verification, fabricated-action detection, behavioral checks. Fabricated-action claims and rule violations are corrected or blocked 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 changing the response.
Approval
Human approval on consequential actions
Actions with real side effects don't execute automatically — they're proposed, then require a human's explicit approval before anything runs.
Record
Tamper-evident audit trail
Audit events for governed actions are written to a hash-chained ledger — each record is cryptographically linked to the one before it, so an edited or deleted entry breaks the chain and is detectable. Approval decisions are kept in a separate append-only approvals record that standard database roles cannot edit or delete; that record is not hash-chained.
Record
Legal Hold
A legal hold freezes a client or matter: nothing under it can be deleted or moved until the hold is lifted. Lifting it needs a second attorney or admin to approve; if you are the only one, the lift waits 72 hours and you can cancel it. Holds are enforced by the database itself, and a blocked delete or move is written to the audit trail. On every plan. Placed and lifted by attorneys and admins (account owners).
Input
Roles within a firm
Work is organized by company and project. Owners and attorneys can see every company and project in the firm, and roles (owner, attorney, paralegal, staff) decide what each person can do. From a client's settings, an owner or attorney can give or remove a paralegal's or staff member's access to that client and its current matters; matters created later need access given again. A firm cannot yet change how owners and attorneys see the firm's work: the app has no setting for it.
Infrastructure and data handling
Who holds your data, and for how long.
- SOC 2
- Supabase, Northflank, Vercel, Stripe, Resend, Anthropic and Brave each state that they hold a SOC 2 Type II attestation or report. Not every provider we use does, and KeepWise itself has not been independently audited.
- Training
- Client data is never used to train AI models.
- Retention
- AI providers retain prompts and responses only for safety and abuse monitoring, and for different periods: up to 30 days at Anthropic, up to 55 days at Google, and longer only for content a provider flags for a policy violation (Anthropic: up to 2 years). Web-search queries are retained by Brave for up to 90 days, and case-law lookups by CourtListener for up to 12 weeks. Per-provider figures are on the Subprocessors page.
- Dependencies
- Dependencies in our application repositories are checked for known vulnerabilities automatically at least once a week.
Full subprocessor list, with data received and retention: Subprocessors.