The security model, plainly
No product is unbreakable, and Verfy does not claim to be. This page says what Verfy protects, how, and where its protection ends. The full threat model is in docs/THREAT_MODEL.md in the repository.
proves A receipt shows
- which tool call passed through Verfy, when, and in which session;
- the verdict, the rules that fired and the hash of the policy that decided it;
- the digest of the tool definition in use, and the hash of the arguments and result;
- that the device holding the key signed it, and that no receipt in the chain was changed, removed or reordered since.
does not prove A receipt cannot show
- what a tool or MCP server did internally after it was called;
- actions that never went through the Verfy hook or gateway;
- that the device itself was not compromised when it signed;
- that a whole ledger was not deleted and restarted, or rebuilt and re-signed by someone holding the device key (only an outside copy, such as the receipts already synced to Verfy Team, shows that).
Controls in place
Tenant isolation
Row-level security on every table, keyed to the signed-in user's memberships. Server routes check the organization again. Cross-tenant access is covered by automated tests on real Postgres.
No direct writes
Browsers can only read. Every change goes through a database function that checks the caller's role and writes an audit entry in the same transaction.
Append-only evidence
Receipts, published policy versions and the audit log cannot be updated or deleted, not even with the server's secret key.
Device keys
Receipts are signed on the device with Ed25519. The server stores only public keys and re-verifies every signature and hash link on upload.
Secrets
The secret Supabase key is used only in server code after Verfy has authenticated the caller. Device tokens and invitation tokens are stored as SHA-256 hashes.
Web hardening
Per-request CSP nonces, HSTS, frame blocking, strict referrer policy, origin checks on every cookie-authenticated change, schema validation with size limits, and safe error messages.
Rate limits
Shared Postgres counters across serverless instances for sign-in, enrollment, ingest, exports and public endpoints. If the limiter fails, requests are refused, not let through.
Supply chain
Pinned dependencies with a lockfile, dependency audit and secret scanning in CI, and a CLI with no required third-party packages.
Known limits
- Guard rules are pattern matching. A determined attacker can phrase a command Verfy does not recognise; unknown risky patterns are not assumed safe, but Verfy is not a sandbox.
- The scanner finds known warning signs. A clean scan does not mean a tool is safe.
- DDoS protection depends on your hosting plan and settings. Verfy adds application rate limits; it does not replace a firewall.
- No independent penetration test has been performed yet. Treat this release as an MVP and review it before relying on it.
Report a vulnerability
Please report security issues privately, not in public issues. Use GitHub's private vulnerability reporting on the Verfy repository (Security tab, "Report a vulnerability"), or the contact in SECURITY.md. Include steps to reproduce and the version you tested. We will acknowledge your report and keep you informed while we fix it.
Please do not test against other people's deployments, access data that is not yours, or degrade service for others.