Trust & security
What's actually true about how govern.sh is built
Last updated July 2, 2026
Our position
We would rather tell you exactly what's implemented today than put a certification badge on our homepage that isn't backed by an actual audit. The lists below are split into what's live now and what isn't — nothing here is aspirational language dressed up as fact.
Implemented today
- Workspace data is isolated with Postgres row-level security — every table scopes to the requesting user's workspace at the database layer, not just in application code.
- Every action receipt persisted to your audit log is signed with govern.sh's Ed25519 platform key. You can re-verify any receipt's signature directly from its detail drawer.
- API keys are hashed with SHA-256 before storage. The plaintext key is shown once at creation and is not retrievable afterward, including by us.
- A strict, nonce-based Content-Security-Policy, HSTS, and standard security headers are set on every response.
- Sign-in, sign-up, and API-key creation are rate-limited to blunt credential-stuffing and abuse.
- The audit log (action_receipts) is append-only at the database level — rows can be inserted and read, never updated or deleted.
- A real v1 API is live at /api/v1 — bearer-token authenticated with your API key, running the same policy engine the dashboard uses. It isn't a preview; actions submitted through it are actually evaluated and persisted.
Compliance & identity roadmap
- SOC 2 Type II — not yet started. We will not claim this certification on our site until an independent auditor has issued a report.
- Single sign-on (SAML / OIDC / Google / GitHub) — email and password only today; OAuth and SAML are on the near-term roadmap.
- Multi-factor authentication.
- A published bug bounty program and independent penetration test.
How receipt signing works
Every action a policy evaluates and every agent identity we mint produces a receipt. That receipt is signed server-side with govern.sh's Ed25519 signing key over a canonical representation of the outcome — the agent, the action, the tool, the input/output hashes, and the timestamp. The signature is stored alongside the receipt. Opening any receipt in your audit log re-runs that verification live against the current signing key, so you can see for yourself whether the record has been tampered with.
Each agent also holds its own Ed25519 identity keypair, generated at creation time. The private half is shown to you exactly once and is never stored or re-displayed — we have no way to recover it, by design.
Reporting a vulnerability
If you find a security issue, please report it responsibly. See /.well-known/security.txt for the current disclosure contact, or reach us directly at security@govern.sh.