Agent audit record format reference

This reference documents a portable public record shape for agent workflows. It focuses on fields an investigator or verifier needs and leaves implementation-specific transport, storage and private extensions to the deployment.

The format is not a product API contract. Use the schema and verifier supplied with the exact release when evaluating a deployed system.

What is the top-level record shape?

{
  "chain_id": "string",
  "sequence": 1,
  "recorded_at": "RFC3339 timestamp",
  "event_type": "versioned.event.name",
  "actor": {},
  "on_behalf_of": {},
  "task": {},
  "action": {},
  "authority": {},
  "approval": null,
  "outcome": {},
  "evidence_refs": [],
  "release": {},
  "schema_version": "aat-ref-1",
  "previous_hash": "128 hex characters",
  "hash": "128 hex characters"
}

Unknown fields may be retained for forward compatibility only when the canonicalization rule clearly includes or excludes them. Silently dropping an unknown field before verification changes the committed content.

How are identity fields represented?

actor identifies the human, service or agent that produced the event. on_behalf_of identifies the principal represented when different.

{
  "actor": {
    "type": "agent",
    "id": "agent.procurement-review",
    "instance": "run_781"
  },
  "on_behalf_of": {
    "type": "human",
    "id": "usr_8421",
    "delegation_id": "dlg_301"
  }
}

Use stable opaque identifiers. Names and email addresses can be resolved through authorized identity systems when needed. Record the delegation or service grant that connects the two identities.

How is the task represented?

The task object names the bounded work and context without copying all underlying content.

{
  "task": {
    "id": "task_9018",
    "type": "requirement_review",
    "purpose": "prepare_internal_summary",
    "tenant_id": "org_104",
    "consequence": "moderate"
  }
}

purpose is useful for policy and investigation. It should come from a controlled vocabulary where authorization depends on it.

How is an action represented?

Separate operation, target and material parameters.

{
  "action": {
    "operation": "document.release",
    "target": { "type": "document", "id": "doc_551" },
    "parameters_digest": "sha512:...",
    "external_effect": true,
    "reversible": false
  }
}

The digest allows approval and execution to bind to the same parameters without placing sensitive values directly in the record. The evidence store must preserve an authorized way to reconstruct or compare those parameters when required.

How is authority represented?

{
  "authority": {
    "policy_id": "policy.document-release",
    "policy_version": "17",
    "decision": "allow",
    "obligations": ["human_approval", "retain_receipt"],
    "attributes_digest": "sha512:..."
  }
}

Record allow, deny and review decisions. Denials matter because they show whether controls stopped proposed actions and reveal repeated attempts that may require design or security work.

How is human approval represented?

{
  "approval": {
    "id": "apr_392",
    "reviewer": "usr_8421",
    "authority": "document-owner",
    "decision": "approved",
    "parameters_digest": "sha512:...",
    "decided_at": "2026-09-20T14:06:31Z",
    "expires_at": "2026-09-20T15:06:31Z",
    "use": 1
  }
}

An approval event should be separate from an execution event even when a summary record embeds the reference. This preserves the decision time and enables single-use reservation.

How is the outcome represented?

{
  "outcome": {
    "state": "verified",
    "request_id": "req_781",
    "receipt_ref": "evidence://receipt_551",
    "target_version": "version_92",
    "error_code": null
  }
}

Use states that distinguish proposed, denied, approved, reserved, accepted, completed, failed, unknown and verified. A network timeout after the target accepts a request is not the same as rejection.

How is release context represented?

{
  "release": {
    "application": "release_2026_09_20",
    "model_endpoint": "endpoint_manifest_44",
    "policy_bundle": "policy_bundle_17",
    "tool_adapter": "document_adapter_9"
  }
}

Release references make historical records interpretable after the current system changes. The referenced manifests should be protected and retained according to the evidence policy.

What validation rules apply?

Rule	Failure
chain_id is present and unchanged within a chain	Reject or require explicit rollover event
sequence is an integer and contiguous	Report first gap or reorder
timestamp parses and uses an allowed precision	Reject malformed record
event type belongs to the declared catalog	Deny unknown type or handle through version rule
identities resolve within the deployment	Mark unresolved and block where required
action operation is typed	Deny generic or unknown operation
policy decision matches obligations	Block execution on unmet obligation
approval digest matches action digest	Deny execution
hashes have exact algorithm width and encoding	Reject record
recomputed hash equals stored hash	Report integrity failure

Validation should produce structured errors with record position and rule. Avoid a single invalid message that forces investigators to guess.

How are corrections and redactions handled?

Append a new event referencing the earlier record. The correction states the field or evidence reference affected, reason, authority, policy and time. If law or policy requires removal of protected content, retain the minimum non-sensitive tombstone needed to explain that an authorized transformation occurred.

Cryptographic erasure, field-level encryption and retention segmentation can reduce exposure while preserving the outer event chain. The correct design depends on legal and operational requirements.

How are chains partitioned and rolled over?

Choose partitions that match ownership, query and export boundaries. A deployment might use one chain per tenant and application, with additional task identifiers inside. High-volume systems may use time-bounded segments connected by signed checkpoints.

A rollover record should commit to the prior chain head, new chain ID, reason, schema version and checkpoint. Verification can then follow the segment history without assuming one unbounded file.

Which limits should an implementation enforce?

Define maximum record size, field sizes, evidence-reference count, nesting depth, batch size, clock skew and verification work. Parse untrusted exports with strict limits before canonicalization to avoid denial-of-service behavior.

The browser proof on this site limits input to 500 records and 250 KB. Production limits should reflect expected volume and threat model.

What should be included in an export manifest?

An export should include the chain or selected segment, schema and canonicalization versions, checkpoints, signature material, hash algorithm, chain opening or genesis rule, query boundary, export time, exporter identity and known omissions.

The recipient should be able to run verification without proprietary dashboard access. Sensitive evidence references remain subject to separate authorization.