Governed Runtime Standards · Specification 1 of 3
Action Provenance Record
A verifiable JSON document describing one action taken by or through an AI agent. It answers, in one place and one format, the questions an auditor, a regulator or a manager will ask after the fact: who requested it, which agent and model acted, what policy decided, who approved it, what it did to which system, and what happened.
Why a record, not a log
Provenance for AI has so far meant content provenance: where a file came from and whether a model made it. That is not the question that arises when an agent acts. An agent does not merely produce a paragraph; it sends the email, changes the record, moves the money. Once AI takes the action itself, the question shifts from "is this output good" to "can we account for what happened."
Existing work covers pieces. W3C PROV and its agent extensions model activity graphs but say nothing about approval, policy or business-system effects. The Agent Action Capsule, an individual Internet-Draft for IETF SCITT, records what was executed and binds it cryptographically, and carries the authority that permitted the action only as an opaque reference. Telemetry conventions record tokens, not accountability. The Action Provenance Record binds attribution, authority, policy, model, effect and outcome together in one document, with an integrity model built on standard primitives (SHA-256 and HMAC-SHA256): anyone can recompute a record's content digest with a hash function, and a holder of the sealing key can verify its proofs offline.
Design principles
- One record per action. Related records share a
correlationId; a set with the same correlation is a run. - Digests, not payloads. The record never needs raw prompts, responses or arguments. It carries digests and references, so content can be checked when available and withheld when it must be.
- Terminal outcome. A record describes an action that has finished.
- Open vocabularies. Growing enumerations are open; extensions use an
x-prefix or theextensionsmember. - Tenant scoped. A runtime never exposes one tenant's records to another.
- Verifiable after the fact. A sealed record can be checked without the runtime that produced it.
What the record contains
Members marked R are required at Level 1.
| Member | Meaning |
|---|---|
| spec (R) | Always action-provenance/1.0. |
| id, correlationId (R) | Unique record id; the id that groups every record of one action or run. |
| recordedAt (R) | When the record was written. RFC 3339, UTC. |
| action (R) | kind (chat_turn, agent_invocation, workflow_step, tool_call, agent_formation, subagent_spawn, runtime_action, or x-), at, effect (none, read, write), optional description. |
| principal (R) | The party the action is attributed to: id, type (human, agent, service, system), optional display, tenant, and onBehalfOf for impersonation or delegation. |
| agent | id, name, version, bundleDigest of the exact agent definition, instructionsDigest of the resolved instructions. |
| model (R) | resolved and provider are required (or the literal none); requested and mode optional. |
| context | References only: tenant, workspace, session, execution, step. |
| policy | verdict (allow, allow_with_obligations, deny, escalate), ref and version of the governing policy, obligations, and per-evaluator detail with decision, code, confidence and reasons. |
| approval | required, decision (approved, rejected, auto, not_required, expired), approver, at, method, and attestation: the id or digest of the Action Approval Attestation that authorised the action. |
| effects | One entry per tool invocation: tool, target system, status, sideEffecting, argsDigest, responseDigest of what the target returned, resultRef to the created or changed object, approvedBy, compensated, error. |
| workProduct | Digests of input and output, and the sources and artifacts relied on. |
| cost | Tokens and estimated cost, with an attribution of exact, approximate or none so the reader knows how reliably cost was tied to the action. |
| outcome (R) | status: succeeded, failed, blocked, denied, cancelled, timed_out. Denied means policy refused; blocked means the runtime refused for another reason, such as a kill switch or a fail-closed condition. |
| integrity | Content digest, MAC or signature, optional per-tenant chain. See below. |
| extensions | Vendor members keyed by reverse-DNS namespace. Consumers ignore what they do not understand. |
Conformance levels
Level 1: Attributable
The required members are present and the record validates against the schema. It answers: who, which agent, which model, what, and what happened.
Level 2: Governed
- Every record carries a policy verdict.
- Every write action, or any action with a side-effecting entry, that was not denied or blocked before execution carries
approvalwithrequiredtrue. - If such an action succeeded, either it was approved by a named approver at a recorded time, or it was auto-approved under a cited policy.
- A record whose verdict is deny never reports a succeeded write.
- Every succeeded side effect carries a response digest or a result reference.
It now answers: on whose authority.
Level 3: Verifiable
The record is sealed: a correct content digest and at least a MAC or a signature. Records should be chained per tenant. It now answers: can this be trusted after the fact.
Canonical form and digests
To digest a record or an attestation: remove its top-level integrity member, drop undefined members, then serialise as JSON with object members sorted by key at every level, arrays in order, no whitespace, and numbers and strings serialised as by ECMAScript JSON.stringify. For standard JSON values this produces the same bytes as RFC 8785. A digest is sha256: followed by the lowercase hex SHA-256 of the UTF-8 bytes. Other content digested the same way, such as tool arguments for argsDigest, keeps every member.
Integrity
Content digest. integrity.contentDigest is the digest of the canonical record without its integrity member.
Keyed MAC. integrity.mac is HMAC-SHA256 over the content digest string, keyed with a dedicated evidence secret (a secret held as text is used as its UTF-8 bytes), base64url without padding. A MAC proves the record has not changed since a key holder sealed it. It cannot be verified by a party without the key.
Signature. integrity.signature uses an asymmetric algorithm such as ed25519 over the same message, for third-party verification. A MAC alone satisfies Level 3; add a signature where outsiders must verify.
Chain. Records may be linked per tenant: a monotonic seq, prev equal to the previous record's content digest (null at genesis), and a link proof, computed like the MAC, over the digest, a full stop, and the previous digest or the literal GENESIS. A chain verifies when sequence numbers are contiguous, every prev matches, every link verifies, and every record verifies. The verifier reports the first failing sequence number. A contiguous segment, such as one day's export, can be verified on its own.
Example
A human-approved email send, Level 2 as written and Level 3 once sealed. Digests are illustrative.
{
"spec": "action-provenance/1.0",
"id": "8d0f2c1e-6f8b-4a2c-9c3e-2b6f1a9d4e70",
"correlationId": "corr_01J9X3Q0Z8K7M2N5P4R6S7T8V9",
"recordedAt": "2026-09-02T03:12:41.902Z",
"action": { "kind": "tool_call", "at": "2026-09-02T03:12:39.117Z", "effect": "write",
"description": "Send the August aged-receivables reminder to Northwind" },
"principal": { "id": "user_2f9a", "type": "human", "display": "Sarah Chen", "tenant": "org_acme" },
"agent": { "id": "agent_finance_ops", "version": "7", "bundleDigest": "sha256:3b7f..." },
"model": { "requested": "gpt-5", "resolved": "gpt-5-2026-03-01", "provider": "azure-openai" },
"policy": { "verdict": "allow", "ref": "pol_finance_outbound_email", "version": "3",
"evaluations": [ { "evaluator": "semantic", "decision": "allow", "confidence": 0.94 } ] },
"approval": { "required": true, "decision": "approved",
"approver": { "id": "user_2f9a", "type": "human" },
"at": "2026-09-02T03:12:38.640Z", "method": "ui",
"attestation": "att_01J9X3PZ9C4D6E8F0G2H4J6K8M" },
"effects": [ { "tool": "outlook.send_email", "target": "microsoft-outlook",
"status": "succeeded", "sideEffecting": true,
"argsDigest": "sha256:5a6b...", "responseDigest": "sha256:c0ff...",
"resultRef": "AAMkAGI2...", "approvedBy": { "id": "user_2f9a", "type": "human" } } ],
"cost": { "inputTokens": 2381, "outputTokens": 412, "estimatedUsd": 0.0143, "attribution": "exact" },
"outcome": { "status": "succeeded" }
}
Relationship to other work
- Agent Action Capsule (SCITT Internet-Draft). An individual Internet-Draft that anchors executed actions with COSE signatures and transparency receipts, and carries the permitting authority as an opaque reference. A record could be a capsule's human-readable payload; the Action Approval Attestation supplies the authority the capsule leaves opaque.
- W3C PROV and PROV-AGENT. The action is an Activity; principal and agent are Agents, with actedOnBehalfOf for delegation; inputs and outputs are Entities identified by digest. Approval and policy verdict have no PROV counterpart and are carried as attributes.
- OpenTelemetry GenAI.
model.providercorresponds to gen_ai.provider.name; requested and resolved to gen_ai.request.model and gen_ai.response.model; token counts to gen_ai.usage.input_tokens and output_tokens. - C2PA. Content provenance authenticates artefacts. Action provenance accounts for behaviour. They coexist.
Implementations
Implementation reports are kept in the standards repository, outside the specification. Renly is implementing this specification in its runtime and does not yet claim a conformance level; see Renly's implementation status.