Verify us. Don’t just trust us.

Last updated August 2, 2026

Permisyn’s whole premise is that a security claim should be checkable, not just asserted. This page describes what we actually do, as plainly as we can — including the parts that are ordinary rather than exceptional, because overstating them would defeat the point.

Signed, independently verifiable receipts

Every authorized or denied call is signed with your organization’s own Ed25519 keypair. Verifying a receipt requires only your organization’s public key — never a Permisyn secret — so a customer, an auditor, or a regulator can confirm a decision is genuine and unaltered without trusting our dashboard. Periodically, a summary of your organization’s activity is anchored into a public transparency log, timestamped against the Bitcoin blockchain, so the historical record can’t be quietly rewritten after the fact.

Encryption

All traffic to and from Permisyn is encrypted in transit (TLS). Provider keys stored in vault mode, and each organization’s own signing key, are encrypted at rest using symmetric encryption (Fernet, which is AES-128 plus a message authentication code) derived from an application-level secret we manage operationally. This is standard encryption-at-rest, not a hardware security module or a zero-knowledge scheme — we’re stating that plainly rather than implying stronger guarantees than what’s actually in place.

If you’d rather we never handle your provider key at all, vaultless mode is the default we recommend: you send your own key with each call, we use it only for that one request, and it is never written to a database.

Enforced Secrets

Our secret-redaction feature can run in a true zero-knowledge mode by default: a local sidecar computes one-way HMAC fingerprints of secrets you want redacted, and Permisyn only ever sees and stores those fingerprints — never the underlying secret. An optional hosted mode trades some of that guarantee for convenience (Permisyn can then compute fingerprints itself); we tell customers this explicitly rather than letting "zero-knowledge" quietly stop being true once they opt in.

Access control

• Session auth for the browser dashboard uses an HttpOnly cookie — never readable by page JavaScript, which closes off an entire class of token-theft-via-XSS attack.
• API keys for programmatic access, rotatable at any time from Settings.
• Kill switch and freeze controls at the agent, user, team, and org level, enforced by the same code path the dashboard button and the automated escalation logic both call — so there’s one enforcement path to reason about, not two that can drift apart.
• Agent passports constrain which models, providers, tools, and budgets an agent may use, checked before the call reaches the upstream provider.

Compliance evidence, not a certification claim

Permisyn can generate a signed attestation that maps your organization’s own real enforcement history — kill-switch events, enforced passports, signed runs, redaction events — onto the controls of a named framework (SOC 2, HIPAA, the EU AI Act, and others). It is a cryptographically signed statement of what actually happened in your org, useful as evidence for your own audit process. Permisyn is not itself SOC 2 or HIPAA certified, and this tool is not a substitute for an independent third-party audit — we want that distinction to be unambiguous rather than something a customer discovers later.

Infrastructure

The service runs on Microsoft Azure (application hosting and database) and Vercel (this website and dashboard). We are a young, small team — we do not yet publish a formal uptime SLA, and we say so plainly on our pricing and terms pages rather than implying enterprise-scale guarantees we haven’t yet proven in production.

Reporting a vulnerability

Our public /breakitarena is a sanctioned, sandboxed environment for testing our authorization and signature logic — if you find something there, the scoreboard will already have recorded it, and we’d still like to hear from you. For anything outside that arena — a real vulnerability affecting the live product or customer data — please email amitcool5115@gmail.com directly rather than testing against live customer accounts. We’ll respond personally.

Subprocessors

See the "Who else sees data, and why" section of our Privacy Policy for the full, current list.