What is an Agent Action Capsule?
An Agent Action Capsule is a signed, tamper-evident record of a consequential action an AI agent took — sealed at the moment it acted, so any third party can verify later what happened, without trusting the operator who ran the agent.
Agents increasingly take real actions: they place orders, move files, send messages, change records. Today, the only evidence that an action happened as described is the operator's own word. The Agent Action Capsule closes that gap by borrowing the shape that software supply-chain security already uses for build artifacts — a signed statement registered to a transparency log — and applying it to agent actions.
The three properties
| Property | What it means |
|---|---|
| Signed | The capsule is a statement committing to the action, its inputs and outputs (by digest), and the model/runtime that produced it. It is always content-addressed, and a producer signs that address with COSE; the reference producer signs every capsule by default. Change any byte and verification fails. |
| Transparent | The statement is registered to a transparency service, which returns a receipt proving the record was included in an append-only log. Dropping or rewriting a logged entry would be detectable by anyone holding an earlier receipt or tree head. |
| Third-party verifiable | An auditor, third party, or regulator checks the signature and the inclusion proof from the bytes alone — no access to the operator's systems. You trust the log's key, not the operator. |
What a capsule commits to
A capsule is a JSON record of media type application/agent-action-capsule+json. A producer signs it with a COSE_Sign1 Producer Envelope whose payload is the capsule's 32-byte capsule_id. The record commits to:
- the action performed (an effect type and its identifying fields);
- input and output digests — SHA-256 of what went in and what came out, so raw values stay local while the proof travels;
- the producing context — the model and runtime that generated the action.
Because inputs and outputs are committed by digest, anyone can check a capsule's integrity without seeing the sensitive payloads.
What gets sealed — the fields
The seal is the capsule_id: the SHA-256 of the canonical capsule. Recompute it and it must match byte-for-byte — that hash is the seal. Around it, a capsule commits the parts an agent action needs to be accountable:
| Field | What it commits |
|---|---|
| capsule_id | SHA-256 of the canonical capsule — the seal / content address. |
| action / operator / developer / timestamp | what was done, the accountable tenant, the agent identity@version, and when. |
| disposition | the may/did verdict — a registered verdict_class such as executed, blocked, denied, timeout or errored (the full list), plus who disposed it and an honest human-in-the-loop flag. |
| effect | what was committed, plus the confirmed-effect binding so the claim and the outcome can't drift apart. |
| model_attestation | which model decided, with the full input it saw (system prompt, context, tool definitions, and the action's arguments) and the output each committed as a digest (fixed-size; raw values, however large or sensitive, are never stored) plus best-effort compute. |
| assurance | how far to trust it: attestation / effect / ledger modes. |
| chain | the link to this producer's own previous capsule: a parent_capsule_id plus a registered relation (follows, confirms, supersedes, epoch_opens, duplicates). Same stream only; a citation of anything else — another producer's record, a grant, a receipt — goes in references. |
Content-private by construction
Each evidence layer is hashed, and only the digest is committed — the raw prompt, vendor, or amount is never inside the capsule. You can hand someone a capsule and they learn what happened and can verify the seal, without seeing your inputs or outputs. Reveal a raw value later only when you choose, and anyone can re-hash it against the committed digest.
Chains: approved → executed → confirmed
A confirmation is itself a capsule that points at its parent by digest. That turns a decision and its follow-through into one verifiable trail — the basis for human-in-the-loop confirmation and for selective disclosure (show a chain that records authorization without exposing the underlying data).
A confirmed capsule is sealed only when the agent observes a reply or receipt back from the system or party it acted on — that returning confirmation is what closes the loop. It's why confirmed carries more weight than dispatched, which records only that the action was sent. When no confirmation comes back to observe, the capsule honestly stays dispatched or executed.
Levels of assurance
Tamper-evidence is always present (the capsule_id hash). A producer signature binds that hash to a key. An existence proof comes from registering the capsule_id with a transparency service — the receipt held beside the capsule. You adopt as much as your use case needs.
capsule_id, a SHA-256 over the canonical capsule, and it does not depend on any signature. The specification makes signing optional: a producer MAY add one or more COSE_Sign1 Producer Envelopes over the capsule_id. The reference producer, capsule-emit, signs every capsule it seals, by default, with a per-ledger Ed25519 key; its only unsigned path is the separately named log() call.What a capsule does not establish
Honest claims matter. Know the limits before relying on this for audit or compliance:
- Attested, not verified. A capsule records what the agent attested it did — not that the real-world effect occurred. A
dispatchedcapsule does not mean the write landed; aconfirmedone does. - No anti-omission property. A capsule shows this action was recorded. It does not prevent an operator from simply not emitting a capsule for an action they'd rather not surface.
- Signer = key-holder. The signature proves who held the signing key at the moment of sealing — not that the named agent actually ran the action. Key-management discipline is outside the capsule.
- A hash alone names no one. Without a Producer Envelope, a capsule is tamper-evident but says nothing about who sealed it. The specification allows that; the reference producer does not do it by default (see What is signed by default, above).
- Single-operator log ⇒ non-equivocation is operational. The public Transparency Service prevents the log from quietly rewriting history — but if one operator controls both the agent and the log, equivocation is an operational question, not a cryptographic one. Registering with a Transparency Service the operator does not run removes this.
These limits are features of being honest, not gaps to hide. Stating them is what makes the record trustworthy to an outside auditor.
Where it sits
The capsule is a statement-layer profile. It says nothing about which verifiable data structure a log uses — that separation is what lets the same capsule verify against different transparency services. See the statement layer vs the transparency layer.
It is one SCITT profile among others — specialized for agent actions, built on the general SCITT/COSE substrate, and interoperable with any SCITT transparency service. Adopting it means building on a shared profile, not forking your own.
capsule-emit: Concepts, in plain words ↗ · Anatomy of a capsule ↗