[Audit] Re: Updates on the proposed Audit charter - Please review and comment!

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Henri,

I’m not sure I fully understand the case you are describing. However, I believe this is a question of what you put into the record or how records are recreated by different entities involved. The record format and the question when and how it is created may vary based on different use cases. I see the focus of the working group more on providing the needed communication protocols to collect and assess the records (as well as correlate them to get the full picture) as well as providing some standardized record formats for common cases. But we need some flexibility about the records itself to be able to address a broad set of use case.

Mirja


> On 8. Sep 2026, at 06:48, Henri Sirkkavaara <[e-mail]> wrote:
> 
> Mirja, Henk,
> 
> The scope says the group will define mechanisms that let systems record, exchange and verify audit-relevant information. It does not say what a verifier is assumed to have available. A party reconstructing what an agent did often holds the records and can reach no service. The building blocks named in the scope include SCITT, which a verifier normally reaches over the network.
> 
> My question is whether that party is in scope for the charter.
> 
> If the answer is yes, the charter should also say that a record does not establish key status. Revocation is a property of the present, and a record carries what was true when it was signed and what the recorder observed. Stating that costs no deliverable, and without it the audit data model work reads as promising a check no offline verifier can make.
> 
> Henri Sirkkavaara
> Vaara - Runtime execution layer for AI agents
> Built to see over the noise.
> vaara.io <https://vaara.io/>Helsinki, Finland
> 
> On Tuesday, September 8th, 2026 at 01:04, Mirja Kuehlewind \(IETF\) <ietf=[e-mail]> wrote:
>> Hi all,
>> 
>> In parallel to the update of the audit architecture document, we been also working on some updates to the proposed audit charter text based on the input we got in advance of the IETF-126 Vienna meeting. The architecture draft is intended to only provide further background on the audit problem statement and scope, however, given there is no working group yet, of course anything the in proposed architecture is also still open for discussion. However, in order to potentially form a working group for the audit work, we need make sure that the problem and scope described in the proposed charter text is clear and understandable and that the proposed work in well understood and actionable. That should be the focus for the list discussion for now.
>> 
>> As I said, based on the last round of discussion before IETF-126, we already received a couple of comments and proposed changes for the charter text. We merge those PRs into the updated charter text added below and to be found on GitHub here: 
>> https://github.com/mirjak/audit-bof-preparation/blob/main/audit-charter.md
>> 
>> As you can see, these updates do not address all raised issue syet and also still leaves some PRs open for further discussion. Please have a look! What we addressed so far, are mainly comments on the wording (e.g. remove AI) and clarification on the deliverables. However, there are more issues open for discussion, even on both of these points. Getting broader input on these or any new issues would be great!
>> 
>> Therefore we would like to restart the charter discussion on this new mailing list. Please feel free to continue the discussion based on the raised issues here on the list or raise new issues that need broader discussion now!
>> 
>> Of course you can also continue the discussion on GitHub, however, for issues that likely benefit from boarder input, it makes sense to bring them back to the list. Smaller issues, e.g. such as editorial proposals, can also go directly on GitHub as issue or even PRs.
>> 
>> In general any discussion related directly on the charter text, the general scope of the proposed work, or problem statement are very welcome on the list! Please keep in mind that we don’t have a working group yet; all deliverables or also any content of the architecture draft are just proposals at this point and open for discussion. Therefore it does not make sense yet to contribute work that aims to directly address the proposed work, however, statements of support or concerns related to ongoing work that might not be well-covered by the current charter are very valuable and more then welcome!
>> 
>> Henk and Mirja
>> 
>> ———————
>> Proposed Charter text
>> ———————
>> 
>> # Agent Use of Delegation and Interaction Traceability (AUDIT) Working Group Charter
>> 
>> Autonomous and semi-autonomous software agents, including those based on LLM-based machine learning systems, are increasingly deployed to act on behalf of users, organizations, and services across the Internet. These agents interact across multiple administrative or trust domains and can initiate actions without direct human oversight at each step.
>> 
>> This introduces challenges for auditability, accountability, and transparency, including:
>> 
>> * Difficulty attributing actions to a specific user, agent instance, or delegation context
>> * Loss of visibility across long-running or distributed workflows
>> * Inconsistent capture of delegation relationships, dynamic authorization context, and identity transitions
>> * Cross-domain interactions lack interoperable means to exchange or verify audit-relevant information about the participating agents and their interactions
>> 
>> Agents participate in two distinct classes of interactions that must be audited:
>> 
>> * User-facing interactions, such as prompts, conversations, and approvals, capturing user intent and human-in-the-loop decisions
>> * System-facing interactions, such as API calls, tool usage, and delegation to other agents or services
>> 
>> Effective auditing requires linking user intent to resulting system actions across protocol and administrative boundaries. While traditional workflows support evolving authorization, these transitions are usually explicit and predefined. Agent systems introduce dynamic, fine-grained authorization changes that arise during execution, driven by agent decisions, delegation, and human interaction. Auditing must therefore capture authorization as a time-evolving state and correlate these transitions across interactions and domains.
>> 
>> Additionally, Agent behavior may be non-deterministic and not fully predefined, requiring auditing mechanisms to capture execution context and structure as they emerge. Auditing must also distinguish between user, agent, and service identities, and ensure audit data can be selectively disclose such that it remains interpretable across systems without shared assumptions.
>> 
>> ## Scope and Goals
>> 
>> The AUDIT working group will define interoperable mechanisms for auditing and accountability of Agents and delegated systems across Internet protocols.
>> 
>> The group will focus on architectures, protocol-layer specifications, and data representations that enable systems to record, exchange, and verify audit-relevant information across user-facing and system-facing interactions. This includes capturing delegation chains, evolving authorization state, and enabling consistent interpretation and correlation of audit data across domains.
>> 
>> The working group will compose existing IETF building blocks for identity (WIMSE), attestation (RATS), authorization (OAuth family), transparency (SCITT), context propagation (W3C Trace Context), and conversation containers (vCon), and will define only the additional protocol elements, data models, and best practices needed to make these compose coherently for the AI agent case.
>> 
>> The working group will not define auditing policies or compliance frameworks, but instead provide the technical building blocks needed to support them. Further, while the entities of a complex agents or workload system need to be identifiable, this group will not work on new identity primitives but rely on work in other groups or fora.
>> 
>> The working group will treat privacy, confidentiality, selective disclosure and retention constraints as core design considerations.
>> Mechanisms defined by the working group are expected to support auditability without requiring indiscriminate disclosure of prompts, user content, personal data, or unrelated execution context.
>> 
>> ## Deliverables
>> 
>> The AUDIT working group is expected to produce:
>> 
>> 1. **Architecture for Autononomous Agent Auditing**
>> An Informational RFC describing roles, trust relationships, and data flows for interoperable auditing, including the relationship between user-facing and system-facing audit signals. This document might also identify needed protocol extensions. 
>> 
>> 2. **Audit Data Models and Semantics**
>> One or more Standards Track RFC(s) that identify and reuse existing or specify new IETF data models that can represent aspects of autonomous system (e.g., AI agents) behavior: e.g., interaction records, agent identity, delegation context, authorization state over time, or action provenance. If existing data model are identified the RFC(s) might create profiles that scope them to a degree of disclosure that is appropriate for audits. The group will work on the minimal set of audit information and consider a registry to enable experimentation and fast deployment for additional data models.
>> 
>> 4. **Protocol Extensions or Profiles**
>> One or more Standards Track RFCs specifying profiles of,  extensions to existing ot embodiment into existing IETF protocols (e.g., HTTP headers, OAuth token formats, attestation worksflows, or claims sets in other data items) to convey audit-related information. If this work in done in this working group or the respective protocol maintenance group depends on the protocols and needs to be considered on a case by case basis. The working group may also define protocol-independent data representations intended for use by non-IETF logging, telemetry, or audit systems, while avoiding standardization of those external systems themselves.
>> 
>> 5. **Best Practices for Deployment and Operation**
>> An Informational or BCP document providing guidance for secure, interoperable, and privacy-aware auditing, including correlation across interaction types for different deployoment models and trust domains.
>> 
>> 
>