Summary

  • On 31 August the IETF created a non-working-group mailing list for Agent Use of Delegation and Interaction Traceability, or AUDIT. The announcement identifies an interoperability problem; it does not create a working group, adopt an architecture or standardize a record format.
  • A trace ID can join claims made by users, agents and services. It cannot make those claims true. Audit evidence must preserve the producer, covered semantics, authorization generation, relevant clocks and first-effect observation—and must report missing or conflicting records instead of smoothing them into one story.

Imagine an agent booking a hotel. The user approves a room below a price ceiling. A planner delegates the search to one agent and the purchase to another. The purchase agent receives a narrower token, selects a property and sends a reservation request. The hotel returns a confirmation. Every component writes the same workflow identifier.

The resulting trace looks complete. It may still be wrong.

Perhaps the approval expired before the purchase. Perhaps the search agent changed the dates after the user approved them. Perhaps the purchase record was written after the hotel had already charged the card but marked “pre-execution.” Perhaps the agent says the request succeeded while the hotel’s ledger shows a declined payment. Perhaps one service copied the trace identifier from an untrusted header without authenticating the sender. Correlation makes these statements easier to compare; it does not decide which statement deserves belief.

That distinction is the timely issue behind the IETF Secretariat’s announcement. On 31 August 2026 it created a non-working-group mailing list named Agent Use of Delegation and Interaction Traceability, or AUDIT. The notice says existing logs, tracing systems and authorization frameworks capture pieces of agent behaviour but lack interoperable support for correlating user intent, delegation chains, changing authorization state and resulting actions across administrative domains.

The status words matter. A mailing list is a venue. The announcement does not say that the IETF has formed an AUDIT working group. It does not adopt a charter, architecture, header or data model. It does not turn the individual drafts discussed around the subject into IETF consensus. The news is that the missing evidence joins now have a named place for technical work.

Correlation is a join, not a verdict

Distributed tracing already demonstrates both the usefulness and the limit of a shared context. The W3C Trace Context recommendation defines traceparent so different tracing systems can relate requests in one graph and tracestate so vendors can carry additional state. A participant can change the parent identifier, alter sampling, edit its own state or restart the trace at a trust boundary. The sampled bit explicitly does not guarantee that trace data was recorded.

Those semantics are adequate for correlation. They are dangerous if promoted into authority. A trace identifier says that a producer associated one record with a graph. It does not authenticate the producer unless another mechanism does so. It does not prove that the stated parent caused the child, that no branch was omitted, that clocks agree or that the actor possessed the claimed authority. An attacker can repeat a valid identifier. A service can accept an identifier from a caller and then write a locally authentic record about a falsely attributed workflow.

The proposed agent-auditing architecture gets an important part of this boundary right. It distributes record production: users report interactions, agents report decisions, actions and delegations, and services report what crossed their boundaries. An Auditor consumes these accounts and decides whether the evidence supports or contradicts compliance. The Agent is the object under audit, not the narrator that must be trusted.

That design yields a better question than “does the trace exist?” Ask who asserted every edge, under which key and policy, from which trust domain, covering which fields, at which stage, and whether another participant observed the same transition. A graph becomes evidence only through its attributable edges.

Four record classes and five clocks

The architecture draft separates Interaction, Action, Delegation and Authorization Transition records. This is more than schema tidiness.

An Interaction record can show what the user saw, said, approved or refused. It does not prove that the agent obeyed. A Delegation record can state that one actor passed bounded authority to another. It does not prove that the delegator possessed that authority or that the delegate used it within bounds. An Authorization Transition record can record grant, narrowing, step-up, revocation or expiry. It must be joined to the authorization state effective when the act crossed its first effective boundary. An Action record can describe the proposed or executed tool call. It does not, alone, prove either permission or external effect.

The same separation exposes at least five clocks:

  1. when the user interaction occurred;
  2. when a grant or revocation became effective;
  3. when the agent formed the candidate act;
  4. when a service first created an external effect;
  5. when each record was created, signed, stored or externally timestamped.

Sorting by one timestamp field cannot reconcile them. The proposed Verifiable Agent Conversation Records distinguish record creation time from session and entry times. They also acknowledge that visible reasoning can diverge from the process that produced an action. A conversation replay is therefore an asserted representation, not privileged access to causal truth.

Another individual draft, Agent Audit Trail revision 01, makes the temporal issue concrete through a record_phase. It says a denial or escalation logged only after execution does not demonstrate that enforcement preceded the act, and proposes linked pre- and post-execution records. That is a valuable design pressure. It remains an individual proposal, not an adopted IETF rule.

The core evidence test is independent of the eventual field names. A record claiming “denied before execution” needs a protected creation boundary before the sink, an identity for the recorder and evidence that the sink consumed that decision. A timestamp added afterward cannot travel backward and become control.

What the existing building blocks prove

The AUDIT announcement explicitly points toward existing authorization, HTTP, attestation and transparency mechanisms. Each answers a narrower question.

OAuth token exchange can represent subject and actor context while one token is exchanged for another. A valid exchange is evidence about an authorization server’s decision under its policy. It does not reveal every model instruction, prove an unrecorded sub-delegation or establish the service outcome.

The RATS architecture separates an Attester, Verifier, Relying Party, Evidence, Reference Values and Attestation Results. Attestation can strengthen a claim about the environment that produced a record. It cannot turn that environment into the user’s principal or decide whether the recorded act was authorized.

SCITT’s architecture and COSE receipts provide a route to transparent registration and verifiable data-structure receipts. A receipt can show that a statement was registered under a service policy and included in a particular state. It does not make the statement true. It does not establish that its issuer had authority over the subject matter. A transparent falsehood remains false—only harder to erase quietly.

HTTP Message Signatures can authenticate selected message components under a key. The verifier still needs an application profile that says which components matter and what the signer is allowed to assert. Unsigned components remain outside the proof. The signature’s creation time is asserted by the signer unless a separate trusted time mechanism exists.

JSON Canonicalization makes the same logical record hash to the same bytes under defined rules. It solves repeatability, not honesty. An RFC 3161 time-stamp token can show that a message imprint existed no later than a trusted timestamp. It cannot prove that the described hotel booking, configuration change or data transfer occurred at that time.

These mechanisms compose well precisely because their authority remains narrow. The audit system fails when one proof is asked to inherit the job of the next.

Missing records are records about the system

A graph assembled from cooperative producers invites a cosmetic failure mode: the auditor displays only the edges that arrived. Absence becomes invisible whitespace.

The architecture draft admits that it cannot solve an adversarial service that refuses to record its boundary, nor collusion across all roles. That limitation should shape the data model. Every expected boundary needs a declared producer and timeout. If the service-side effect record never arrives, the graph should show “unobserved,” not infer “not executed” from an agent log. If the agent reports success and the service reports failure, both records should remain, with the conflict assigned for resolution. If the user record and delegation record disagree about scope, the auditor should not choose whichever arrived first.

Hash chains do not remove this requirement. A chain can make deletion or reordering within the captured sequence detectable. It cannot reveal an event that was never inserted, an alternate chain that was hidden, or a field the schema did not require. A recorder co-located with the agent can faithfully sign a selective account. Transparency can make the selective account durable without making it complete.

The operational ledger therefore needs expectation records: which service boundaries should emit which receipt, under what condition, by what deadline and with which correlation mapping. Reconciliation compares expected and observed edges. Completeness becomes a testable claim instead of a visual impression.

Auditability can become surveillance

The same context that joins accountability evidence can join a person’s activity across services. The architecture draft warns that a chain identifier may reveal the actors and shape of a workflow, even when payloads are kept elsewhere. Trace Context likewise treats cross-request correlation as a privacy risk.

Lu Heng’s distinction between formal and practical data sovereignty is useful here. An organization may formally own its audit policy while another service holds prompts, tool outputs, trace graphs, signing keys or inclusion receipts. Practical control belongs to whoever can read, correlate, withhold, alter or retain those artifacts.

Do not put the full prompt, reasoning trace or tool output into a globally visible transparency log merely because the record can be signed. Use detached hashes, encrypted payloads and pairwise correlation identifiers where global linkage is unnecessary. Record disclosure purpose, auditor identity, query scope and retention. Redaction must leave a tombstone or fingerprint that exposes the fact and boundary of removal without preserving sensitive content forever.

This is a direct application of Heng’s reality-layer discipline. A trace link, signature, attestation result, inclusion receipt, authorization decision, service response and user outcome are separate facts. Their proximity in one interface cannot merge their meanings.

And running-code primacy supplies the final witness rule. The strongest record of an external effect comes from the independently controlled boundary that could create or refuse it. A reconstructed agent narrative may guide the investigation. It cannot substitute for what the running service observed and changed.

The new IETF list matters because these joins cross protocols and administrative domains. Its success should not be measured by producing one universal story. It should be measured by making incompatible claims, missing witnesses and bounded proofs legible enough that an auditor can reach a defensible conclusion.

Sources