How Proofable is built
No implicit authority
Every action is checked against identity, proof, policy, and the permission an owner granted, at the moment it runs. Signing in, owning an account, or holding a key never grants authority by itself.Private by default
Proofs and receipts stay private and offchain unless you share them. Public pages, public indexing, IPFS, and blockchain records are explicit choices.Minimum disclosure
A check returns the smallest claim the decision needs. Apps and agents get the result, not the source material.Server-side credentials
Connected tools run without handing credentials to the model. Credentials are resolved inside trusted server execution and never placed in a tool schema, proof, browser response, or public record.Auditable decisions
Important decisions produce proofs you can inspect, verify, and revoke without exposing the data behind them.Invariants
These hold everywhere in Proofable. A deviation from any of them is a bug.- No implicit authority. Identity, ownership, sign-in, or possession never grants authority by itself.
- Minimum disclosure. A check returns the minimum claim or result the decision requires.
- Private and offchain by default. Public exposure, indexing, IPFS, and chain anchoring are explicit choices.
- Secrets never become agent context. Credentials stay inside trusted server execution.
- Evidence is not public proof. Private evidence can exist to keep a proof auditable. Public readers get the claim, status, or proof, not the source material.
- Every privileged action has a policy decision. Subject, resource, action, policy, and context produce allow, deny, or approval. The proof records the decision.
- Permission is narrower than ownership. Agents act only inside the permission they were given. Spend, secrets, tool access, and high-risk actions stay bounded.
- Auditability without surveillance. Records show who authorized what, under which policy, against which proof, and what happened. They are not a store for request bodies, prompts, OAuth payloads, or provider responses.
One model for every decision
Sign-in, connected apps, payments, agents, and jobs all follow the same path:- Sensitive evidence is examined inside a trusted boundary.
- It is reduced to a claim or proof.
- The claim is checked against policy and the permission an owner granted.
- The action is allowed, denied, or sent for approval.
- A proof records what was decided.
- The evidence stays protected, or is deleted according to its retention rule.
Proof visibility
Proofs are private unless you choose otherwise. Visibility modes and defaults are in Proofs.Smart contract audit
SafeStack AI audited the Proofable smart contracts in March 2026. The audit found no critical, high, medium, or low severity issues. Scope:ProofableVerifierRegistry.sol, ProofableVoucherHub.sol, ProofableVoucherSpoke.sol, and ProofableToken.sol. Status is listed on the Trust Center. Email dev@proofable.me for the full report.
Integration checklist
- Decide access with a server-side gate check, not a browser flag.
- Respect each check’s freshness window.
- Run interactive checks through Hosted Verify at
/verify. - Read the verifier list from the live catalog.
- Keep proofs private unless your product needs them public.
- Keep access keys and other secrets on servers.
Report a vulnerability
Email dev@proofable.me and do not post it publicly. The full policy is in Security disclosure.Policies
Privacy Policy
What Proofable processes and why.
Terms of Use
The terms for using Proofable.
Security disclosure
How to report a vulnerability.
DMCA
Copyright notices and takedowns.