AI Agent Action Receipts: Signed Evidence for Privileged Actions

An overnight cleanup agent deletes production customer records. By morning everyone asks the same blunt question: what exactly did it do, on whose authority, with what parameters, and can anyone prove the trail was not edited afterward? The ops log says maintenance task completed. The agent transcript reads like a story. Neither artifact is evidence you can hand to security, legal, or a customer after a dispute.

You need a signed action-receipt contract: every privileged boundary event produces a cryptographically signed, hash-chained receipt from a recorder outside the agent process; authorization claims stay separate from controller-outcome and physical-effect claims; parameters are hashed rather than dumped in plaintext; verification works offline against pinned keys; and high-risk paths fail closed when receipt emission is unavailable. It sits beside AI agent audit logs (the structured event schema and redaction rules), binding human approval to exact AI agent actions (the human authorization artifact), validating AI agent tool calls before execution (schema and policy on the proposed call), and attenuating capability-token contracts for multi-hop AI agent delegation (narrowed authority before the call). The job here is narrower: prove what the governed boundary recorded as happening, in a form that survives agent compromise.

Why editable agent logs fail the morning-after question

OWASP MCP08:2025 Lack of Audit and Telemetry states the failure plainly. When MCP and agent systems lack structured, centralized, integrity-protected logs, organizations lose visibility into actions, data access, and decisions. Logs stored locally, deleted often, or left without integrity protections cannot support incident response or compliance. Silent exfiltration and insider manipulation stay invisible for weeks.

Structured audit events, as described in Fire in Belly's AI agent audit logs guide, are necessary. They are still insufficient on their own. A schema that answers who, what, which policy, and which target can still live inside the same trust boundary as the agent. If the writer's identity can update or omit events, or if the only signature is the agent's own key, compromise of that principal rewrites history. OWASP LLM06:2025 Excessive Agency reminds you that agents with more functionality, permissions, or autonomy than the job needs create blast radius; accountability after the fact is part of containing that radius.

The IETF SCITT profile for AI-agent action receipts opens with the same morning-after question and refuses to solve it with vendor prose. A receipt is a small, signed record per governed action. Anyone holding the issuing key can check it without calling the agent vendor. Being narrow is the point: a record that promises more than it can support is worse than no record.

The attack: evidence that the agent still owns

Three failure modes show up in internal platforms.

1. Self-attested completion. The agent or its host process writes tool completed to its own log. After compromise via prompt injection or a stolen workload identity, the same principal omits the destructive call or rewrites the summary.
2. Collapsed claims. One log line implies authorization, successful API response, and real-world effect. Investigators cannot tell which of those statements was ever checked.
3. Logging as best effort. Receipt or audit emission fails. The privileged tool still runs. The platform treated evidence as optional telemetry instead of a control on the hot path.

Agent Receipts frames the first failure as the reason signing keys and the receipt store must live outside the agent process. draft-sharif-agent-audit-trail-06 frames the second and third: denials and escalations must be recorded before execution if they are to prove enforcement, and higher trust levels should use an independent recording component with a distinct signer key.

Place the recorder outside the agent

Start with placement before you argue about field names. The component that issues receipts for privileged tools must not share the agent's writable filesystem, OS principal, or signing key.

Practical placement rules:

Agent Receipts / obsigna shows one concrete shape: an MCP proxy or daemon signs every tool call as a W3C Verifiable Credential with Ed25519, hashes parameters, and hash-chains receipts so sequence gaps become visible. You do not need that exact product. You do need the same trust split: the agent proposes and the recorder attests.

Self-recording can be acceptable for low-risk read tools during early rollout. For refunds, deletes, production deploys, cross-tenant writes, and external egress, treat self-recording as a known weak mode and label it in the genesis or session metadata so reviewers do not mistake it for independent evidence.

Keep the claim boundary honest

The SCITT AI-agent receipt profile makes a deliberately narrow claim: this issuer-authenticated, signature-verifiable, tamper-evident record says the governed boundary recorded this action, principal class, verdict, and optional policy identity. It does not claim the agent was correct, safe, or wise; that inputs were true or complete; that a named approver authorized this exact action before it ran; that a downstream controller succeeded; or that any physical effect occurred.

Wire that honesty into your contract as three claim classes with independent failure behavior:

1. Authorization claim. Policy allow/deny or human-approval binding for this exact action digest. Often a pre-execution receipt. Complements - does not replace - binding human approval to exact AI agent actions.
2. Dispatch / controller-reported outcome. The boundary attempted the call and the downstream system reported success, failure, or timeout under that system's semantics.
3. Physical or ledger effect. Only when a separate witness artifact exists (payment settlement evidence, signed ticket transition from the system of record). Never inferred from an EXECUTED or success receipt alone.

If your receipt format has a single outcome: success field that operators read as "the money moved," you have invented liability the crypto never promised. Prefer lifecycle verdicts like the SCITT profile's closed set (ALLOWED, BLOCKED, EXECUTED, FAILED, and related tokens) or an explicit split between decision receipts and outcome artifacts as in draft-marques-asqav-compliance-receipts-02.

Pre-execution vs post-execution phases

A denial logged after the tool already ran is a diary entry, not enforcement evidence. draft-sharif-agent-audit-trail-06 requires record_phase: pre_execution for denied and escalated decisions, and for high-risk systems requires a pre-execution authorization record before external state changes, fund movement, or delegation.

Minimum phase rules for internal platforms:

• Emit a pre-execution receipt for allow/deny/escalate on privileged actions before the side effect starts.
• Emit a post-execution receipt for controller-reported results, linked by action digest or authorization receipt id.
• Never let a single post-hoc summary stand in for both.
• If the pre-execution receipt cannot be issued, do not run the privileged tool.

That pairing is what lets an investigator prove the gate existed, not only that someone later wrote a story about the run.

Hash parameters; chain and sign the envelope

Receipts must be useful in audits without becoming a second secrets database.

• Store action type, risk class, agent id, policy digest or rule id, timestamps, and reversible/rollback hints.
• Store params_hash (SHA-256 or HMAC-SHA-256 for low-entropy values), not raw prompts, tokens, or full tool arguments.
• Hash-chain receipts (prev_hash / previousReceiptHash) so mid-chain deletion or reordering is detectable.
• Sign with a modern algorithm (Ed25519 is the common baseline in these drafts; compliance profiles may also allow ML-DSA-65 for long retention).
• Optionally anchor chain heads with RFC 3161 or OpenTimestamps when retention and dispute windows demand an external clock.

draft-marques-asqav-compliance-receipts-02 tightens optional upstream fields into required chain linkage, anchoring, and retention floors for EU AI Act Articles 12 and 26 and DORA Article 17. Even if you are not yet in a regulated deployer role, those bindings are a useful severity ladder: if you cannot produce a signed pack for a time window, you do not have an operating contract - you have aspirational logging.

Worked example: refund delete without a trustworthy trail

A support orchestrator holds a capability token attenuated to order.read and refund.write with max_refund <= 50. A specialist sub-agent somehow still reaches customer.delete through a miswired tool server. Two evidence designs diverge.

Editable log design. The host process writes cleanup finished under the orchestrator identity. After the mistake, an operator with the same deploy credentials truncates the log. The approval record for a different refund still exists. Nobody can prove whether customer.delete was authorized, denied, or silently skipped in logging.

Signed receipt design. An MCP proxy outside the agent issues a pre-execution receipt for the proposed customer.delete with params_hash, policy digest, and verdict BLOCKED or ALLOWED. If allowed in error, a post-execution receipt records controller FAILED or EXECUTED with a link to the pre-execution id. The chain is signed by the proxy key. Truncating the agent host log does not remove the receipt store. Offline verification against the pinned proxy public key still shows the sequence.

Capability attenuation (capability-token guide) should have blocked the tool. Receipts are what prove whether the boundary actually enforced that block when the morning-after argument begins.

Fail closed when evidence cannot be produced

Treat missing receipts on high-risk paths as an authorization failure.

on privileged_tool_request(action):
    authz = evaluate_policy_and_approval(action)
    pre = recorder.issue(phase="pre_execution", action=action, verdict=authz)
    if pre is None:
        deny("receipt_unavailable") # not "log later"
    if authz.denied:
        return deny(authz.reason)
    result = execute_tool(action)
    post = recorder.issue(phase="post_execution", parent=pre.id, result=result)
    if post is None:
        alert("receipt_gap"); quarantine(action)
    return result

Low-risk reads may degrade to best-effort telemetry. Production deletes, payments, IAM changes, and external egress should not. OWASP MCP08 lists "no data available" during investigations as a detection signal; your platform should create that signal at emission time, not months later in a tabletop.

How this contract relates to adjacent controls

Operating constraints

These constraints are easy to miss when teams only add structured logs:

1. Treat authorization, controller outcome, and physical effect as three separately signed claims; a valid EXECUTED receipt is not proof the world changed. Operators who collapse those claims into one success bit invent liability the receipt format never supported.
2. Require an independent recorder with its own signing key outside the agent process; self-signed agent logs collapse under compromise of the same principal. If the agent and the evidence share one key or one writable store, the morning-after question has no trustworthy answer.
3. Fail closed on high-risk tool paths when receipt emission is unavailable; silent continuation without evidence is an authorization change, not a logging outage. Telemetry degradation policies that still allow deletes and payments silently rewrite your control plane.

Promote or hold

Promote when:

• privileged tool paths issue receipts from a recorder outside the agent process with a distinct signing key;
• pre-execution and post-execution phases are both present for high-risk actions;
• authorization, controller outcome, and physical effect are not collapsed into one success bit;
• parameters are hashed; raw secrets never enter the receipt payload;
• chains verify offline against pinned keys; mid-chain gaps alert;
• high-risk tools fail closed when receipt emission is unavailable.

Hold when the only evidence is an agent-host log, when the agent signs its own receipts with a key it can also use to call tools, when success silently means "money moved," or when privileged tools continue during receipt outages.

What to do next

List every production tool that can delete data, move money, change IAM, deploy to production, or egress externally. For each path, record whether evidence is an editable log, a self-signed agent summary, or an independently signed hash-chained receipt with honest claim boundaries. Until that inventory shows fail-closed independent receipts on every privileged path, treat "we have audit logging" as an incomplete control rather than a finished one.

If you need the control plane implemented as part of an internal workflow program rather than a weekend receipt prototype, start from AI workflow automation with signed action receipts as an explicit deliverable.

---