Record of controls — rev. 2026-08
Trust & verification
This page states what Attestive actually enforces, how, and where that stops — not a marketing summary of it. Where a claim depends on something you can check yourself, we link to the thing to check.
The verifier is public. Don’t take our word for it.
The code that decides whether a decision log is intact — attestive-verify— is open source, published independently of our backend, and has zero runtime dependencies beyond Node’s built-in cryptomodule. It’s short enough to read end to end in a few minutes. Run it against your own exported evidence, or read it, rather than trust a claim on this page.
Edit any past entry above and watch it stop matching its own stored hash — that mismatch is exactly what attestive-verify detects. The stored hash never gets silently updated to match your edit; only the live recomputation changes, which is the whole point.
- 01
Append-only, hash-chained records
Attestive logs AI agent decisions in an append-only, hash-chained format. Each record’s hash is computed from its own content plus the previous record’s hash — altering, deleting, or reordering any past entry breaks the chain in a way that’s independently detectable, not just logged as “audit trail” in the usual sense.
- 02
No UPDATE or DELETE, enforced at the database
No application credential, including our own backend’s service-role key, can update or delete a logged decision. This is enforced at the database permission level — no
UPDATE/DELETEgrant exists for any application-facing role on the decisions table — not just by application logic.Noted for the recordThe one honest exception is database-owner-level access, a structural property of any Postgres database and separate from anything the application or its normal operators touch. - 03
Tenant isolation at the database, not just the app
Each customer’s data is isolated at the database level via row-level security tied to organization membership — not just application-level filtering.
- 04
API keys: hashed, shown once
API access is authenticated via hashed API keys. Raw keys are shown once at creation and never stored or retrievable again.
- 05
Hosting
Hosted on Supabase, with data stored in AWS
eu-central-1(Frankfurt, EU).
What we deliberately don’t claim
We are not currently SOC 2 or ISO 27001 certified. We believe the open, independently-verifiable design above provides a meaningful trust signal on its own, and we’re happy to discuss our security posture in more depth with any customer evaluating us.
Questions about anything on this page? hello@attestive.io