Security overview

This document summarizes how GovAI approaches security posture for enterprise review. It is descriptive documentation for operators and security teams; it does not replace your own threat modeling or contractual commitments.

Security controls explorer

Themes for enterprise security review — deep dives in docs/security/.

Search

Trust boundaries

3

• API key → tenant mappingLedger isolation from GOVAI_API_KEYS_JSON; not from X-GovAI-Project.
• Fail-closed verdictsBLOCKED / INVALID halt promotion; missing evidence never silently passes.
• Hash chain verificationGET /verify, /verify-log, and CLI pack verification.

Operations

3

• Readiness vs livenessLoad balancers should use GET /ready, not /health alone.
• Secrets managementAPI keys, JWT JWKS, Stripe webhook signing — see docs/security/.
• Responsible disclosureSecurity reports via trust center responsible disclosure path.

Scope#

GovAI spans an audit HTTP service (Rust), Python tooling (CLI, evidence packs, reports), optional hosted backends, and CI integrations (for example GitHub Actions). Each layer has distinct assets, trust boundaries, and configuration surfaces.

The GovBase dashboard (dashboard/ Next.js app) may be deployed alongside or separately from the audit API; public /docs and /help routes render Markdown from docs/ and do not widen ledger trust boundaries by themselves.

Principles#

• Fail-closed governance: missing evidence, missing approvals, or integrity failures surface as BLOCKED or INVALID in the authoritative compliance projection (GET /compliance-summary) and in matching CLI exit codes (trust-model.md, cli-reference.md).
• Evidence integrity: bundles and digests are first-class; tampering or mismatch is treated as a security-relevant failure mode (GET /verify, GET /verify-log, govai verify-evidence-pack).
• Tenant isolation: operational tenant boundaries for ledger-backed routes are derived from server-side API key mapping, not client-supplied project headers alone. See tenant-isolation.md and root SECURITY.md.
• Readiness vs liveness: GET /health is liveness-only after startup; GET /ready is the operator-grade readiness probe (Postgres, migrations, ledger). Do not point load balancers only at /health for dependency safety (hosted-backend-deployment.md).

Where to read next#

Out of scope#

This repository documentation does not certify legal compliance, SOC 2, ISO 27001, or FedRAMP. Use ../trust/compliance-mapping.md as a mapping aid, not an attestation.