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

What a capsule commits to

A capsule is a COSE_Sign1 envelope over the media type application/agent-action-capsule+json. The payload 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, a capsule proves integrity without disclosing 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:

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 proves 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). An existence proof comes from anchoring — the receipt held beside the capsule. A producer signature binding to a key is the SCITT Signed-Statement level, a step up from the default. You adopt as much as your use case needs.

What a capsule does not prove

Honest claims matter. Know the limits before relying on this for audit or compliance:

• Attested, not verified. A capsule proves what the agent attested it did — not that the real-world effect occurred. A dispatched capsule does not mean the write landed; a confirmed one does.
• No anti-omission property. A capsule proves 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.
• Default may be signature-less. The base assurance level is a content hash (tamper-evident, content-private). A producer signature binding to a key requires the SCITT Signed-Statement level explicitly.
• 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. A witness or a second independently-operated log 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.