How ProofLedger keeps your data safe
The trust layer for AI agents is only as good as its own security. Here is how identity, signatures, isolation, and data handling work — in plain terms.
Identity & signatures
Each agent has an Ed25519 keypair. Events are signed with the agent's private key — which never leaves the agent — and verified server-side against the registered public key. Verification findings are signed by per-verifier identity keys.
Tamper-evident ledger
Agent activity is recorded as an append-only, per-agent SHA-256 hash chain: each event commits to the one before it. Any edit, deletion, insertion, or reorder breaks verification. The ledger is append-only in application flows.
API key handling
API keys are shown once at creation and stored only as SHA-256 hashes. A key resolves to exactly one project and cannot act outside it. Revocation is immediate.
Tenant isolation
Every record is scoped to a project; every query filters on it, and an API key's project is authoritative over any client-supplied value. Row-Level Security is being rolled out as staged defense-in-depth.
Data minimization
Raw prompts and model inputs are not stored by default — ProofLedger records summaries, hashes, and metadata. Outcome and verification evidence is stored as hashes, never as raw payloads.
Retention
Event data is retained per plan and pruned by a daily job. Evidence records carry a retention policy. Customers control what they place in outcome and metadata fields.
Infrastructure
ProofLedger runs on Vercel (application) and Supabase PostgreSQL (data). Transactional email is sent via Resend; billing via Stripe. Secrets are held server-side and never returned after creation.
Responsible disclosure
Report a suspected vulnerability to info@tejos.co. We investigate every report, do not pursue researchers acting in good faith, and will acknowledge receipt.
Trust model — what we guarantee, and what we don’t
A trust product should be precise about its own guarantees. Here is exactly what ProofLedger does and does not provide today.
Guaranteed today
- + Events are signed with an Ed25519 key generated on the agent by default — the private key stays in your process; only the public key is registered.
- + The per-agent SHA-256 hash chain is tamper-evident: any edit, deletion, insertion, or reorder is detectable when the chain is verified.
- + You can verify a chain independently, offline, with the open-source SDK (`verifyEventChain`) against public keys you retain — you do not have to trust our dashboard.
- + Every record is project-scoped; an API key's project is authoritative over any client-supplied value.
Not yet — don’t rely on it
- – Not globally immutable. The chain is stored in our database and is not yet externally anchored (transparency log / timestamp authority), so tamper-evidence relies on you verifying against public keys you keep.
- – Enforcement is cooperative. The policy engine evaluates and records decisions; in `enforce` mode the SDK halts your agent, but ProofLedger is not an inline gateway and cannot stop an agent that ignores the SDK.
- – The trust score is a transparent heuristic, not a validated risk model — use it as a signal, not a control.
- – ProofLedger records evidence; it does not assert or certify regulatory compliance.
On the roadmap (Enterprise)
External chain anchoring (transparency log / timestamp authority) · Customer-managed & hardware-backed signing keys (BYOK/HSM) · Row-Level Security enforced in production (staged defense-in-depth) · SSO/SAML, data-residency regions, and SOC 2 — for the Enterprise edition
Security questions or a disclosure? info@tejos.co