Your agent can create verifiable file proofs.

Public creation request

No Authorization header.

POST https://api.verifyum.com/v2/anchor
Content-Type: application/json

{
  "commitment": "sha256:<64 lowercase hex characters>",
  "idempotency_key": "agent-run-unique-request-0001"
}

Poll https://api.verifyum.com/v2/proofs/{proof-id}. Honor HTTP 429, HTTP 503 and every Retry-After header.

Machine-verifiable witness chain

Follow one proof into the daily witnesses.

GET https://api.verifyum.com/v2/proofs/{proof-id}/witnesses
GET https://api.verifyum.com/v2/proofs/{proof-id}/witness-chain

The first route proves inclusion in the hourly checkpoint. After the next daily checkpoint, the second also proves that exact hourly checkpoint hash belongs to the daily aggregate and returns the hourly and daily receipt URLs. A 404 for the daily bridge is normal while it is not due yet. Neither route lists another proof.

Model Context Protocol

One URL for MCP agents.

Agents that speak the Model Context Protocol can reach the same service through one hosted endpoint. The HTTP API above remains the complete contract. The endpoint accepts only a commitment, an idempotency key or a public proof ID, and file hashing stays on your machine.

https://api.verifyum.com/mcp

Example for Claude Code: claude mcp add --transport http verifyum https://api.verifyum.com/mcp

The tools are verifyum_get_proof, verifyum_verify_public_proof and verifyum_anchor_commitment. Anchoring through MCP follows the same limits and current free policy as the HTTP API. The endpoint is listed in the official MCP registry as com.verifyum/mcp.

Decision records

Seal what the agent knew, when it acted.

An autonomous system can assemble its full operating state into one document: system instructions, the exact user prompt, model and version, parameters such as temperature, the tools it called, and the response or action it produced. Hash that document locally, anchor only the commitment, and the log becomes tamper-evident.

{
  "type": "agent-decision-record",
  "recorded_at": "2026-08-31T20:15:04Z",
  "agent": { "name": "claims-triage", "version": "4.2.0" },
  "model": { "provider": "...", "model": "...", "temperature": 0.2 },
  "system_instructions": "...",
  "input": { "...": "the exact prompt and retrieved context" },
  "tools": [ { "name": "...", "arguments": {}, "result_digest": "sha256:..." } ],
  "output": { "decision": "...", "rationale": "..." }
}

The record never leaves your infrastructure. Verifyum receives only the commitment, so the prompt, the context and the customer data stay private while the timestamp becomes public and independently checkable.

When a decision is later reviewed, whether for automated case handling, a financial action or generated content, you present the record. Anyone can recompute its hash, rebuild the commitment and match it against the Solana transaction. A document that was rewritten, backdated or quietly corrected afterwards will not match.

What this shows, precisely: that this exact record existed no later than the block time and has not been altered since. It does not prove that the agent truly ran with those parameters, because Verifyum never sees the system that wrote the record. It fixes the record in time, which is the part an audit cannot otherwise establish.

One anchor per decision is rarely needed. A daily or per-case record, or a hash chain of many decisions with periodic anchoring, keeps volume inside the fair-use limits.