Open record format

What was this agent allowed to do?

ACTION-v1 is the record that answers it. A declared tool action is checked against policy before it runs, and the outcome is signed either way. A refusal is a record in its own right.

The problem

A log describes what happened after it happened, and it is written by the system under review. That was tolerable when an AI produced text. It stops being tolerable when an agent selects tools and changes something outside itself: deploys code, moves money, opens a door, writes to a record system.

The question a reviewer asks months later is not whether the model was clever. It is what the agent was permitted to do, who decided, and whether anyone outside the operator can check that now.

The record

Thirteen fields and not a number among them, so the whole class of cross-language number formatting disagreement cannot arise. The arguments are hashed rather than carried, so a record holds no prompt, no customer data and no case detail.

tool
the action the agent declared
args_hash
its arguments, hashed canonically
intent_hash
the instruction the session is bound to
outcome
ALLOWED or BLOCKED
policy_applied
the policies that were evaluated
agent
identity as claimed, never verified

The full specification is normative, including the field-by-field statement of which claims the issuer attests and which it merely records.

What an action record proves, and where it stops

It proves

  • The holder of the published key evaluated these policies over exactly this declared action
  • The outcome that was reached, and when
  • That the session was bound to an intent that could not be changed once set
  • That not one signed field has moved since

It does not prove

  • That the action was correct, wise or safe. The record is about permission, not judgement
  • Who the agent was. That identity is supplied by the caller and recorded, never verified
  • What the caller then executed, unless the boundary performed the action itself. A refusal has no such gap, because nothing ran
  • That every action was recorded. Proving none was left out is an open problem and we treat it as one

Verifying one

Two independent implementations, TypeScript and Python, agree on every published vector. Selecting the format is explicit, never guessed from the shape of the fields.

curl -sL https://app.aqta.ai/samples/sample-action.json -o record.json
npx aqta-verify-receipt record.json --profile action-1 --key <published key>

That sample is a real record from the production gateway: an agent proposed git.push_production, and policy refused it before anything ran. The key comes from the published key endpoint, pinned once. Change one character of the file and the signature fails. Every record the format defines is also published as conformance vectors, valid and deliberately broken, so you can check the checker.

Where it sits

Agents increasingly act through the Model Context Protocol and similar tool interfaces, which settle how an agent reaches a tool. ACTION-v1 is the evidence at that boundary. Authorisation decides whether the action happens; the record decides who can prove it afterwards.

It is a sibling of ATTESTATION-v1, which records what an AI decided on a model call. Same key, same reference verifiers, same offline check. The in-browser checker reads model-call receipts; action records are checked with the command above.