Summary

  • The IETF Datatracker marks the AUDIT BoF request Declined. A non-WG mailing list created on 31 August 2026 provides a place to revise the proposal; it does not create a Working Group.
  • IESG feedback treated auditable agent actions as a worthwhile problem but found the proposed scope too broad and asked for a sharper account of gaps left by OAuth, WIMSE, OpenTelemetry and related work.
  • The individual AUDIT architecture offers a useful vocabulary for interaction, action, delegation and authorization-transition records, yet explicitly leaves refusal to record, universal collusion, model alignment and a detailed threat model unsolved.
  • A durable authority-state receipt should separate discussion venue, BoF decision, charter, draft adoption, IETF review, RFC publication and operational deployment so that evidence of activity cannot be mistaken for institutional mandate.

The state changed, but not into a Working Group

At first glance, the sequence looks like a revival. On 3 June 2026, IESG feedback said the request for an Agent Use of Delegation and Interaction Traceability BoF was being “deferred.” On 31 August, the IETF Secretariat announced a new AUDIT mailing list. A reader moving quickly from the first date to the second could conclude that the proposal had passed its institutional test.

The live records say something narrower. The AUDIT BoF request is classified as a “Declined BOF request,” its state is “Declined,” and it was last updated on 6 July. The broader BoF requests index places it in the same state. Its metadata does not name responsible leadership. The body lists Security Area Directors as proposed responsible ADs and Yaroslav Rosomakho as a proposed chair, but a proposal field is not an appointment.

The later venue is equally explicit about itself. The IETF non-WG list index describes the AUDIT list as a place to discuss a potential BoF, work on updates to a proposed charter and move toward forming a new Working Group. Every decisive verb points forward. At the 1 September cutoff, the public archive contains only the creation announcement. There is no hidden ambiguity here: discussion has a home, while authorization remains to be earned.

That is normal IETF institutional design. The guidelines for non-WG mailing lists expressly contemplate lists intended to form a WG. An appropriate Area Director approves the request to create such a list. The approval grants a communications facility; it does not silently approve a BoF, a charter, chairs, milestones or a standards programme. A venue may be a necessary precursor to mandate without being a smaller version of mandate.

This distinction is easiest to see against RFC 2418, the IETF Working Group guidelines. A WG is created around a narrow charter and operates with responsible Area Directors, appointed chairs, milestones and defined process. It must have a mailing list, but the inference does not run backward. The existence of a list cannot prove the existence of the group any more than an open meeting room proves that its occupants have been delegated corporate signing authority.

“Deferred” in the exchange, “Declined” in the record

The language of the June exchange deserves preservation rather than harmonization. The IESG message, quoted in the proponents’ 5 June reply, used “deferred.” It did not say that auditable agent actions were a bad idea. It described the concept as good while judging the current proposal too broad. It asked the proponents to narrow the scope, consult relevant OAuth and WIMSE participants, and explain why existing work—or an OpenTelemetry profile—would not fill the gap. It also questioned whether some notions of intent and policy belonged in a legal framework rather than an IETF protocol architecture.

The proponents’ response on the agent2agent list challenged the timing and procedural meaning of deferral and defended the need to join evidence across administrative domains. A later scope discussion continued the substantive exchange. Those messages show disagreement about the shape and handling of the request, not an approval displaced into email.

The current Datatracker state should therefore be reported exactly as it stands: Declined. The earlier word “deferred” remains part of the decision history because it explains how the parties discussed the outcome at the time. Neither word should be used to erase the other. A revised request may appear; the present state is not a prediction that the work will never advance. It is a receipt for what the institution has authorized so far.

This is a small example of a recurring governance error. Participation becomes stakeholder status; stakeholder status becomes representative authority; a forum becomes a decision body; technical documentation becomes policy. Heng Lu’s essay on the multi-stakeholder mirage names the underlying confusion: presence and participation do not themselves identify a principal or prove authorization. In standards work, state labels are one of the few defenses against that compression.

The proposal is technically substantial—and still a proposal

The individual AUDIT architecture draft, dated 18 May 2026, starts from a real operational problem. An agent receives an instruction, delegates work, calls services across trust domains and causes an effect. Logs exist, but they are usually local, uneven and unable to answer the combined question: who asked for what, what authority was passed, which action occurred, and what evidence survives?

The draft divides that evidence into four useful families. Interaction Records capture user-facing prompts, approvals and other evidence of intent. Action Records describe what occurred at an execution boundary. Delegation Records describe authority passed from one actor to another, including scope and constraints. Authorization Transition Records record grants, step-up approvals, narrowing, revocation and expiry. A shared audit context can correlate records and point to prior events; multiple actors produce records from their own perspectives; an audit store can canonicalize material for later examination.

Optional attestation and transparency services may strengthen individual claims.

That vocabulary could improve implementations even before any standards decision. It forces designers to distinguish a request from an action and a delegation from a later permission change. It also reveals why a single universal log format is unlikely to solve the whole problem: different boundaries know different facts, and the party executing an action may not be the party capable of proving the original human instruction.

Yet the draft is careful about its limits. It does not assume the agent is trustworthy. It treats an audit store as only partly trusted. It does not solve a service’s refusal to record what occurred at its boundary, collusion among all relevant actors or alignment of the model driving the agent. A detailed threat model remains future work. These exclusions are not footnotes to be hidden by the word “audit”; they define when the architecture cannot support a conclusion.

Privacy is equally structural. Interaction records may expose prompts and user intent. Action records can reveal tool calls, business operations and counterparties. A global correlation identifier can link a person’s activity across organizations. Even registering only a hash with a transparency service can reveal that an interaction existed at a particular time. The more complete a cross-domain trail becomes, the more valuable it is to an auditor—and to an adversary, litigant, employer or surveillance authority.

A companion individual document on verifiable agent conversations may supply one candidate format for user-facing interaction evidence. It too is an individual draft. There is no AUDIT WG that could have adopted it. A signature over a conversation also leaves hard policy questions untouched: which content is minimized, who may decrypt detached material, how redaction is proven, when retention ends and how a conversation is bound to a later action without creating a permanent identifier.

Adjacent standards contribute pieces, not the whole conclusion

The IESG’s overlap question is not bureaucratic obstruction. It is how the IETF prevents an attractive umbrella from duplicating mature work or turning undefined seams into someone else’s responsibility.

RFC 8693, OAuth 2.0 Token Exchange, can represent delegation semantics and actor chains. That helps describe authority transmitted between actors. It does not reconstruct the user’s original instruction, every later authorization transition, the execution result and an auditor’s policy judgment. The RFC also leaves detailed token semantics, security properties and trust models outside its basic protocol scope. A token can be evidence in an authority story; it is not the entire story.

The W3C Trace Context Recommendation propagates identifiers that correlate parts of a distributed request. Correlation is indispensable when an action crosses services. But a trace ID asserts no permission. It cannot show that a delegation narrowed authority, that the user approved a risky step or that the resulting act was correct. Joining two events is not authorizing either event.

RFC 9334, the RATS architecture, supplies roles and messages for remote attestation. Evidence is assessed by a Verifier, and a Relying Party applies policy to an Attestation Result. This can help determine properties of a component or execution environment. It does not establish legal authority, contractual responsibility or fidelity to a human’s meaning. A healthy device can execute an unauthorized instruction perfectly.

RFC 9943, the SCITT architecture, describes signed statements, append-only transparency services and receipts that can prove registration or inclusion. Such machinery can make deletion and retrospective rewriting more detectable. It does not make a signed statement true, demonstrate that all relevant events were recorded or convert a receipt into permission. Cryptographic integrity protects the relationship between a claim and a record; it does not settle the claim’s semantics.

The overlap analysis should therefore be a map of ownership and gaps, not a contest over which acronym wins. OAuth may own specific delegation mechanisms; WIMSE may own workload identity concerns; Trace Context may supply correlation; RATS may attest an environment; SCITT may make selected statements transparent. A proposed AUDIT scope must state what irreducible cross-boundary function remains, who will specify it and how the seams avoid redefining work elsewhere.

Two audit trails, one common discipline

There are really two audit problems in this story. The proposed technical architecture would record authority and action inside agent systems. The institutional record should document authority and action inside standards formation. Their objects differ, but their failure mode is the same: a record of participation is mistaken for the authority that gives the record meaning.

A public standards authority-state receipt need not be elaborate. It should name a stable problem and the exact proposal version. It should record the current state—proposal, declined or deferred BoF, non-WG discussion, approved BoF, chartering, active WG or concluded work—and the actor competent to create that state. It should link the dated decision without inflating its wording. Each revision should state the scope delta, especially the work removed or assigned to adjacent groups.

Leadership requires the same care. Proposed ADs and chairs remain labelled proposed until appointment. The discussion venue is recorded separately from authority. An approved charter needs an exact revision and approval date; otherwise the charter field is null. A document must be labelled individual or WG-adopted, with the adoption record. Working Group last call, IETF last call, IESG evaluation and unresolved objections are separate states.

Publication should identify Internet-Draft status, RFC stream and category rather than use the undifferentiated label “standard.” Implementations and operational policies belong in a deployment field, not in the publication field.

The receipt should be append-only in meaning even when its presentation is updated. A later successful BoF must link back to the declined request and state what changed. An adopted draft must not retroactively turn its individual revisions into WG products. A published RFC must not erase unresolved deployment choices. Old decisions are evidence of the path by which mandate was acquired.

For the AUDIT proposal, the receipt at the cutoff is short: an individual architecture draft exists; a version 02 BoF request was discussed; IESG feedback found the scope too broad; the Datatracker records the request as Declined; a non-WG list now hosts work on a possible new request and charter; no responsible leadership, approved charter, WG adoption or IETF consensus exists. That description is neither hostile nor promotional. It is accurate enough to let the next state be recognized when it arrives.

Accountability without a surveillance default

If the discussion progresses, privacy cannot be postponed until after the record model stabilizes. Data minimization must be defined by record family. Content that need not cross a boundary should remain detached, with hashes or selectively disclosed claims rather than full prompts. Pairwise or opaque identifiers should replace global identifiers where cross-organization linkage is not required. Auditor access must be separately authorized, not inferred from the fact that records exist.

Retention also needs more than a universal expiry number. Operational debugging, contractual evidence, security investigations and regulated records have different purposes and policy owners. Deletion can conflict with transparency, while permanent inclusion can conflict with privacy and correction. A sound design should make gaps, refusals and unavailable evidence visible instead of inventing continuity. A receipt should prove exactly which record it covers, never imply that the record set is complete.

This is where institutional precision has technical value. A narrow charter can force the group to decide which privacy properties are protocol requirements, which belong in deployment profiles and which remain legal or organizational controls. It can keep “intent” from becoming an unlimited demand to capture human thought. It can make threat modeling, omission handling and selective disclosure deliverables rather than aspirational paragraphs.

The new list is the right place to do that work. Calling it merely a list does not diminish the participants. It protects their work from premature institutional branding and gives them a clear target: produce a narrower problem statement, a defensible overlap map and privacy constraints strong enough that a future decision can carry real authority.