Summary

  • Revision 01 of draft-kuehlewind-audit-architecture, released on 7 September 2026, adds an explicit in-band storage option: each agent may operate an Audit Store and exchange records over the same connection used for the interaction.
  • The draft calls that arrangement an alternative, not a replacement, for an external store and says the two can be combined. It also warns that same-party operation places more trust in the agent operator.
  • Storage is not the whole audit function. The draft separately describes recorders, an Auditing Service, attestation, transparency registration, auditors and verifiers.
  • The document remains an active individual Internet-Draft. The IETF Datatracker says it is not endorsed by the IETF and has no formal standing in the standards process.
  • Daniel Kade proposes a custody-topology receipt that declares which operator controlled each function. It is an editorial proposal, not a requirement of the draft.

The new shortcut carries a trust label

The most consequential addition in revision 01 is only one paragraph long. Section 3.2 says that, instead of exporting records to a separate external Audit Store, each agent may run its own Store. It may send those records to the Store of the agent with which it is interacting, reusing the existing transport connection rather than opening an out-of-band channel.

That can be an attractive deployment choice. An ephemeral agent may already have an authenticated path to its counterpart. Reusing it can reduce extra integrations and allow records to follow a distributed workflow. The text does not present self-hosting as the only design: it calls it an alternative to an external Store, permits both approaches together and states the cost plainly. A Store operated by the same party as the agent places more trust in that party than an independent external Store would.

The paragraph is new. Revision 00 did not contain an in-band storage section. This is therefore a genuine revision event, not a fresh label for unchanged text.

“Audit” names several different acts

The danger is not that in-band storage is inherently invalid. It is that a deployment can flatten a chain of distinct acts into the comforting sentence “the agent is audited.” Revision 01 itself supplies the vocabulary needed to resist that compression.

Principal actors create records from different viewpoints. A user-facing system can preserve intent or approval. An agent can emit action, delegation and authorization-transition signals. A service or tool can record the request it observed at the point of effect. An Audit Recorder captures or transforms those signals. An Audit Store retains and exposes records. The Auditing Service canonicalises observable records, signs them under its own identity and submits them for transparency registration. An Auditor then evaluates evidence under a policy; a verifier can appraise particular claims.

These functions answer different questions. Storage answers where a record can later be found. A signature can answer which key endorsed a statement. Attestation can support a claim about the producing environment. A transparency receipt can support the proposition that a statement existed in a log at a point in time and was not shown inconsistently. Auditor independence concerns who applies judgment. None of those facts, alone, proves that every relevant actor recorded everything truthfully.

This distinction matters because the same draft allows role aggregation. A role is a function, not necessarily a separate deployment unit, and one entity may perform several roles. An agent’s host can also implement its recorder. That is operationally simple, but the draft identifies recorder-collusion risk and points to an independent recorder or non-repudiation through transparency registration as mitigations. Elsewhere, revision 01 says the architecture’s accountability properties require an independent Auditing Service.

The apparent tension disappears when the labels remain precise. A same-party Store may transport and retain records while an independent service canonicalises or commits them. A third party may operate a Store without being the Auditor. An external product may still be controlled by the same corporate group, administrator or key holder. “External” describes placement; “independent” describes control and incentives.

The store’s address cannot prove its custody

Consider two deployments. In the first, an agent writes to a Store in its own process, but a separate service immediately registers signed commitments in a transparency system that the agent operator cannot rewrite. In the second, an agent exports records to a cloud logging account administered by the same team that operates the agent and can delete both the original and the export before any outside commitment.

The second Store is geographically external. The first may provide the stronger historical constraint. The example does not prove that either deployment is complete or compliant. It shows why a network diagram and a vendor count are poor substitutes for a custody record.

RFC 9334 makes a related separation in remote attestation: an Attester produces Evidence, a Verifier appraises it, and a Relying Party applies its own policy to the result. RFC 9943 similarly separates signed statements, transparency services, receipts and relying-party decisions. Those architectures do not turn a component name into an assurance level. Trust emerges from roles, policies, keys and the evidence path.

The individual audit draft remains work in progress. Its Datatracker page records no RFC stream, responsible Area Director or Working Group adoption and displays the explicit warning that an Internet-Draft has no IETF endorsement or formal standards standing. The new storage option should therefore be reported as a proposal under development, not as an IETF rule for agent systems.

Sources