Skip to content
Tervos Protocol

Auditor-Ready Evidence for Your AI Agents

Your agent platform keeps an audit log. That log is a database the platform promises not to edit. When a regulator, customer, or court asks “prove these are the actions your agents actually took”, a platform’s promise is not proof.

Tervos makes the log itself tamper-evident, and makes the proof portable:

  1. Hash chain — every event records the hash of the previous one. Mutating, deleting, or reordering any past event breaks the chain.
  2. Signed evidence bundles — export any range of the log as a single JSON file, signed with an agent’s Ed25519 key (every Tervos agent has a did:key identity).
  3. Offline verification — anyone can verify the bundle with npx @tervos/verify, on any machine, with no Tervos installation and no network access.

Why now

Section titled “Why now”
  • The EU AI Act’s high-risk obligations reach full enforcement on August 2, 2026. Record-keeping obligations require technical evidence of enforcement — policy documents without verifiable logs don’t clear the bar.
  • NIST’s AI Agent Standards Initiative names agent identity and security as core pillars.
  • Emerging assurance standards require cryptographically verifiable agent identities rather than bearer tokens. Tervos agents are did:key identities natively.

The five-minute version

Section titled “The five-minute version”
Terminal window
# 1. Run a governed organization (or attach Tervos to an existing one)
npx tervos init --template demo
tervos start --dev


# 2. Check the chain
tervos audit --verify
# ✓ did:key:z6Mk…: chain intact — 23 events verified


# 3. Export signed evidence
tervos export-evidence --sign-as ceo -o evidence.json


# 4. Verify it anywhere — different machine, no Tervos install, no network
npx @tervos/verify evidence.json
# Chain:     ✓ valid
# Signature: ✓ valid — signed by did:key:z6Mk…

What’s in a bundle

Section titled “What’s in a bundle”

tervos-evidence/v1 is a single JSON document containing:

FieldPurpose
eventsThe raw events: who (emittedBy, a DID), what (type, payload), when (timestamp), in order (sequenceNumber)
prevHash / hash per eventThe hash chain — recomputed from scratch during verification
chainHead, rangeWhat slice of the log this bundle covers
chainValidThe chain state at export time (export refuses tampered logs by default)
signatureEd25519 signature over the bundle digest, with the signer’s DID

Every policy decision (policy.evaluated), every approval (approval.granted/denied), every budget charge (budget.charged) is an event in the chain — so the bundle is evidence of enforcement, not just activity.

Periodic attestations

Section titled “Periodic attestations”

A chain proves internal consistency, but a log truncated from the end is still internally consistent. Close that gap by periodically publishing signed chain-head receipts:

Terminal window
tervos attest --sign-as ceo -o receipts/$(date +%Y-%m-%d).json

Store receipts somewhere the log’s operator can’t rewrite (a different system, a ticket, an email). Any later log that doesn’t extend a receipted chain head is provably truncated.

Honest limitations

Section titled “Honest limitations”
  • Tamper-evidence, not tamper-proofing: the chain detects after-the-fact edits. An attacker who controls the machine while events are written can write false events. Mitigate with periodic attestations and by running the event store with least privilege.
  • Events written by pre-0.2.0 versions of Tervos have no hash fields; verification skips them as a legacy prefix and reports the count.
  • A signature proves the bundle was signed by the holder of that DID’s key — distribute and pin your org’s DIDs through a channel you trust.

Next steps

Section titled “Next steps”