Every decision your AI agents make becomes tamper-evident, independently verifiable evidence — the audit trail the EU AI Act (Article 12) requires. And because it's anchored outside our systems, the record is provable even against us.
Part of the Verified Digital Agents (VDA) platform.
A complete, tamper-evident record of what every agent did and the rule it acted under — hand it straight to an auditor.
Anyone can check the evidence themselves — offline, with our open-source SDK, no private key, and without trusting VDA.
The trail is anchored to independent authorities we don't control, so even VDA can't quietly rewrite history.
prepare → sign locally → submit, and check_valid confirms your key against your published did:web (issuer_verified). For threat models where the vendor must never hold the key at all — and the way a credential authority proves a credential was signed by it, not us.| Tier | Price | Seals / month | Access |
|---|---|---|---|
| Sealed | Free | 5,000 | Self-serve, instant, no human |
| Anchored | from €50 / month | 5,000 included | Contact us to enable (concierge today) |
| Enterprise | Talk to us | Volume-negotiated | Contact us |
The security architecture, in full — every claim above, made concrete.
Each decision is Ed25519-signed and hash-chained to the ones before it. Altering any field, or deleting/reordering any record, breaks verification.
Verification runs on standard crypto with no VDA dependency — a third party reproduces the signed bytes and checks the chain themselves.
Signing keys are versioned verification methods under a published W3C DID — did:web:witness.getvda.ai. Keys rotate and revoke transparently (an append-only rotation log).
Each record binds the DID + key version, so historical records verify against the key that was valid at signing time — rotations don't break old evidence.
On a fixed cadence (at least hourly), the chain head is anchored to two independent RFC-3161 timestamping authorities — DigiCert and Sectigo — and recorded in the public, append-only Sigstore Rekor transparency log (operated by the Linux Foundation).
Availability quorum: a window is validly anchored on Rekor + at least one TSA. Both TSAs are attempted and all attestations stored, so one authority being down never leaves a gap.
Between anchors, a just-sealed record is already tamper-evident by signature + hash-chain, and is covered by the next anchor. The honest claim is "anchored within the cadence"; verification reports each record as anchored or pending — never an unstated asterisk.
Not us alone. VDA holds the key, so we can re-sign a fully valid alternate chain — but that changes the chain head, and the original head is pinned outside our systems. To rewrite a past record undetected, an attacker would have to compromise the public Sigstore/Rekor transparency log (and slip past its independent monitors) and get an independent commercial RFC-3161 timestamping authority to attest the forged head at the original time — simultaneously, none of it under VDA's control. The trail is anchored to Rekor plus DigiCert and Sectigo; a valid anchor requires Rekor + at least one TSA, so forgery means subverting Rekor and a TSA together. (A maximum-assurance option — anchoring to the Bitcoin blockchain via OpenTimestamps — is on the roadmap.)
Our open-source SDK verifies a record offline, with zero calls to VDA: npm i vda-witness or pip install "vda-witness[verify]". It checks the Ed25519 signature, the hash-chain, the DID key that was valid at signing time, and the anchor — the Rekor signed entry timestamp against Rekor's pinned key and the RFC-3161 token against a pinned TSA root (DigiCert today) — either fully air-gapped from a bundled proof or by re-fetching the Rekor inclusion from rekor.sigstore.dev directly. Never a Witness endpoint.
The verdict is one of three, so it can't over- or under-claim: ANCHORED_VALID, SIGNED_PENDING (signed, honestly not-yet-anchored), or BROKEN (with the reason). Identical result in JS and Python. MCP clients get 16 tools at /api/witness/mcp: the shaped seals (seal_hitl_decision, seal_agent_action, seal_attestation), admission credentials (issue_admission_credential, check_valid, revoke_admission_credential), whoami (cross-service key resolution), plus seal, verify, report, list_records, get_record, get_test_key, and the renew_* pair. Customer-controlled signing is a REST flow — prepare → sign → submit.
Each account is an opaque, server-minted ID (a ULID) that is part of the signed record — not just a database column. A seal is bound to the account behind your API credential; there is nowhere in the request to name a different account, so cross-tenant forgery is structurally impossible, not merely rejected.
Reads are filtered to your authorized accounts at the data layer and re-checked against each record's signed account, so a tampered routing column still can't leak another tenant's records. Display names are mutable and DB-only; they never enter a signed record.
An agent binds an Ed25519 controller key it holds to a durable account. When its API key expires, it renews itself — challenge, sign (vda.witness.renew/1|<accountId>|<nonce>), fresh key — into the same account and the same chain, with no human and no standing long-lived secret. A leaked key dies within 24h; the account and its evidence chain never do.
list_records returns your chains and record summaries; get_record returns the full signed body — your agent's own reasoning, inputs, and actionProposed — everything needed to verify offline. Account-scoped and structurally isolated: there is nowhere to name another account.
Witness is opinionated about evidentiary completeness: instead of one generic seal, it publishes shaped skills that require what an auditor actually needs. seal_hitl_decision demands the cited policy and the system-of-record artifacts the human saw; seal_agent_action separates external evidence (content-addressed, hashed) from computed parameters; seal_attestation records a fact as-of a time. A human decision sealed with no evidence and no stated reason is rejected — the gap can't be sealed silently. This guidance lives in the agent card + tool schemas, so every caller sees the correct pattern by default.
An admission credential is a sealed Witness record — not a separate document. Environment operators hold only the credential id and ask Witness check_valid, getting one canonical answer (valid / revoked / expired / not_found), so every enforcer is identically correct and the meaning of "valid" evolves in one place. Revocation is a new superseding record; validity is computed, never mutated. A credential can honestly record a provisional state (e.g. a sandbox that hasn't passed), not only a passing one — honesty over a schema that would force a lie.
For issuer-authenticity that is provable even against Witness, seal with your own key — Witness never holds it. prepare (Witness assembles the shaped body, so enforcement still holds) → sign locally → submit. Then check_valid resolves the issuer's did:web and confirms the signing key is published there, returning issuer_verified. Records still hash-chain and anchor, so you get both issuer-authenticity and tamper-evidence. This is how a credential authority proves a credential was signed by it, not merely by us.
The sealed trail is the record-keeping Article 12 requires. Witness generates an Article 12 Evidence Report mapping each decision to its governing rule, each line traceable to a signed, anchored record. The report is scopeable by chainKey (and date range), so an account with many chains gets a clean per-chain report. It is evidence, not a compliance certificate — attestation stays a human act.
seal_hitl_decision/seal_agent_action/seal_attestation), admission credentials (issue_admission_credential/check_valid/revoke_admission_credential), reading their own trail, self-provisioning + no-human key renewal, and customer-controlled signing (prepare/sign/submit). Sibling suite services resolve a presented key via whoami (the sanctioned cross-service auth path). 16 MCP tools at /api/witness/mcp.
Write code, connect it to your AI with no code, or just ask your assistant.
No human in the loop. To seal you need a key; verify is public, so you can succeed in 30 seconds with no key at all.
SEALED · signed + offline-verifiable · NOT externally anchored (terminal on this tier)
Bind a controller key (an Ed25519 public JWK your agent holds) and the account becomes durable — no auto-expiry — and self-renewable forever with no human. It's still Sealed (not anchored) — durability is the account surviving, not anchoring.
You're sealed — anchor it, and even we can't rewrite it. Want the Anchored tier (externally committed, provable even against us)? It's concierge-provisioned — Talk to us →
await witness.seal(decision, rule);
// verify offline — no VDA dependency:
import { offlineVerify } from "vda-witness/verify";
const v = await offlineVerify(bundle);
// v.state === "ANCHORED_VALID"
v1.0.0 live on npm & PyPI. Grab a Sealed-tier key above, then seal, read your own trail, and renew unattended. Sealing is fail-open; verifying is offline.
Add as a connector — 16 tools natively: an agent can self-provision a durable account, seal with the shaped skills, issue & check admission credentials, resolve its own key (whoami), read its own trail, renew unattended, verify & report — no human. Claude / Cursor / VS Code configs →
Add VDA Witness to my agent so every decision is sealed to a tamper-evident audit trail. Install vda-witness and wrap my decision calls. Docs: witness.getvda.ai/llms.txt
Witness is the evidence layer of Verified Digital Agents — rules, enforcement, and audit-ready EU AI Act & GDPR evidence for your agents.