AI Agent Execution Attestation: A Verifiable Audit Trail

An execution attestation is a signed statement about an agent run. It can prove that a particular key signed particular bytes. It cannot, by itself, prove those bytes describe reality.

That distinction separates useful audit infrastructure from cryptographic theatre. The attestation must bind identity, authorised intent, runtime configuration, inputs, tool effects, checks, and outcomes—and the verifier must trust how each field was measured.

Logs, audit records, and attestations

Artifact	Purpose	Integrity property
Operational log	Debug and observe detailed events	Often mutable and access-controlled
Audit record	Reconstruct accountable decisions and effects	Append-only policy and retention expected
Execution attestation	Bind a compact claim set to an issuer and subject	Signature plus verifiable artifact digests

Do not put every prompt and document into the attestation. Store sensitive evidence in its authorised system and reference it by digest and evidence ID.

The envelope

{
  schemaVersion,
  attestationId,
  emittedAt,
  issuer: {id, keyId, collector},
  subject: {type, id, artifactDigest},
  run: {traceId, parentTraceId, startedAt, endedAt},
  actor: {principal, agentId, delegationDigest},
  intent: {requestDigest, policyDigest, approvalDigest},
  runtime: {orchestrator, model, promptDigest, environmentDigest},
  inputs: [{name, digest, classification, evidenceRef}],
  tools: [{name, version, inputDigest, outputDigest,
           effectClass, effectReceipt}],
  checks: [{id, version, result, evidenceDigest}],
  outcome: {status, outputDigests, errorClass},
  sequence: {previousAttestationDigest, nonce}
}

The downloadable JSON Schema makes these fields concrete. It deliberately keeps the detached signature outside the payload so the signed bytes are unambiguous.

Identity and delegated authority

The issuer is the component that measured and signed the claim. The actor is the human or service principal plus the agent operating under delegated authority. They are not necessarily the same.

For a consequential effect, bind:

• the authenticated principal;
• the agent and orchestrator instance;
• the exact policy version and granted scope;
• the approved action hash and expiry;
• the tool identity and external effect receipt.

A signature from “the agent” is weak if the agent held the key and could invent its own authority. Prefer a separate execution gateway or trusted collector that observes policy decisions and tool calls.

Bind configuration, not raw secrets

Model behavior depends on more than a model name. Record immutable identifiers or digests for:

• model provider, model identifier, and revision where the provider exposes one;
• system prompt, policy bundle, tool definitions, and route;
• orchestrator and connector builds;
• execution environment, sandbox policy, and dependency lock;
• evaluation and verifier versions.

A hash proves equality to bytes you already possess. It does not reveal what opaque hosted model weights actually ran. Record provider receipts and be explicit about that assurance gap.

External effects need receipts

“Tool call returned success” is not enough. For a payment, deployment, email, or deletion, capture the provider's stable operation ID, idempotency key, accepted payload digest, status, and reconciliation timestamp.

Effect state	Meaning	Allowed next step
Not attempted	No mutation request was sent	May execute with valid authority
Confirmed	Provider receipt matches the requested effect	Continue; never repeat the effect
Rejected	Provider definitively refused it	Stop or repair under policy
Unknown	Request may have succeeded but acknowledgement is missing	Reconcile; do not retry blindly

Verification flow

payload + detached signature + public key
                    │
                    ▼
1. Parse and validate schema
2. Verify exact-byte signature
3. Resolve issuer and key status at emittedAt
4. Apply trust policy for subject/action class
5. Recompute referenced artifact digests
6. Check policy, approval, sequence, time, and nonce
7. Reconcile effect receipts with external systems
8. Evaluate required checks and unresolved gaps
                    │
                    ▼
verified | rejected | incomplete | untrusted

Signature success is step 2, not the final verdict. A revoked key, untrusted collector, expired approval, missing receipt, or inaccessible evidence can still make the attestation unusable.

Threat model

Threat	Control	Residual limitation
Emitter signs a fabricated story	Independent collection at policy/tool gateway; cross-check receipts	Collector compromise can still lie
Signing key is stolen	Hardware-backed key, rotation, revocation, short-lived credentials	Past compromise time may be uncertain
Record is replayed	Unique attestation ID, nonce, subject, time, and sequence checks	Verifier needs durable replay state
Events are removed or reordered	Previous-digest chain or transparency log	Private forks require an external checkpoint
Secrets leak through evidence	Digest and reference; classification; access and retention policy	Digests of low-entropy values may be guessable
Opaque provider claims are treated as proof	Record assurance source and distinguish observed from asserted fields	Hosted internals may remain unverifiable
Approval covers a different action	Bind approval to canonical action digest and expiry	Human may still approve without understanding

Canonicalization and signature profile

Production systems should adopt a defined canonicalization and envelope standard rather than inventing one. The downloadable demonstration avoids canonicalization entirely: the Ed25519 signature covers the exact bytes of agent-execution-attestation.example.json. Any whitespace change invalidates it.

openssl base64 -d -A \
  -in agent-execution-attestation.example.sig.b64 \
  -out /tmp/agent-attestation.sig

openssl pkeyutl -verify -pubin \
  -inkey agent-execution-attestation.example.pub.pem \
  -rawin \
  -in agent-execution-attestation.example.json \
  -sigfile /tmp/agent-attestation.sig

The private demonstration key is not published and must never be trusted for production. The public key proves only that the included sample and signature match.

A practical adoption path

1. Choose one irreversible or externally visible action.
2. Define its subject, authority, effect receipt, and minimum checks.
3. Emit the unsigned schema first and verify completeness.
4. Move collection outside the agent process.
5. Add signing, key identity, rotation, and revocation.
6. Verify at the release or action gate—not only during an audit.
7. Add sequence integrity or a transparency log when omission matters.

Download and verify the example

Download the attestation JSON Schema

• Example signed payload
• Example Ed25519 public key
• Detached signature, base64

Connect the envelope to the EU AI Act evidence framework, the SkillLedger trust model, and the agent reliability SLO framework. Attestation provides evidence; those systems decide what evidence is required and what to do with it.