Security & Assurance
A trust product earns trust by being audited — here is the dated-target plan to get there.
Confidential · June 2026 · Illustrative figures are placeholders. This document states current posture honestly and the funded plan to close the gap. Nothing here describes a completed third-party security review.
govrn.ai sells assurance. That sets a higher bar for us than for most early-stage software: the credibility of the product depends on the credibility of our own controls. This page is deliberately split into two parts — what is true today, and what the raise funds. We do not blur the line between them.
Current Posture (Honest)
What exists today is an architectural stance, not an audited control set.
Pointers, not payloads — enforced in the architecture. Aperture operates on metadata, not customer content. The engine stores and reasons over pointers, identifiers, counts, and configuration state; raw model inputs and outputs are not ingested. Forbidden content keys are rejected at the boundary so that payload data cannot enter the measurement path even by accident. This is described in detail in Aperture Architecture. It is the single most important property of the design, and the one we most want independently validated.
Single-tenant-in-your-cloud — the intent. The intended deployment model is a single tenant running inside the customer's own cloud boundary, so data residency and isolation are the customer's to govern. This is the architectural direction, not a shipped, multi-customer-proven posture.
What does NOT exist yet — stated plainly:
- No authentication or RBAC. There is no access-control layer in the current build.
- No multi-tenant isolation. The single-tenant intent is not yet enforced by a hardened isolation boundary.
- No immutable audit log. Actions are not yet recorded in a tamper-evident store.
- No secrets vault, SSO, or per-tenant key management.
- No third-party security review and no penetration test have been performed. There is no SOC 2 report. Any claim to the contrary would be false.
We are a pre-entity team of five (see Risks & FAQ). The controls above are roadmap, not operating fact.
The Assurance Roadmap
The hardening sequence is ordered so that isolation and identity land before audit and key management — you cannot meaningfully log or vault what you cannot first isolate and authenticate.
| Phase | Capability | Target |
|---|---|---|
| 1 | Multi-tenant isolation boundary | Funded post-raise |
| 2 | SSO / OIDC authentication | Funded post-raise |
| 3 | RBAC (role-scoped access) | Follows SSO |
| 4 | Immutable, tamper-evident audit log | Follows RBAC |
| 5 | Secrets vault + per-tenant key management | Follows audit log |
| 6 | Per-tenant pricing + provisioning | Follows isolation |
These are engineering commitments. The dates firm up against the funded build plan; we publish targets, then report against them.
Funded Commitments
The raise funds the independent validation that makes the posture above credible to an enterprise buyer:
- Independent third-party security review and penetration test. An outside firm, engaged after Phase 1–4 land, to attack the running system — not a self-assessment.
- SOC 2 Type I → Type II path. Type I attests the controls are designed; Type II attests they operate over time. We commit to the Type I readiness work first, then the observation window for Type II.
- Architecture audit of the "pointers, not payloads" guarantee. An independent review specifically targeting the boundary enforcement and forbidden-content-key rejection described in Aperture Architecture — the property the whole trust thesis rests on.
The principle is consistent with everything govrn stands for: the body that asserts a control is not the body that should attest it. We hold ourselves to that standard. This plan is how we earn the right to sell assurance.