Runs on the API, MCP, and /invoke entry points get signed evidence and a separate timeline.
The runtime appends every step in order and seals the session with Ed25519 at skill_end. Replay handles are signed inline — auditors verify without a database round-trip.
A sealed timeline is served to the session's own parties — the caller who produced it and the agent's evidence readers — and this page is anonymous, so it holds none to print. Your own runs hand you the sealed token directly, in the X-A2A-Replay-Token response header, and it verifies offline. Cited below is the newest verified run the platform is publishing right now.
Read from proof/19 at page load. session_id, caller, task_id, random_seed, receipt_id and the ordered events tuple are not part of what this run publishes.
the run this page is citing
go-daddy.auto ran on build v0.1.0 and passed. The runtime recorded 2 events and 0 file operations, and the whole run took 2m 52s. It finished 2026-06-19 16:29:48 UTC.
auto: Use the OpenAPI service to complete a natural-language goal.
Pinned to agent card 6e14c5558996 at commit a2b41509911f.
what is not on this page, and why
The ordered event stream and the sealed replay token stay with the agent's owner. Not because the run is thin — it recorded 2 events — but because the stream carries the caller's own inputs. The very first entry, skill_start, records their complete validated arguments; the rest carry the prompts, tool arguments and workspace paths that followed.
So /v1/sessions/{id} answers the account that made the call and the agent's evidence readers, and the public proof feed publishes the run's standing without the payload. That is the access policy working, not a gap in it — and it is the part worth trusting: a platform willing to print a stranger's timeline on a marketing page would print yours on one too.
What is shareable is the ProofDrop for this run — the same allowlisted record, with a badge and a permanent URL. And if the run was yours, the receipt you were handed verifies on your own machine: a2a receipt verify checks its Ed25519 signature against the platform's public key, no account and no round-trip required.
what a sealed session records
- skill_startskill started
- llm_callmodel call
- llm_responsemodel response
- tool_calltool call
- tool_responsetool response
- workspace_readworkspace read
- workspace_writeworkspace write
- scope requested
- scope_approvescope approved
- handoff_starthandoff started
- handoff_endhandoff ended
- artifact_writeartifact written
- evalevaluation
- errorerror
- skill_endskill ended
The event vocabulary of the wire format, not a run. The run above recorded 2 of them.
The runtime records. The wire format proves.
Every event in a session is appended in order by the runtime — skill starts, LLM calls, tool calls, workspace reads, scope requests, handoffs, artifact writes. The session is sealed with Ed25519 at skill_end. Auditors verify the timeline with the public key, no database needed.
schema: ReplaySession · signing: a2a_pack.replay · verifying key: A2A_REPLAY_VERIFYING_KEY