agent-decision-receipts

---
name: agent-decision-receipts
description: Use when an autonomous agent takes a consequential, side-effecting action (deploy, delete, pay, grant-access, model decision) that may need proof later, or for EU AI Act Article 12 record-keeping.
category: Regulatory & Quality
version: 1.0.0
tools: []
---

# Agent Decision Receipts

A log says an action happened. A **receipt is tamper-evident**: it records who, what, and under which policy, and it is signed, so any later edit breaks the signature. This skill mints one for a consequential agent action and verifies it later from the certificate alone — no database, no network, no trusting the issuer.

The cryptography is not implemented here — it's delegated to the open-source **OpenAgentOntology** receipt primitive (Apache-2.0), which signs every receipt with Ed25519 **and** the post-quantum legs ML-DSA-65 (FIPS 204) + SLH-DSA (FIPS 205) when the post-quantum backend is available. This skill is the decision layer: when to mint, what goes in, how to verify.

**Three decisions, nothing else:**

1. **Does this action need a receipt?** Side-effecting + consequential + later-provable = yes.
2. **Mint the receipt** — build the action manifest, have it signed.
3. **Verify it** — recompute the hash, check each signature leg, from the certificate alone.

This is **NOT log analysis** — logs describe what happened and can be silently edited after the fact; a receipt is minted at the point of action and breaks if edited. Use logs for debugging, receipts for evidence.

This is **NOT a hosted notary** — it mints a local, self-signed receipt anyone can verify offline. Cross-organization verification (one org proving something to another) is a separate hosted service and out of scope.

This is **NOT a legal opinion** — it produces evidence shaped to support FRE 902(13)/(14)-style certification and EU AI Act Article 12 record-keeping. Whether a given receipt is admitted is a question for counsel.

## Decision 1: Does this action need a receipt?

Mint a receipt when the action is **all three** of:

| Test | Mint if... |
|------|-----------|
| Side-effecting | it writes, sends, deploys, deletes, pays, grants access, or changes external state |
| Consequential | a wrong call costs money, breaks compliance, or harms a person |
| Later-provable | an auditor, insurer, regulator, court, or counterparty may later ask "what did the agent do and why?" |

Read-only, reversible, trivial actions do **not** need a receipt. Receipt everything and the signal drowns; receipt nothing and the one call that mattered can't be proven.

Mint by default for: deploy, delete, pay/wire/refund, grant_access, export/egress, approve/deny a claim, and any model decision that affects a person under a high-risk AI system.

## Decision 2: Mint the receipt

Build an action manifest — any plain, ASCII-safe description of what the agent did. Four fields are required, and the manifest should be rejected if any is missing:

| Field | Required? | Carries |
|-----|-----------|-----------------|
| `agent_id` | required | the acting agent |
| `operation` | required | the verb — deploy / delete / pay / decide / ... |
| `target` | required | what it acted on |
| `policy` | required | the rule that governs it, e.g. "EU AI Act Art 12" or "internal change-control" |
| `inputs_hash` | auto-added | a hash of the inputs, so the full payload need not be stored in the clear |
| `decision_label` | auto-added | the receipt's decision label, defaults to `ACTION_GOVERNED` |

Minting hashes the full manifest into the receipt evidence, signs the canonical body, and returns a receipt carrying an `evidence_hash`, an Ed25519 signature, and — when the post-quantum backend is installed — an ML-DSA and an SLH-DSA signature. Each leg signs the same bytes; any one verifying proves authenticity.

## Decision 3: Verify it

Verification recomputes `sha256` over the canonicalized evidence, compares it to `evidence_hash`, then checks every signature leg it has a backend for, returning an ok/hash_ok/sig_ok/legs/reason result. A single edited byte anywhere in the action breaks `hash_ok`; a forged signature breaks that leg. Verification needs only the receipt — no call back to the issuer. That's the property that makes it evidence: a reviewer who distrusts the issuer can still confirm the receipt is intact and authentic, entirely offline.

## Anti-Patterns

- **Receipt the log, not the decision.** Minting over a log line written after the fact proves nothing — mint at the point of action, over the action.
- **Storing the signing key next to the receipts.** A compromised key makes every signature meaningless — treat it like any other signing secret.
- **Ed25519-only when post-quantum legs are available.** A receipt is long-lived evidence — sign with ML-DSA-65 + SLH-DSA so it stays verifiable if a future quantum computer breaks Ed25519.
- **Putting raw secrets or PII in the manifest.** The manifest is hashed into evidence and recoverable from the receipt — carry hashes, not cleartext.
- **Calling it "admissible."** It's evidence shaped to *support* FRE 902(13)/(14)-style certification; admissibility is a court's decision, not the tool's claim.
- **Faking a signature when crypto is unavailable.** Emit an explicit `unsigned` flag instead — never present an unsigned receipt as signed.

## Related work

This pairs with EU AI Act Article 12 risk-tier and record-keeping work (decide the obligations first, then mint the per-action record they require) and with AI management-system controls work (receipts are the per-decision evidence those controls call for). @mention a teammate who owns either program when scoping which actions need receipts.