Lab 005 · Verifiable Action Receipts

Can We Prove What the Agent Actually Did?

Trustworthy autonomy needs more than an activity log. It needs a verifiable record of request, authority, judgment, execution, and outcome.

An agent’s claim that it completed a task is not enough. A trustworthy system should preserve evidence connecting intent, authority, judgment, execution, and outcome.

This Lab is an educational receipt prototype using fictional data. It does not create production audit evidence, digitally sign production events, or perform security actions. Execution is never performed against real systems.

Previous Lab: The Agent Escalation Boundary Browse all Labs

A log is not a receipt

Activity log asks

What event was recorded?

Example: 10:42:11 session revoked

Action receipt asks

Who acted, under which authority, based on what evidence, through which tool, and what changed?

It binds request, identity, decision, human involvement, and outcome together.

Why reconstruction is hard

Complex agent activity can span multiple agents, evaluation runs, tools, credentials, and systems. Reconstructing what happened requires correlating evidence across the full action chain—not only reading a single activity line.

This Lab uses fictional Cedar Quill Markets data. It never claims to reconstruct or prevent any specific real-world incident.

Presets

Select a preset to fill the receipt builder, then generate a hash-protected receipt.

Receipt builder

Inspect or adjust the fictional fields, then generate a receipt hash. No real action is performed.

Request and identity

Request ID Correlation ID Agent identity Principal identity Target resource Requested action Delegated capability Authority source

Policy and judgment

Policy ID Policy version Authorization outcome Execution judgment Human involvement Approval reference

Evidence, tool, and integrity demo controls

Evidence references Hold Command or Control to select multiple. Machine IDs are kept in the receipt. Evidence summary Original request Clarification note Simulated tool Simulated tool action Observed outcome Reason codes Hold Command or Control to select multiple. Canonical codes stay in Raw JSON. Explanation Previous receipt hash Force tamper field Force tamper value Force broken previous-receipt chain

Receipt result

Select a preset or adjust the builder, then generate a receipt. No real security action is performed.

Receipt chain

Request, authority, decision, execution, and outcome feed a hash-protected receipt. Human approval can enter at the decision boundary when confirmation is required.

Flow from request through authority, decision, execution, and outcome into a verifiable action receipt, with optional human approval.

Teaching notes

Logs are evidence sources, not automatically complete receipts. A useful receipt connects the request, identities, delegated authority, policy decision, human involvement, simulated tool activity, and observed outcome.

Receipt integrity is different from decision correctness. A VERIFIED receipt can document a denied or stopped action. A matching hash shows content has not changed relative to a trusted reference; it does not by itself prove who created the receipt.

Production-grade non-repudiation needs protected signing keys, trusted timestamps, identity-bound signatures, durable storage, access controls, privacy controls, and retention policies—beyond a self-contained educational SHA-256 seal.

Every evaluation reports execution: not_performed for the real system. Fictional tool activity may be recorded on the receipt as simulated for teaching. This Lab uses fictional data and must not be used as a production audit or incident-response system.