Checking evidence
Ask the chain what a piece of evidence proves: audit entries, agent terms, settlements, device readings and finality proofs, checked against consensus state.
tenzro_verifyEvidence checks evidence against chain state and says what each item checks to. It is an open read: any application can use it to decide whether a delivery, a reading or a claim is backed by the chain before it pays, releases an escrow or accepts a result. Nothing is stored.
What it checks
| Item | Checked against |
|---|---|
audit | An audit or telemetry entry, against its node's committed epoch root |
terms | A delegated agent's terms, by its DID |
settlement | A recorded settlement, by its payment id |
sensor_data | A device-signed reading, against the device's registered hardware key |
finality_proof | A finality proof (journal and seal), against the governed finality program |
document | A mandate, receipt, evidence pack or delivery, bound by digest only |
Each answer carries the item's kind, its digest and verified_on_chain. A document is bound by its digest and is never verified on chain: the chain can say which document you mean, not that what it says is true.
Using it
import { TenzroClient } from "tenzro-sdk";
const tz = new TenzroClient({ endpoint: "https://rpc.tenzro.com" });
const { items } = await tz.duty().verifyEvidence([
{ settlement: { payment_id: "0x..." } },
{ terms: { agent_did: "did:tenzro:agent:..." } },
]);
for (const item of items) console.log(item.kind, item.verified_on_chain);A call checks 1 to 16 items. The MCP tool is verify_evidence.
An agent's audit trail can be exported as an evidence pack and checked the same way: tenzro agent audit evidence export writes it, and tenzro agent audit evidence check asks a node to verify its items. See Agents.
Tool-call records
Every tool call an agent makes through a node's /mcp, /mcp/compact or A2A endpoint with a valid access token leaves one entry in the agent's audit log, recorded and signed by that node. The entry names the tool, the SHA-256 of the arguments and, once the call ran, the SHA-256 of the result. It also carries:
| Field | Content |
|---|---|
node | The machine DID of the serving node, whose registered hardware identity certified the signing key |
surface | mcp, mcp_compact or a2a |
principal | For a delegated agent: the human (passkey) or machine DID at its root, the Terms version and the digest of the approval those Terms carry |
approval | The approval reference the caller presented, exactly as presented |
outcome | allowed, or refused with the reason the node gave: the agent's Terms, its pinned tools or the access policy |
Arguments and results are never stored, only their digests. The node signs each entry with a session key its hardware identity certified, hybrid Ed25519 and ML-DSA-65 once governance requires hybrid records. One agent's entries form a hash-chained session per node, and the node's epoch commitment fixes each session's root on chain. Entries are written to disk before the response is returned.
A node returns an agent's entries on request. A node with no hardware identity serves calls without records and says so: it answers recording: false with the count of calls it served unrecorded. Calls without a valid access token are not attributed to anyone and are not recorded.
Evidence packs and the EU AI Act profile
tenzro agent audit evidence export writes an agent's evidence pack, or the packs of every agent under one root identity. tenzro_exportEvidencePack with tool_calls: true adds the node's committed tool-call entries, with the registration of every node that signed one.
tenzro agent audit evidence profile --file pack.json --out profile.json maps a pack to the record-keeping and human oversight provisions of Regulation (EU) 2024/1689. Each clause names the pack items it rests on, what they establish and what they do not:
| Clause | Measure | Pack items |
|---|---|---|
| Art. 12(1) | Recording | Every audit entry and the commitments they reach |
| Art. 12(2) | Monitoring | Refused calls and violations, payments, token issuer actions, session receipts, models called |
| Art. 14(3) | Mandate | The Terms records, serving node identities and the approvals the Terms carry |
| Art. 14(4)(d) | Approval | Approval and grant entries, actions held for approval, calls with a presented approval |
| Art. 14(4)(d) | Revocation | Revocation records, or a proven absence of any |
| Art. 14(4)(e) | Halt | Quarantines in force or proven absent, and governance decisions touching the subject |
Verifying offline
An auditor checks a pack with nothing but the chain's genesis anchor:
tenzro agent audit evidence verify --file pack.json \
--chain-id <id> --genesis-hash <hex> --genesis-committee-root <hex>Given the pack's profile as well, the verifier checks it too. The check covers every item in the pack, every node-signed tool-call entry against the key its node registered on chain, proven under the same certified state root, and the profile rebuilt from the pack, so a profile that claims anything the pack does not hold is refused. The operator that produced the pack is not trusted for any of it.
A verified tool-call record proves that the named node, holding the hardware identity registered for its DID, stated that this agent called this tool with arguments and a result of these digests, and allowed or refused it for the reason given; and that the entry sits in the session the node committed on chain for that epoch, in order, with nothing removed around it.
It does not prove what the arguments or result were (only someone holding them can show they match), that the node recorded every call, that a presented approval was valid or reviewed, or anything about calls served by nodes the pack does not cover.
A profile lists evidence. It is not a legal assessment: it does not decide whether a system is high-risk, whether its logging or oversight is adequate for its use, or whether its provider or deployer meets the Regulation.
Related
- Task marketplace, which records a delivery only when its evidence checks
- Network duties
- Trust and provenance