An Agent Must Not Be the Sole Witness to Its Own Actions

An agent sends a payment instruction, changes a customer record, accepts a supplier term or triggers a production workflow. Later, someone asks a basic question: what happened? The agent’s trace says it acted under policy, received a successful tool response and completed the task. That is useful operational telemetry. It is not, by itself, authoritative evidence.

The structural problem is simple: the component that acted is often also the component narrating the action. An agent can emit a detailed log without being an independent witness. Its runtime may fail, be misconfigured, be compromised, or simply report an interpretation that differs from the effect recorded by the system it called. For an autonomous organization, this distinction becomes consequential as agents gain access to business systems. Accountability cannot rest on self-reporting.

The architectural answer is an independent evidence plane: a protected record of decisions and effects generated at control boundaries outside the acting agent. It is not another observability dashboard. It is a separately administered accountability system that connects authorization, attempted and confirmed effects, and resulting authoritative state.

Telemetry explains operations; evidence supports accountability

Application telemetry is designed to help operators understand a running system. Logs, traces and metrics reveal latency, faults, retries and dependencies. OpenTelemetry provides a strong common representation for this purpose. Its logs specification supports correlation through trace IDs, span IDs, timestamps and resource context. That makes a distributed action easier to reconstruct across components.

Correlation is valuable, but it does not make a record tamper-proof or prove that the reported event was true. A trace identifier can connect an agent request to a policy decision and a database write. It cannot establish that the agent was authorized, that the write reached the authoritative system, or that the record was retained beyond the control of the actor being examined.

NIST SP 800-53 treats auditability as a system of controls, not as the existence of logs. Its controls cover record content, timestamps, protection, non-repudiation, retention and generation. AU-9 specifically addresses protection of audit information and includes enhancements such as storing it on separate systems or components, restricting management access, applying cryptographic protection, dual authorization and read-only access. The direction is clear: a system should not have unrestricted control over the evidence used to assess that system.

“The agent may describe an action. The organization needs other systems to witness whether authorization, effect and state transition occurred.

Put witnesses at the boundaries that matter

A governed runtime should not ask an agent which actions deserve recording. The requirement to create evidence must be enforced by boundaries that the agent cannot bypass within its granted path. In practice, three boundary receipts form a useful minimum.

1. The policy gateway records the authorization decision: which actor requested the action, which delegating identity and purpose applied, which policy was evaluated, which policy version was used, and whether the request was allowed, denied or required escalation.
2. The tool or effect gateway records the attempted external effect and, where available, its confirmation. This is the boundary that sees an API call, payment instruction, outbound message, file transfer or other consequential operation leave the governed environment.
3. The authoritative state store records the resulting state version. A successful tool response does not always mean that the organizational state changed as expected. The authoritative system of record should witness the committed version, rejection or conflict.

These are not three redundant copies of an agent log. They are observations made by distinct components with distinct responsibilities. Their records should share an operation or effect identifier so that reviewers can join them without treating any one record as the complete story. A single material action may have an authorization receipt, an effect-attempt receipt, an effect-confirmation receipt and a state-transition receipt. A denied action should also leave evidence: absence of a business effect is often as important as its presence.

Design the receipt, not just the event stream

An evidence receipt needs enough structure to answer a later question without retaining every sensitive payload. A practical schema is an architectural recommendation, not a field set mandated by one standard. It should include an operation or effect identifier; the actor and delegating identity; the policy decision and policy version; the tool capability and version; input and output digests; authoritative state versions; timestamps; outcome status; and links to predecessor receipts.

Digests and controlled references matter. Full prompts, model outputs and business payloads may be sensitive, commercially restricted or subject to retention limits. An evidence plane should support minimization, access controls and retention policy rather than assume that complete content belongs in a permanent log. The record must establish what material was used or produced at a defined boundary; it does not require indiscriminate collection.

W3C PROV offers a useful semantic model for this structure. Its entities, activities and agents, along with relations such as usage, generation, derivation, attribution, association and delegation, can represent a lineage graph across people, agents, plans and artifacts. An authorization receipt can associate an activity with an agent and delegated authority. A state receipt can show that an entity was generated from a preceding activity. PROV does not provide the protected storage or independent witnessing itself, but it gives the evidence graph a coherent vocabulary.

Make mutation detectable, then monitor the monitors

A separately administered evidence store should be append-only and protected from routine control by the execution environment. Transparency-log techniques add a useful property: submitted records can be organized in a Merkle tree, allowing inclusion and consistency proofs. RFC 9162 specifies these proofs for Certificate Transparency. Sigstore’s Rekor is a deployed example of signed metadata held in an append-only, cryptographically verifiable structure.

This does not mean an append-only log proves the underlying event was truthful. It can provide evidence that a submitted record was included and that views of a log remain consistent. It cannot turn a false statement from a compromised producer into a true one. Nor is one central log automatically enough. RFC 9162 notes that a misbehaving log can present inconsistent views to different clients. Independent monitoring and comparison of log views remain part of the design; Sigstore likewise identifies monitoring as necessary for long-term trust.

The consequence is architectural discipline. Protect the evidence store administratively; collect receipts from independent enforcement and effect boundaries; cryptographically bind and append them; and have separate monitors check that the log remains visible and consistent. Separation reduces the scope of a single compromise. Monitoring reduces the scope of a single operator’s claims.

What this changes for autonomous organizations

An organization built this way can investigate an action as a chain of independently generated claims. Did the agent hold delegated authority? The policy receipt answers. Was a consequential request made outside the organization? The effect gateway answers. Did the system of record commit the expected change? The authoritative state receipt answers. Were these records retained without an unnoticed rewrite? Protected storage, cryptographic proofs and independent monitoring address that question—within their stated limits.

This also changes implementation priorities. Do not begin by asking how to preserve an agent’s chain of thought. Begin by identifying material control boundaries: where authority is checked, where an external effect is attempted, and where organizational state becomes authoritative. Require each boundary to emit a receipt before treating the path as governed. Use OpenTelemetry-compatible context to correlate the records. Use PROV-compatible relations where a durable lineage graph is needed. Keep the evidence plane operationally and administratively distinct from the execution plane.

The goal is neither perfect knowledge nor a ceremonial ledger. It is a record that remains useful when the agent, its session and its self-description are no longer trustworthy. Autonomous organizations will make mistakes, encounter disputes and need to reverse decisions. They need to know not only what an agent says it did, but which independent boundaries witnessed the organization authorize, attempt, confirm and commit the action.

Sources

• NIST SP 800-53 Rev. 5, including AU-9 on protection of audit information.
• OpenTelemetry Logs Specification, on distributed telemetry correlation and representation.
• W3C PROV-DM, on provenance entities, activities, agents and relations.
• RFC 9162, Certificate Transparency Version 2.0, on Merkle-tree inclusion and consistency proofs and split-view risks.
• Sigstore documentation, on Rekor transparency logs and the continuing need for monitoring.