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. That hashed content includes the input evidence the agent acted on, not just its output — the context behind a decision is protected the same way the decision itself is.
- 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 recordThis guarantee covers application-facing credentials only — no role the application itself uses, including our own backend’s service-role key, can update or delete a logged decision. It does not extend to database-owner-level access, a structural property of any Postgres database that no grant can revoke. Today there is also no external witness or independent anchor for the chain’s head hash — so someone with database-owner-level access could, in principle, alter history and regenerate an internally-consistent replacement chain that verification alone would not catch. That is a real limitation, not a hypothetical, and it is not yet closed. - 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). - 06
Integrations
Logging a decision is one function call, wherever your agent’s decisions actually happen. Two integrations are live today, each a real, runnable example — not a proof-of-concept — published publicly so you can read exactly how it works before you build against it.
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