Features Pricing Docs Security For Managed AI Healthcare Log in Start free
Security

How we protect your data and your receipts

Authproof Cloud is built on cryptographic primitives, not policy promises. Here is exactly what we do and how it works.

Cryptographic Foundation
The primitives underneath everything
🔏

ECDSA P-256 Signatures

Every delegation receipt is signed using ECDSA P-256 via the Web Crypto API. This is the same elliptic curve algorithm used in banking and government digital signatures. The user's private key never leaves their hardware secure enclave.

#️⃣

SHA-256 Hashing

Operator instructions, scope schemas, and model state commitments are hashed using SHA-256 before being included in the receipt. Any modification to the original content produces a completely different hash and is immediately detectable.

🕐

RFC 3161 Timestamps

Every log entry can carry a timestamp token from an RFC 3161 timestamping authority. The SDK presence-checks these tokens: it confirms the token bytes contain the entry's digest. It does not verify the TSA's signature or certificate chain, so a forged token embedding the digest would pass. Treat timestamps as audit support, not as independently verified legal proof.

🔗

Append-Only Log

The action log is append-only by design. Entries can never be modified or deleted — only added. Every entry contains a hash of the previous entry. Modifying any record breaks the chain and is immediately detectable by any verifier.

Infrastructure
How the platform is built and secured
What How
Data in transit All API traffic uses TLS 1.3. No unencrypted connections are accepted. HTTPS is enforced on all endpoints.
Data at rest All data stored in Supabase PostgreSQL is encrypted at rest using AES-256. Receipt hashes, verification records, and account data are encrypted in the database.
API authentication API keys are hashed before storage using bcrypt. Plain text API keys are never stored. Keys are transmitted only over HTTPS and never logged.
Infrastructure provider Authproof Cloud runs on Vercel for compute and Supabase for database storage. Both providers maintain SOC 2 Type II certification. Data is stored in US East region by default.
Dependency management The open source SDK has 1,392 JS tests across 23 suites with zero failures, plus 36 Python tests, all green. Dependencies are reviewed and pinned. The SDK is MIT licensed and auditable by anyone.
Secret management Environment variables and secrets are managed through Vercel's encrypted environment system. No secrets are committed to the repository.
Data Handling
What data we store and what we do not
What we store
  • Receipt hashes SHA-256 fingerprints of your delegation receipts
  • Verification event records Decision, risk score, and timestamp for each verification
  • Tool call metadata Tool name, arguments hash, and result hash
  • Account information Email address, API key hash, and plan
  • Session state summaries Aggregated trust and risk scores per session
What we never store
  • Raw PHI or patient data Of any kind, from any source
  • Plain text operator instructions Only the SHA-256 hash is stored
  • Private keys These never leave the user's hardware
  • Raw tool call arguments Only the hash
  • Payment card information Handled entirely by Stripe
Note: If you include raw sensitive data in receipt metadata fields, that is your data. We recommend only including identifiers and hashes in receipt metadata — never raw PHI or PII.
Key Custody
Key custody and user control

Hardware custody is the recommended model: WebAuthn and FIDO2 keep your private signing key in your device's secure enclave — the same protected chip that stores Face ID and fingerprint data on modern devices. The enclave performs the signing operation internally, and the key is never exported, transmitted, or accessible to Authproof. The SDK also supports software key generation, where the key is only as safe as the machine holding it — use hardware custody for anything that matters.

This means that even if Authproof Cloud's infrastructure were completely compromised, an attacker could not forge delegation receipts signed by your users. The receipts require the user's hardware key to create.

Responsible Disclosure
Security vulnerabilities

If you discover a security vulnerability in Authproof Cloud or the open source SDK, please report it to ryan@authproof.dev with the subject line Security Vulnerability Report.

We will acknowledge your report within 24 hours and provide a timeline for resolution. We do not currently have a formal bug bounty program, but we are grateful for responsible disclosure and will credit researchers who report valid findings.

Please do not publicly disclose vulnerabilities until we have had reasonable time to address them.

Transparency
What we are working toward

We believe in transparency about where we are and where we are going. These are security and compliance milestones we have not yet reached:

  • SOC 2 Type II audit — planned. We are building toward a formal SOC 2 audit. Until that audit is complete, our SOC 2 claims reflect our control design, not a certified attestation.
  • Penetration test — not yet completed. An independent penetration test of the Authproof Cloud API and infrastructure is on our roadmap.
  • On-chain log anchoring — in development. Publishing receipt hashes to a public blockchain would remove Authproof as a trusted party in the audit chain entirely. This is our roadmap item for removing centralized log dependency.
  • Bug bounty program — planned. A formal bug bounty program with defined rewards is planned once the product reaches sufficient maturity.
  • Independent security audit — not done. No third-party security audit or penetration test has been completed yet; the test suite (1,392 JS + 36 Python, all green) is the current assurance baseline.
  • Key management story — missing. Key rotation, KMS/HSM integration, and compromise procedures are not part of the SDK.
  • Canonical signatures and JS/Python interop — planned. The JS SDK signs insertion-order JSON, and the Python SDK is a partial port that cannot verify JS receipts. A JWS/COSE canonical profile would fix both; until then, do not mix SDKs across the same receipts.
  • Full RFC 3161 signature verification — out of scope. The SDK presence-checks timestamp tokens (digest in token bytes) but does not validate the TSA's signature chain.

Security questions or concerns?

Contact ryan@authproof.dev

We respond to all security inquiries within 24 hours.