| Internet-Draft | vCon Agent Roadmap | November 2026 |
| Petrie | Expires 6 May 2027 | [Page] |
AI agents converse with people, other agents and tools. There is a growing need to capture these conversations for audit, compliance and review. This document sorts the requirements for capturing agent conversations into those that fit vCon, those better met by plain logging and those that need other solutions. It then identifies the gaps in vCon and proposes a strawman set of vCon extensions to fill them. It is intended as a discussion document.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://dgpetrie.github.io/draft-petrie-vcon-agent-audit-roadmap/draft-petrie-vcon-agent-audit-roadmap.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-petrie-vcon-agent-audit-roadmap/.¶
Discussion of this document takes place on the Virtualized Conversations Working Group mailing list (mailto:vcon@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/vcon/. Subscribe at https://www.ietf.org/mailman/listinfo/vcon/.¶
Source for this draft and an issue tracker can be found at https://github.com/dgpetrie/draft-petrie-vcon-agent-audit-roadmap.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
AI agents act on behalf of people and other agents. They exchange prompts and responses with people, delegate to other agents and invoke tools. Several drafts define requirements for recording these interactions (e.g. [VACR] and [AUDIT-ARCH]).¶
vCon [VCON-CORE] is a container for conversation data and the analysis of it. A vCon captures the observation of a conversation from one or more points in the network. An agent conversation is not that different from a contact center conversation in this respect. We do not want to solve all of this with vCon. vCon is a good fit for some of the requirements, but some are better met with plain logging and some need other solutions.¶
This document:¶
sorts the requirements into vCon, logging and other solutions¶
identifies the gaps between the vCon requirements and [VCON-CORE]¶
proposes a strawman break down of vCon extensions to fill the gaps¶
This is a first cut and is surely incomplete. We would like feedback on what is missing or should not be included.¶
+------+ +-------+ +---------+ +----------+ +------+
| User |---| Agent |---| Agent |---| Subagent |---| Tool |
| | | | | Gateway | | | | |
+------+ +-------+ +---------+ +----------+ +------+
^ ^ ^ ^ ^
(1) (2) (3) (4) (5)
(n) = example observation points
The observation points in Figure 1 are examples, not an exhaustive list. A conversation may be observed from any point in the network that it passes through, such as a gateway (e.g. [DMSC-PS] and [DMSC-GW]), a proxy or a platform. In back end scenarios where communications inside a silo are less secure, ordinary network entities may also be observers. Each observation may go in a single vCon or in separate vCons that are linked or merged later. This is the same as a contact center call, which may be observed by the carrier, the contact center platform or both.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
See section 2.1 of [VCON-CORE] for terminology used in this document.¶
Agent: As defined in [AUDIT-ARCH], "a Workload whose behaviour is driven, in whole or in part, by a non-deterministic decision process (typically an LLM)".¶
Tool: As defined in [AGENTIC-REQS], "an external service invoked by an agent to retrieve data or perform operations. A tool is not necessarily an agent and may not participate in agent-to-agent communication."¶
Observation Point: A point in the network from which a conversation, or part of it, is observed and recorded (see Figure 1).¶
The requirements considered here come from two sources:¶
the four record types in section 5 of [AUDIT-ARCH]¶
Related work on AI logging includes [ISO-24970]. We only briefly summarize the requirements here, enough to jog the memory of someone who has read the source drafts.¶
Each requirement is put into one or more of the following categories:¶
vCon - the conversation and the analysis of it¶
Logging - system and operational events¶
Other Solutions - existing or other IETF work¶
Some requirements are split across categories.¶
The agent protocols themselves (e.g. [MCP] and those in [AGENTIC-REQS]) are not candidates for capture in vCon. The data exchanged over them, and the results of them that bear on the conversation (e.g. identity or the tools discovered), are candidates for observation and capture in vCon.¶
REQ-1, REQ-4 Event Logging and Type: conversation level events such as session start and end and permission requests and grants¶
REQ-3 Actor Identification: people, agents and tools as parties¶
REQ-5 Input/Output Recording: prompts, responses, agent to agent messages and tool invocations and results, with reasoning traces as analysis¶
REQ-7 Tamper-Evidence and Integrity: integrity of the record itself, signing and encryption¶
REQ-10 Human Oversight: a reviewable and redactable record of the conversation¶
REQ-11 Traceability: one vCon with one or more observation points, or separate vCons linked or merged later¶
The same conversation observed from different points may result in different, duplicate or conflicting data. vCon records observations, it does not reconcile them. Conflicting observations are kept, each attributed to its observer. Any reconciliation can be added as an Analysis.¶
Token usage is partially captured in vCon today, as vendor responses (e.g. from a LLM or transcription service) are often attached as an Analysis and include token counts. A more formal definition of token usage would be useful to contact center as well as agent to agent and audit scenarios.¶
From [AUDIT-ARCH]:¶
Interaction Records: prompts, responses, approvals, refusals and agent to agent dialog¶
Action Records: the agent view of a tool invocation, the tool or service side record is another observation point which may go in the same vCon, a linked vCon or a log¶
Delegation Records: only the structure of which agent delegated to which subagent (i.e. Session and Session_Reference)¶
Authorization Transition Records: only the parts requested of a person or agent in the conversation¶
REQ-1, REQ-4 Event Logging and Type: system level events such as configuration and prompt changes and infrastructure events¶
REQ-2 Timestamp: clock synchronization¶
REQ-8 Incident Response: queries over logs and vCons¶
REQ-9 Anomaly and Risk Detection: queries over logs and vCons¶
From [AUDIT-ARCH]:¶
Action Records: the tool or service side record, when not put in a vCon¶
[AAT] and [OTEL-GENAI] are examples of logging formats for agents.¶
REQ-6 Retention Period: storage and policy¶
REQ-7 Tamper-Evidence and Integrity: non-repudiation and attestation (e.g. [SCITT] and [RATS])¶
From [AUDIT-ARCH]:¶
The following compares the vCon requirements in Section 3.1 with what [VCON-CORE] already provides. The gaps are filled by the strawman extensions in Section 5.¶
REQ-1, REQ-4 Event Logging and Type¶
Covered: Session start and duration, join and drop Events¶
Gap: permission and directive requests and responses -> Section 5.5¶
Gap: policy decisions on whether an operation may be performed -> Section 5.4¶
REQ-3 Actor Identification¶
Covered: Party Object, including type "bot", uuid, did and validation¶
Gap: agent attributes such as model, provider, framework, version and workload identity -> Section 5.1¶
TODO: is the Party type "bot" sufficient, or are there kinds of agents that need to be distinguished beyond these attributes?¶
Gap: tools, which are named resources rather than Parties -> Section 5.3¶
REQ-5 Input/Output Recording¶
Covered: text Dialog for prompts, responses and agent to agent messages¶
Gap: structured agent to agent content that is not just text, audio or video -> Section 5.2¶
Gap: tool invocations and results -> Section 5.4¶
Gap: the tools available to an agent and their definitions -> Section 5.3¶
Partial: reasoning traces can be an Analysis today, but there is no Analysis type for them -> Section 5.6¶
Partial: token usage is often in an attached vendor response, but is not formally defined -> Section 5.7¶
REQ-7 Tamper-Evidence and Integrity¶
REQ-10 Human Oversight¶
REQ-11 Traceability¶
Covered: Session and Session_Reference, including the AI Agent example in the sessions Objects Array section of [VCON-CORE]¶
Covered: an observer can be a Party¶
Gap: which observer captured which Dialog, Event or Analysis, and where it was in the network -> Section 5.9¶
Gap: grouping or linking separate vCons, as Session_Reference only refers to Sessions in the same vCon -> Section 5.10¶
Gap: correlation with audit context outside of the vCon -> Section 5.11¶
General, also applies to contact centers¶
Covered: Analysis mediatype, vendor, product and schema¶
Gap: no standard media types for the data of common analysis (e.g. transcripts), making it hard to use one analysis as input to another -> Section 5.8¶
The [AUDIT-ARCH] record types map onto the same gaps. Interaction Records are covered by Dialog and Section 5.5, and the policy decisions which precede them by Section 5.4. The agent view of an Action Record is covered by Section 5.4, the tool or service side by Section 5.9. The structure of Delegation Records is covered by Session and Session_Reference. The conversation parts of Authorization Transition Records are covered by Section 5.5, and the policy decisions by Section 5.4.¶
TODO: one subsection per extension: gap and a sketch.¶
Each of the following is listed as a separate extension. Some could be bundled into a single draft, for example:¶
AI Agent: Section 5.1 and Section 5.2¶
Tools: Section 5.3 and Section 5.4¶
Analysis Data: Section 5.6, Section 5.7 and Section 5.8¶
Multiple vCons: Section 5.10 and Section 5.11, with Section 5.9¶
TODO: model, provider, framework, version and workload identity. TODO: the model may change mid conversation, so it may be a Session or Dialog parameter, with an Event to mark the change. TODO: workload identity (e.g. WIMSE), possibly via the existing did parameter or a new one.¶
TODO: a new Dialog type, or at least a new media type for Dialog content, for structured agent to agent exchanges (e.g. a JSON container). TODO: tweak the text Dialog definition in [VCON-CORE], or justify agent messages as transcribable text. TODO: the [VACR] media type covers a whole record, not a single one directional message, ask for a single entry media type or define one.¶
TODO: revisit with more detail.¶
Defined in draft-petrie-vcon-tool-invocation, with [MCP] as the first protocol mapped:¶
Event Object types for each step of a tool invocation, from the request sent to the tool to its result, failure, protocol error, denial by the tool, timeout or cancellation, including pending operations, progress and requests for input from the tool¶
a policy-decision Event Object type, recording whether an operation is allowed, disallowed or requires permission, for one operation or standing¶
an operation_id which correlates the policy decision, the attempts of a tool invocation and, in future, permission requests and responses¶
the server and tool which identify a tool, without the tool definitions themselves (see Section 5.3)¶
Before an agent performs an operation (e.g. invoking a tool), the agent or its host makes a policy decision whether the operation may be performed. The outcome may be that no permission is needed, that permission is required or that the operation is disallowed. No one is asked, so there is no conversation, only the decision and what it applies to. In some cases it is likely desirable to also capture the reason for the decision (e.g. why the operation was disallowed). The policy decides whether the decision applies to one operation only or is standing. Recording the decision is in scope, making or enforcing it is not (see Section 3.4).¶
Permission and directive requests occur within tool invocations (e.g. [MCP] elicitation), as well as directly in dialog with an AI agent.¶
This covers a request for permission or input to the person or agent on whose behalf the agent is acting, and their response. This is part of the conversation. The response may be more than yes or no (e.g. allow once, allow for the Session, always allow or a choice from a menu).¶
The request is distinct from the policy decision in Section 5.4, and is recorded separately. Only a decision that permission is required is followed by a request. [AAT] and [AUDIT-ARCH] partially capture this distinction. The requirements identified so far are outlined in draft-petrie-vcon-tool-invocation, including requests passed along a chain of agents, requests which end without an answer, directives no one asked for, answers given out of band and more than one approver.¶
TODO: [MCP] elicitation (form and URL modes, accept, decline and cancel) as a model. TODO: [MCP] does not define a message for tool invocation approval, that is left to the host.¶
TODO: reasoning traces.¶
TODO: supplemental data on the Analysis Object, separate from the analysis content, and on Dialog generated by a LLM. TODO: applies to contact centers as well.¶
TODO: standard media types for the data of common analysis, starting with transcripts. TODO: applies to contact centers as well.¶
TODO: applies to contact centers as well. TODO: may be mostly a definition of how to use the existing schema (e.g. observer as a Party), rather than new parameters, plus observer location or entity.¶
TODO: a Group Object that refers to zero or more vCons, grouping vCons in a similar way that Session groups Dialog. TODO: the "group" parameter is reserved in the vCon Object Parameter Names Registry in [VCON-CORE]. TODO: different from Observer perspectives, but may need to support them.¶
TODO: AUDIT trace ID, parent ID and delegation chain.¶
TODO: is the Party type "bot" sufficient for agents, or are there kinds of agents to distinguish beyond model, provider, framework, version and workload identity¶
TODO: where the tool side record of an invocation goes¶
TODO: Observer as an extension or later in core¶
TODO: overlap between Agent Analysis Types and Standard Analysis Media Types¶
TODO: linking, merging and de-duplicating vCons of the same conversation from different observation points, and handling conflicts¶
TODO: policy decisions for operations other than tool invocations, and whether operation names need a registry¶