[SCITT] Re: [agent2agent] Re: New draft on AI Agent Auditing and proposed BoF/WG charter

[Dick Brooks <[e-mail]>]

Mirja,

Thanks for your insights. 
Regarding " Yes, we need some kind of identifiers but I think this new group would need to rely on work done in other groups for this."

I agree, but this identifier technology needs to be available broadly so that anyone can implement a Transparency Service that is protected using a verifiable identifier, like the one suggested in this Internet Draft ztdnaid URI scheme:
https://www.ietf.org/archive/id/draft-brooks-ztdnaid-new-02.txt

A ztdnaid is an Uppercase SHA256 hash over unique data used to identify an entity or resource (DDR) operating in a Zero Trust environment.

This ztdnaid identifier can be verified as trusted before performing any COSE/SCITT processing to ensure that only trusted entities are allowed to register a Signed Statement in a Transparency Service.

We are presently using this ztdnaid approach to protect our own SAG-CTR Trust Registry.

Thanks,

Dick Brooks
   
Active Member of the CISA Critical Manufacturing Sector, 
Sector Coordinating Council – A Public-Private Partnership
Lifetime IEEE Member
Never trust software, always verify and report! ™
Risk always exists, but trust must be earned and awarded.™ 
https://businesscyberguardian.com/ 
Email: [e-mail]
Tel: [phone]


-----Original Message-----
From: Mirja Kuehlewind (IETF) <[e-mail]> 
Sent: Thursday, May 28, 2026 9:16 AM
To: [e-mail]
Cc: Henk Birkholz <[e-mail]>; [e-mail]; Thomas Fossati <[e-mail]>
Subject: Re: [SCITT] [agent2agent] Re: New draft on AI Agent Auditing and proposed BoF/WG charter

Hi Dick,

This is a good question and related to one from Thomas, asking if the working group would define new identity primitives. I think the answer is actually clearly no and I added a sentence to the charter to clarify this. Yes, we need some kind of identifiers but I think this new group would need to rely on work done in other groups for this.

Mirja



> On 20. May 2026, at 14:20, Dick Brooks <[e-mail]> wrote:
> 
> Henk,
> 
> Question regarding this statement: " Additionally, AI 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 remains interpretable across systems without shared assumptions."
> 
> How will these entities assert their identity that may be required for a Zero Trust implementation?
> 
> Thanks,
> 
> Dick Brooks
> 
> Active Member of the CISA Critical Manufacturing Sector, Sector 
> Coordinating Council – A Public-Private Partnership Lifetime IEEE 
> Member Never trust software, always verify and report! ™ Risk always 
> exists, but trust must be earned and awarded.™ 
> https://businesscyberguardian.com/
> Email: [e-mail]
> Tel: [phone]
> 
> 
> -----Original Message-----
> From: Henk Birkholz <[e-mail]>
> Sent: Wednesday, May 20, 2026 7:30 AM
> To: [e-mail]
> Cc: Mirja Kuehlewind (IETF) <[e-mail]>; Thomas Fossati 
> <[e-mail]>
> Subject: [SCITT] Re: [agent2agent] Re: New draft on AI Agent Auditing 
> and proposed BoF/WG charter
> 
> Hi SCITT List,
> 
> on the agent2agent email list, Thomas highlighted that we should share the charter draft for the AUDIT WG BoF proposal with aligned WGs.
> 
> AUDIT: Agent Use of Delegation and Interaction Traceability
> 
> On 20.05.26 09:48, Thomas Fossati wrote:
>> 2. There seems to be quite a lot of overlap with WIMSE, OAUTH, SCITT, 
>> RATS -- at least, which is both good and bad.  To minimise the risk 
>> of overlap, conflict, et cetera, I suggest you make the proposal 
>> visibile to these groups (if you haven't already done it).  I 
>> understand it may be a bit too early to properly engage, but a quick 
>> heads-up would not hurt (_maybe_).
> 
> Mirja just send a sharable copy of the charter text to the agent2agent list. Please let me repost it to SCITT for your convenience and awareness (as this proposed charter text refers to accountability and transparency as enabled by SCITT building blocks). Please have look!
> 
> Either in:
> 
> https://mailarchive.ietf.org/arch/msg/agent2agent/QHFRoQ5g8S7FvoN_Bz6o
> lgx1hn4
> 
> or verbatim below.
> 
> 
> Viele Grüße,
> 
> Mirja & Henk
> 
> 
> On 20.05.26 12:35, Mirja Kuehlewind (IETF) wrote: > Hi all,
>> 
>> To make it easier to comment on the proposed charter text directly, I thought I send another mail with the text directly imbedded. Again any quick comments or expressions of interest before Friday are very welcome, so we can decide on Friday if we want to put a preliminary BoF request in!
>> 
>> Here is the initial draft for the proposed charter text:
>> 
>> —————
>> # Agent Use of Delegation and Interaction Traceability (AUDIT) 
>> Working Group Charter
>> 
>> Autonomous and semi-autonomous software agents, including those based on artificial intelligence (AI), 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, 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
>> 
>> AI 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. AI 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, AI 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 remains interpretable across systems without shared assumptions.
>> 
>> ## Scope and Goals
>> 
>> The AUDIT working group will define interoperable mechanisms for auditing and accountability of AI 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 not define auditing policies or compliance frameworks, but instead provide the technical building blocks needed to support them.
>> 
>> ## Deliverables
>> 
>> The AUDIT working group is expected to produce:
>> 
>> 1. Architecture for AI 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.
>> 
>> 2. Audit Data Models and Semantics
>> One or more Standards Track RFCs defining data models for representing audit information, including interaction records, agent identity, delegation context, authorization state over time, and action provenance.
>> 
>> 3. Protocol Extensions or Profiles
>> One or more Standards Track RFCs specifying extensions to existing IETF protocols (e.g., HTTP, OAuth, or token formats) to convey audit-related information.
>> 
>> 4. 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.
>> —————
>> 
>> Again here is also the link to the charter text on github: 
>> https://github.com/mirjak/draft-audit-architecture/blob/main/audit-ch
>> a
>> rter.md
>> 
>> And the architecture draft as reference: 
>> https://www.ietf.org/archive/id/draft-kuehlewind-audit-architecture-0
>> 0
>> .html
>> -> The draft provides further details and also has four brief examples use cases.
>> 
>> This is all early work, so any feedback is more than welcome!
>> 
>> Mirja & Henk
>> 
>> 
> 
> --
> SCITT mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>