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

[toshiyuki sato <[e-mail]>]

Henk, all,

Thank you for cross-posting the AUDIT charter. I want to flag a specific
composition point with existing RATS building blocks that may be relevant
to the AUDIT scope discussion.

draft-sato-soos-gar-00 (Governance Audit Record) defines a
kernel-generated, kernel-signed audit layer for agentic AI governance.
GAR's Session Audit Record (SAR) is structurally an Attestation Result in
the ar4si sense: it carries evidence of governance execution —
authorization state transitions, human oversight decisions, prohibition
enforcement events, and pre-action intent commitments — that a Relying
Party such as a regulator or national AI safety institute can evaluate
against a known governance policy.

Two specific RATS composition points:

1. ar4si (draft-ietf-rats-ar4si). The SAR is a candidate ar4si Attestation
Result profile for governance execution. The kernel acts as the Attester;
the SAR carries the Evidence; the Relying Party (Verified External Auditor
in GAR terminology) evaluates the SAR against the governance policy the
agent was bound to. The non-suppressibility property — the kernel generates
and signs the SAR independently of the agent and operator — maps directly
to the ar4si attester trustworthiness model: the Attesting Environment is
separate from the target of evaluation.

2. Epoch Markers (draft-ietf-rats-epoch-markers). GAR Type 4 audits are
scheduled cross-session pattern audits that require correlating SARs across
multiple sessions and administrative domains. Epoch Markers provide exactly
the shared freshness anchor needed to make cross-session SAR correlation
verifiable without requiring synchronized clocks across domains. This is a
direct composition use case for Epoch Markers in the agentic governance
context.

The broader AUDIT charter question — how to ensure a compromised agent
cannot forge or drop its own audit trail — is where the RATS attestation
stack provides the answer. GAR's kernel attestation model requires that the
Governance Kernel run in an attested execution environment; the kernel's
signing key is bound to that environment via RATS attestation. Thomas Howe
described three independent defenses against audit forgery on the
agent2agent list; RATS attestation binding is the third and strongest layer.

draft-sato-soos-gar-00:
https://datatracker.ietf.org/doc/draft-sato-soos-gar/

The companion drafts that compose with GAR normatively:
draft-sato-soos-idp-01:
https://datatracker.ietf.org/doc/draft-sato-soos-idp/
draft-sato-soos-hem-01:
https://datatracker.ietf.org/doc/draft-sato-soos-hem/
draft-sato-soos-cap-00:
https://datatracker.ietf.org/doc/draft-sato-soos-cap/

Happy to discuss the ar4si profile mapping in more detail if that would be
useful ahead of Vienna.

Tom Sato
CEO, MyAuberge K.K. /
Chino, Nagano, Japan
[e-mail]

2026年5月20日(水) 20:14 Henk Birkholz <[e-mail]>:

> Dear Rodent Enthusiasts,
>
> 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 RATS for your convenience and awareness
> (as this proposed charter text makes use of the authenticity assurances
> RATS building blocks create). Please have look!
>
> Either in:
>
>
> https://mailarchive.ietf.org/arch/msg/agent2agent/QHFRoQ5g8S7FvoN_Bz6olgx1hn4
>
> 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-charter.md
> >
> > And the architecture draft as reference:
> https://www.ietf.org/archive/id/draft-kuehlewind-audit-architecture-00.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
> >
> >
>
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Tom Sato
佐藤俊之
代表取締役CEO
マイオーベルジュ株式会社
090-6315-1325
[e-mail]