]> Fraunhofer SIT

henk.birkholz@ietf.contact

SIPez LLC

dan.ietf@sipez.com

VCONIC

ghostofbasho@gmail.com

jdrosen.net

jdrosen@jdrosen.net

orie@or13.io

Applications and Real-Time Virtualized Conversations conversation vcon AI agent verifiable evidence transparency auditability AI agents that use large language models increasingly perform consequential tasks on behalf of humans and other AI agents. Demonstrating that recorded AI agent behavior truthfully represents actual behavior is essential for accountability, compliance, and human oversight. To achieve that goal, this document defines an extension to the Virtualized Conversation (vCon) object format, allowing a vCon to capture a conversation between a human and an AI agent, or between AI Agents. The vCon core format can already capture the back and forth messages (including text and voice) sent by AI agents, but additional extensions are required to fully reproduce the AI agent trajectory, such as agent metadata, message exchanges, tool invocations, reasoning traces, system events, file attribution, etc. This document defines those extensions in both descriptive language and formal CDDL definitions. This draft is a replacement for the former Verifiable Agent Conversation Records specification, which was a standalone format and not an extension of vCon. About This Document Status information for this document may be found at . Discussion of this document takes place on the Virtualized Conversations Working Group mailing list (), which is archived at . Subscribe at .

Introduction An AI Agent is a system that performs actions on behalf of a principal in a fully or semi-autonomous fashion. AI Agents are growing rapidly in their adoption across the Internet, finding usage in business, consumer, government and other applications. Yet, AI agents - like humans - are not infallible. They make mistakes, they misunderstand, and they may even act maliciously. This is creating demand for visibility, auditability, and traceability of AI agent actions. Some examples:

• An agent authorized to read files might invoke tools to modify production systems or exfiltrate sensitive data beyond its authorization scope. The CISO of the company may need to investigate what happened.
• An agent's visible CoT output might diverge from the reasoning that actually produced its actions, resulting in a loss of revenue that the finance team needs to investigate
• An agent might deliberately underperform during capability evaluations while performing at full capacity during deployment, causing the IT department to need to consider other vendors
• An enterprise making use of an AI agent from another vendor, using it to perform accounting work, may be later audited and need to have supporting documentation on what the AI agent did and why.
• A small business may use an AI agent to manage its inventory, and upon discovering an error, might need a complete trace of what the agent did to determine what went wrong.

These use cases also extend into the legal realm. An enterprise using an AI agent for screening job applicants may later get sued by an applicant that was passed up for a role. The enterprise might subpoena the AI agent vendor, requesting a full trace of what the AI Agent did, and why. Similarly, a governmental body investigating malicious steps taken by an AI Agent, might request a full log of all of the sessions that AI Agent had. In all cases - there is a need to exchange information between organizational domains, and then to process that information to obtain important insights. To do this, a standardized object format is required. This object format needs to carry the record of the conversation between the principal (typically a user, but potentially an AI Agent), and the AI agent which is acting on its behalf. This record needs to contain all of the information needed to answer critical questions - why did it do, when did it do it, how did it do it, and why did it do it? This need grows even further in cases where AI Agents themselves begin communicating with other AI agents, which may in turn communicate with further AI agents. This will create a web of AI agent interactions. Without a standardized format for documenting the actions of each agent, and how they chain together, it will become impossible to satisfy industry needs for tracing, troubleshooting, auditing, reconciliation, and so on. If, as some predict, we see as many AI agents accessing the Internet as we have humans accessing it, the need becomes dire. This specification addreses that need. It does so by building upon the vCon specification . A vCon is a Virtualized Converation, which captures the content of any conversation (such as a call, chat, or meeting), along with its meta-data. Interactions between users and AI Agents, or between AI Agents, are also conversations, making vCon a natural foundation to build upon. vCon however is missing additional information that is important to capture when a participant is an AI Agent. Examples include tool calls and their results, token usage, model versions, and so on. This document provides an extension to the core vCon specification, using its established extension points, adding in this missing information. It also provides the CDDL for these extensions, using the defined CDDL sockets.

Goals This specification has the following goals:

1. To assure that the recording of an agent conversation (a distinct segment of the interaction with an autonomous agent) being proffered is the same as the agent conversation that actually occurred.
2. To provide a general structure of agent conversations that can represent most common types of agent conversation frames, is extensible, and allows for future evolution of agent conversation complexity and corresponding actor interaction.
3. To use existing IETF building blocks to present believable evidence about how an agent conversation is recorded utilizing Evidence generation as laid out in the Remote ATtestation ProcedureS architecture .
4. To use existing IETF building blocks to render conversation records auditable after the fact and enable non-repudiation as laid out in the Supply Chain Integrity, Transparency, and Trust architecture .
5. To enable detection of behavioral anomalies in agent interactions, including unauthorized tool invocations, inconsistencies between reasoning traces and actions, and performance modulation across evaluation and deployment contexts, through structured, comparable conversation records.
6. To enable cross-vendor interoperability by defining a common representation for agent conversations that can be translated from multiple existing agent implementations with distinct native formats.
7. To produce records suitable for demonstrating compliance with emerging regulatory requirements for AI system documentation, traceability, and human oversight.
8. To allow software-based analysis of the records to achieve these goals, either with or without the aid of an LLM.
9. To allow human-based observation of the records.
10. To ensure that records can be authenticated and encrypted, without relying on transport or storage security to provide these capabilities.

Most agent conversations today are represented in "human-readable" text formats. For example, JSON is considered to be "human-readable" as it can be presented to humans in human-computer-interfaces (HCI) via off-the-shelf tools, e.g., pre-installed text editors that allow such data to be consumed or modified by humans. However, if we wish for these records to be processed by traditional software, a documented format with well-defined syntax and semantics is required. If we further wish for this format to be valid across AI agent vendors, a standard is required. A vCon is a JSON document, and so are the agent conversation records extensions defined in this document. The signed and the encrypted forms of a vCon defined in apply unchanged. The application of COSE to vCons that carry agent conversation vCon records is described in the SCITT architecture .

Transition from Verifiable Agent Conversation Records to a vCon extension The data definitions in this document originate from the stand-alone Verifiable Agent Conversation Records specification . This Internet-Draft rebuilds them as an extension of the vCon CDDL definition. Each high level part of a Verifiable Agent Conversation Record is assigned to one of the extension points that defines as CDDL sockets, and the sections of this document follow these extension points. CDDL definitions that are used by more than one extension point are collected in after the sections for the extension points. maps each data item of to its place in this document. The vCon concepts of Session and Event that this extension builds upon were proposed to accommodate AI agent conversations in . and describe related approaches that carry agent session data and generation provenance in a vCon.

Editor's Note:

The assignment of each part of a Verifiable Agent Conversation Record to a vCon extension point is preliminary. Each section that defines parameters for an extension point lists alternatives that are still open for discussion.

Editor's Note:

This document is based on the editor's copy of (CDDL syntax version 0.5.0), which introduces the Session Object and the Event Object. Sections of are therefore referenced by name and not by number.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. In this document, CDDL is used to describe the data formats of agent conversations in the JSON form accodring to vCon CDDL definitions.

Terminology See the Terminology section of for terminology used in this document. The following terms are used in this document:

Agent:

Also known as an AI Agent, it is an autonomous software system, typically based on a large language model, that is represented by a Party Object and that produces messages, invokes tools, and produces reasoning.

Agent Session:

A session of an agent, represented by a Session Object.

Entry:

A discrete, system-recorded event of an agent session in the native format of an agent implementation, such as a message, a tool call, a tool result, a reasoning step, or a system event. In a vCon, an entry is represented by a Dialog Object or by an Event Object.

Recording Agent:

The tool or agent that generates the vCon, as distinct from the agent that conducted the conversation.

Extension Name The extension name for this document is "ai_agent". The string token "ai_agent" SHOULD be included in the extensions parameter of a vCon that contains any of the parameters or Event Object types defined in this document. As described in and , this extension is intended to be fully interoperable with the vCon definitions and the name "ai_agent" is not inlcuded as a critical parameter.

Parameter Definitions This section defines the parameters and Event Object types of the "ai_agent" extension. There is one subsection for each extension point of that this extension uses. Each subsection contains the CDDL that plugs into the corresponding socket of the vCon CDDL. New Objects are defined in the subsection of the extension point at which they are introduced. The record unifies two complementary perspectives: the agent session captures how code was produced (the full conversation replay), while file attribution captures what code was produced (which files were modified and by whom).

Extension Points Defined by this Document Each Object defined in this document that does not allow arbitrary additional members ends with a CDDL group socket, so that other extensions can add parameters to it. Each Event Object type defined in this document also ends with a CDDL group socket. The following CDDL group sockets are defined in this document. CDDL Group Extension Points Defined by this Document

Object	CDDL Socket	Defined in
File_Attribution	$$file-attribution-ext
File	$$file-ext
File_Conversation	$$file-conversation-ext
Range	$$range-ext
Contributor	$$contributor-ext
Resource	$$resource-ext
"tool-call" type Event Object	$$tool-call-event-ext
"tool-result" type Event Object	$$tool-result-event-ext
"reasoning" type Event Object	$$reasoning-event-ext
"system-event" type Event Object	$$system-event-ext

Editor's Note:

The Recording_Agent, Agent_Meta, Environment, Token_Usage, and VCS_Context Objects allow arbitrary additional members (* tstr => any), as in . Whether these Objects get a CDDL group socket in addition to or instead of this wildcard is for further discussion.

vCon Object Parameters This extension adds the following parameters to the vCon Object, using the vcon-ext socket:

CDDL for the ai_agent Parameters of the vCon Object any } ; File_Attribution Object file_attribution_type = { files: [* file_type], * $$file-attribution-ext } ; File Object file_type = { ; relative path from the repository root path: tstr, conversations: [* file_conversation_type], * $$file-ext } ; File_Conversation Object file_conversation_type = { ? url: uri_type, ; default contributor for all ranges ? contributor: contributor_type, ranges: [* range_type], ? related: [* resource_type], * $$file-conversation-ext } ; Range Object range_type = { ; 1-indexed start_line: uint, ; 1-indexed, inclusive end_line: uint, ? content_hash: tstr, ; default: "sha-256" ? content_hash_alg: tstr, ; overrides the conversation level contributor ? contributor: contributor_type, * $$range-ext } ; Contributor Object contributor_type = { type: "human" / "ai" / "mixed" / "unknown", ? model_id: tstr, * $$contributor-ext } ; Resource Object resource_type = { type: tstr, url: uri_type, * $$resource-ext } ; URI (RFC 3986) uri_type = tstr .regexp "(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?" ]]>

Editor's Note:

Alternative placements for recording_agent are a Party Object that represents the recording tool and the Attachment Object. An alternative placement for file_attribution is the Attachment Object, as proposed in .

recording_agent The recording_agent parameter identifies the tool or agent that generated this vCon, as distinct from the agent that conducted the conversation. This distinction matters for provenance chains: the recording tool's version affects how native data is translated into the canonical data definition specified in this document.

• recording_agent: "Recording_Agent" (optional)

The Recording_Agent Object contains the following members:

name:

The name of the recording tool or agent.

version:

The version of the recording tool.

vcs The vcs parameter provides version control metadata at the record level (repository, branch, revision).

• vcs: "VCS_Context" (optional)

The VCS_Context Object is defined in .

file_attribution NOTE: This section is specified but not yet validated against real session data. Implementation or validation against a healthy example corpus is pending. File attribution captures what code was produced: which files were modified, which line ranges were changed, and who authored them.

• file_attribution: "File_Attribution" (optional)

The File_Attribution Object is the top-level container for file attribution data. It holds an array of files, each with their attributed line ranges and contributor information.

files:

Array of File Objects with attributed ranges.

$$file-attribution-ext:

A CDDL socket that can be used to extend the File_Attribution Object. See .

A File Object represents a single source file that was modified during the conversation. It groups all conversations that contributed changes to this file.

path:

The file path relative to the repository root.

conversations:

The conversations that contributed modifications to this file, as an array of File_Conversation Objects.

$$file-ext:

A CDDL socket that can be used to extend the File Object. See .

A File_Conversation Object links a specific session to the line ranges it produced in a file. This enables tracing from a line of code back to the conversation that generated it.

url:

A URL pointing to the conversation source (e.g., a web UI permalink).

contributor:

The default contributor for all ranges in this conversation. Can be overridden per-range.

ranges:

The line ranges in the file that were produced by this conversation.

related:

External resources related to this conversation (e.g., issue trackers, documentation).

$$file-conversation-ext:

A CDDL socket that can be used to extend the File_Conversation Object. See .

A Range Object identifies a contiguous block of lines in a file that were produced by a specific conversation. Line numbers are 1-indexed and inclusive. The optional content hash enables position-independent tracking when lines move due to later edits.

start_line:

The first line of the range (1-indexed).

end_line:

The last line of the range (1-indexed, inclusive).

content_hash:

A hash of the range content for position-independent identification.

content_hash_alg:

The hash algorithm used (default: "sha-256").

contributor:

Overrides the conversation-level contributor for this specific range.

$$range-ext:

A CDDL socket that can be used to extend the Range Object. See .

A Contributor Object identifies who authored a range of code. The type member distinguishes between human-authored, AI-generated, mixed, and unknown authorship.

type:

The authorship category.

model_id:

The model identifier for AI-authored ranges.

$$contributor-ext:

A CDDL socket that can be used to extend the Contributor Object. See .

A Resource Object represents an external reference related to a conversation, such as an issue tracker entry, a pull request, or a documentation page.

type:

The resource type (e.g., "issue", "pr", "documentation").

url:

The URL of the resource.

$$resource-ext:

A CDDL socket that can be used to extend the Resource Object. See .

Editor's Note:

The content_hash member of the Range Object is not a ContentHash as defined in . Aligning both is for further discussion.

Party Object Parameters This extension adds the following parameter to the Party Object, using the party-ext socket:

CDDL for the ai_agent Parameters of the Party Object any } ]]>

Editor's Note:

Alternative placements for agent_meta are the Session Object and the generation provenance of .

agent_meta The agent_meta parameter identifies the coding agent and language model that a Party Object represents. Agent identification is essential for provenance tracking: knowing which model produced which output enables auditing, capability assessment, and compliance verification. The type parameter of a Party Object that contains agent_meta SHOULD be "bot".

• agent_meta: "Agent_Meta" (optional)

The Agent_Meta Object contains the following members:

model_id:

The primary language model identifier, using the naming convention of the provider (e.g., "claude-opus-4-5-20251101", "gemini-2.0-flash").

model_provider:

The provider of the primary model (e.g., "anthropic", "google", "openai").

models:

List of all model identifiers used during the session. Relevant for multi-model sessions where the agent switches between models.

cli_name:

The name of the CLI tool or agent framework (e.g., "claude-code", "gemini-cli", "codex-cli").

cli_version:

The version of the CLI tool.

Session Object Parameters An agent session is represented by a Session Object. It captures the full conversation between a user and an autonomous agent. The Dialog Objects and Event Objects that are part of the Session Object represent messages, tool invocations, reasoning steps, and system events. Together, they preserve the complete interaction history including all native agent metadata, enabling both replay and audit of the conversation. The start parameter of the Session Object provides the time the agent session began, and the duration parameter provides the time until the agent session ended. An agent that spawns sub-agents is represented by a Session Object that references the Session Objects of the sub-agents using the Session_Reference type "child", as described for AI agents in . This extension adds the following parameters to the Session Object, using the session-ext socket:

CDDL for the ai_agent Parameters of the Session Object any } ]]>

agent_session_id The agent_session_id parameter contains an opaque string uniquely identifying the agent session in the native format of the agent implementation. Values may be UUID v4, UUID v7, SHA-256 hashes, or other formats. The agent_session_id parameter is distinct from the session_id parameter of the Session Object, which contains a SessionId Object.

• agent_session_id: "String" (optional)

format The format parameter classifies the session style, such as "interactive" (human-in-the-loop) or "autonomous" (fully automated). Informative only; does not change the structure.

• format: "String" (optional)

environment The environment parameter captures execution context for the conversation: where the agent was running, what version control state was active, and whether sandboxing was in effect. This context is important for reproducibility and for understanding the scope of file modifications.

• environment: "Environment" (optional)

The Environment Object contains the following members:

working_dir:

The primary working directory path. File paths in tool calls are typically relative to this directory.

vcs:

Version control state at the time of the session (branch, revision, etc.), as a VCS_Context Object ().

sandboxes:

Paths to sandbox mount points. Some agents run in sandboxed environments where the working directory is a temporary mount.

Dialog Object Parameters A message of an agent session represents a conversational turn: either human input or agent response. This is the most common entry type, carrying the primary dialog content of a session. A message is represented by a "text" type Dialog Object. The parties parameter of the Dialog Object references the Party Object of the contributor of the message. Human (or upstream agent) input is contributed by the Party Object of the user, and an agent response is contributed by the Party Object of the agent. The message body is contained in the Dialog Content. For assistant messages, additional metadata may be present: the model that generated the response and token usage statistics. This extension adds the following parameters to the Dialog Object, using the dialog-ext socket:

CDDL for the ai_agent Parameters of the Dialog Object any } ]]>

Editor's Note:

An alternative placement for model_id and token_usage is the generation provenance of .

model_id The model_id parameter identifies the model that generated this response. Present on assistant messages, absent on user messages.

• model_id: "String" (optional)

token_usage The token_usage parameter captures token consumption metrics for a model response. Token usage data is essential for cost tracking, quota management, and understanding model behavior. All members are optional because different agents report different subsets of token metrics.

• token_usage: "Token_Usage" (optional)

Editor's Note: add a non-empty generic here The Token_Usage Object contains the following members:

input:

The number of input tokens consumed by this response.

output:

The number of output tokens generated.

cached:

The number of input tokens served from cache rather than reprocessed.

reasoning:

Tokens consumed by chain-of-thought or reasoning computation.

total:

The total token count.

cost:

The monetary cost in US dollars for this response.

entry_id and parent_id The entry_id parameter contains the unique identifier of this entry within the session. The parent_id parameter references the parent entry, enabling tree-structured conversations. Both are defined in .

• entry_id: "String" (optional)
• parent_id: "String" (optional)

Event Object Types and Parameters This extension defines four Event Object types representing the kinds of entries in an agent conversation that are not messages. They are added using the event-type-ext socket. Each type ends with a socket of its own, so that other extensions can add parameters to it.

CDDL for the ai_agent Event Object Types any }, agent_entry_reference_type, * $$system-event-ext ) ]]>

For all four types, the time parameter provides when the entry occurred, the session parameter references the Session Object of the agent session, and the party parameter references the Party Object of the agent. The entry_id and parent_id parameters () preserve the native entry identifiers and the tree structure of the agent trace.

Editor's Note:

An alternative placement for the agent trace is a single Analysis Object that carries the trace, as proposed in . It is also an open question whether the "tool-call" and "reasoning" Event Object types apply to human parties.

tool-call A "tool-call" type Event Object represents a tool invocation: which tool was called and with what arguments. Tool calls are central to agent conversation records because tool use is the primary mechanism by which agents interact with external environment.

tool_name:

The tool name (e.g., "Bash", "Edit", "Read", "apply_patch").

input:

The arguments passed to the tool, preserved in their native structure.

call_id:

Links this call to its corresponding result.

$$tool-call-event-ext:

A CDDL socket that can be used to extend the "tool-call" type Event Object. See .

tool-result A "tool-result" type Event Object represents the output returned by a tool after execution. It is linked to its corresponding "tool-call" type Event Object via the call_id parameter. The result carries the tool's response data and optional status metadata indicating success or failure.

output:

The tool's response, preserved in native structure.

call_id:

Links this result to its corresponding call.

status:

Outcome status of the tool execution, such as "success", "error", or "completed".

is_error:

Boolean error flag, present when the tool execution failed.

$$tool-result-event-ext:

A CDDL socket that can be used to extend the "tool-result" type Event Object. See .

reasoning A "reasoning" type Event Object captures CoT, thinking, or internal reasoning content from the agent. Not all agents expose reasoning traces. When they do, the content may be plaintext, structured blocks, or encrypted. Reasoning entries are valuable for auditing decision-making processes and understanding why an agent took particular actions.

content:

The reasoning text or structured content. May be an empty string when only encrypted content is available.

encrypted:

Encrypted reasoning content. Used where the model provider encrypts chain-of-thought output.

subject:

A topic label for the reasoning block.

$$reasoning-event-ext:

A CDDL socket that can be used to extend the "reasoning" type Event Object. See .

system-event A "system-event" type Event Object records system lifecycle events that are not part of the conversation dialog but are relevant for understanding the session context. Examples include session start and end markers, token usage summaries, permission changes, and configuration events.

event_type:

Classifies the event, such as "session-start", "session-end", "token-count", or "permission-change". The values are not enumerated in the schema to accommodate vendor-specific event types.

data:

Event-specific payload. The structure varies by event type.

$$system-event-ext:

A CDDL socket that can be used to extend the "system-event" type Event Object. See .

Event Object Parameter Applicability by Type The following table summarizes which Event Object parameters apply to each Event Object type defined in this document. The symbols used in the table are the ones used in : M the parameter MUST be present, O the parameter is optional, X the parameter MUST NOT be present. Event Object Parameter Applicability for the ai_agent Event Object Types

Parameter	tool-call	tool-result	reasoning	system-event
type	M	M	M	M
time	M	M	M	M
session	M	M	M	M
party	M	M	M	M
dialog	X	X	X	X
button, transferee, transfer_target, consultation, target_session	X	X	X	X
tool_name	M	X	X	X
input	M	X	X	X
call_id	O	O	X	X
output	X	M	X	X
status	X	O	X	X
is_error	X	O	X	X
content	X	X	M	X
encrypted	X	X	O	X
subject	X	X	O	X
event_type	X	X	X	M
data	X	X	X	O
entry_id	O	O	O	O
parent_id	O	O	O	O

Reusable Definitions The CDDL definitions in this section are used by more than one of the extension points above.

CDDL for Definitions Used by More Than One Extension Point any } ; Reference to an entry of the native agent trace agent_entry_reference_type = ( ? entry_id: agent_entry_id_type, ? parent_id: agent_entry_id_type ) ; Per-entry unique reference within a session agent_entry_id_type = tstr ]]>

VCS_Context Object The VCS_Context Object captures version control metadata for reproducibility. Knowing the exact repository, branch, and commit at the time of a conversation enables consumers to reconstruct the codebase state and verify file attributions. It is used by the vcs parameter of the vCon Object () and by the Environment Object of the Session Object ().

type:

The version control system type (e.g., "git", "jj", "hg", "svn").

revision:

The commit SHA or change identifier at session time.

branch:

The active branch name.

repository:

The repository URL.

Agent Entry Reference Agent implementations identify each entry of their native trace and arrange entries in a tree. The entry_id and parent_id parameters preserve this structure in the Dialog Objects () and the Event Objects () of an agent session.

entry_id:

A per-entry unique reference within a session, enabling parent-child linking.

parent_id:

References the parent entry, enabling tree-structured conversations. Entries that the native format nests inside another entry reference that entry in parent_id.

Compatibility Considerations This extension is Compatible as defined in . The parameters added by this extension to the vCon Object (recording_agent, vcs, file_attribution), to the Party Object (agent_meta), to the Session Object (agent_session_id, format, environment), and to the Dialog Object (model_id, token_usage, entry_id, parent_id) are new and optional. None of them changes the meaning, structure, or permitted values of any parameter defined in . An implementation that does not recognize these parameters can therefore continue to process the vCon correctly by ignoring them. The Event Object types added by this extension ("tool-call", "tool-result", "reasoning", "system-event") are values that an implementation that does not support this extension does not recognize. As defined in , such an implementation ignores these Event Objects, and they remain in the events array so that indexes are not changed. The effect is that the agent trace is not processed, while the messages of the agent session, which are Dialog Objects, are processed as usual. This does not make the extension Incompatible.

Incompatibility Considerations This extension introduces no incompatibilities. All parameters and Event Object types defined in this document are new and additive. None of them changes the semantics, structure, or permitted values of any parameter defined in . Because no incompatibility is introduced, the "ai_agent" extension name is not required to appear in the critical parameter. A redactor that does not support this extension cannot assess the content of the parameters and Event Object types defined in this document, which can carry PII (see ). As described in , such a redactor may reject a vCon that lists "ai_agent" in the extensions parameter.

Privacy and Integrity Considerations Verifiable agent conversation records reveal substantial information about agent behavior, system state, and user interactions. The privacy considerations of apply.

Information Disclosure User prompts captured in Dialog Objects may contain personal identifiers, business confidential information, credentials inadvertently included in prompts, or behavioral patterns. Agent responses and reasoning traces may reveal inference results that expose information about users not explicitly provided, confidential information retrieved by tools, or system architecture details through tool names and parameters. Implementations MUST treat user-provided content as potentially containing personally identifiable information. Record metadata exposes operational details that may have privacy implications. Model identifiers reveal AI capabilities, CLI versions enable targeted attacks against known vulnerabilities, working directories expose file system structure, and VCS context discloses repository names and commit timing. Token usage patterns may enable inference about conversation content even when the content itself is protected.

Sensitive Content in Records Reasoning entries may contain inferences that constitute special category data, including health-related inferences from user queries, political opinions derived from conversation context, or biometric data processed by AI systems. The encrypted parameter of the "reasoning" Event Object type reflects that some model providers encrypt chain-of-thought content; when reasoning is encrypted, audit capabilities depend on the provider's cooperation. Tool inputs and outputs warrant particular attention. Tool call inputs may contain credentials, API keys, or file contents. Tool results may contain query results with personal data from databases or external services. Implementations SHOULD provide configurable redaction rules for common patterns and support selective entry type recording based on deployment requirements.

Redaction and De-identification The input parameter of "tool-call" type Event Objects, the output parameter of "tool-result" type Event Objects, the content and encrypted parameters of "reasoning" type Event Objects, and the data parameter of "system-event" type Event Objects can carry party-identifying data or PII. The same applies to the Dialog Content of the Dialog Objects that represent messages, to the working_dir and sandboxes members of the Environment Object, and to the path and url members of the File_Attribution Object. A redactor is expected to handle these parameters like Dialog Content, using the redacted parameter of . A redactor that removes an Event Object entirely leaves a placeholder in the events array, so that indexes in other Objects do not change.

External References This extension does not add url and content_hash parameters for externally referenced files as defined in , and therefore introduces no new externally referenced content. The url members of the File_Conversation Object and of the Resource Object are references to related resources and not content of the vCon. They are not protected by a content_hash.

Retention Considerations Multiple frameworks impose retention requirements that may conflict with data minimization principles. Organizations must balance compliance obligations requiring extended retention against privacy principles requiring timely deletion. Compliant data management may require separating raw personal data from audit trail metadata, implementing automated deletion for personal data after compliance-minimum periods, and maintaining cryptographic commitments enabling verification without retaining content.

Correlation and Inference Presentations of the same record to multiple parties can be correlated by matching on the signature component. Session identifiers enable linking of records across time, potentially revealing long-term behavioral patterns or organizational structure. Implementations SHOULD use unlinkable session identifiers where correlation is not required. Without accessing record content, observers may infer conversation frequency and duration patterns, types of tools used, error rates, or timing correlations with external events. Metadata exposure in unprotected headers warrants careful consideration; the trace-metadata in the COSE unprotected header () reveals session identifiers, agent vendor, and timestamps even when the payload is encrypted.

Authority Access Regulatory frameworks may require provision of records to authorities upon request. Access to records has to be logged, capturing who accessed which records, when access occurred, what legal basis justified access, and what data was disclosed. This creates a recursive consideration: access logs may themselves contain personal data requiring protection.

Security Considerations The security considerations of apply.

Record Integrity The signed form of a vCon and the signed-agent-record envelope () provide cryptographic integrity protection for the serialized record payload. A valid signature establishes that the claimed signer produced the record but does not guarantee the truthfulness of its contents. Modifications to the record structure after signing invalidate the signature, but modifications before signing cannot be detected. Implementations generating records incrementally during a conversation MUST sign only after the conversation concludes or at defined checkpoints.

Signing Key Protection The security of signed records depends critically on the protection of private signing keys. If an attacker obtains a signing key, they can forge records indistinguishable from genuine ones. Protection mechanisms range from operating system process isolation in development environments to hardware security modules with physical tampering resistance in high-assurance deployments. Compromised signing keys require rejection of records signed after the compromise date and notification to Relying Parties. Key provisioning processes must guarantee that exclusively valid attestation key material is established. Off-device key generation requires confidentiality protection during transmission, creating recursive security dependencies. On-device key generation eliminates transmission risks but requires chain-of-custody integrity to prevent attackers from obtaining endorsement for keys they control.

Timestamp Integrity Timestamps establish temporal ordering of events within records. Attackers who can manipulate timestamps can backdate records, freeze participants in chosen time periods to evade freshness checks, or manipulate perceived temporal relationships between entries. Timestamps within records are attested by the signer, not independently verified. Implementations requiring independent timestamp verification SHOULD use external timestamping services or transparency logs such as those defined in .

Adversarial Content Processing verifiable agent conversation records involves parsing content that may be produced by adversaries. This applies both to user-supplied prompts and to model outputs that may have been influenced by adversarial inputs. The open extensibility (* tstr => any) in the Objects defined in this document allows arbitrary additional fields; implementations MUST NOT assume that unrecognized fields are safe to process or display. Records may contain content designed to exploit downstream systems. Malicious prompts preserved in records may execute if records are subsequently processed by AI systems. Tool results may contain executable content that executes if rendered unsafely in web interfaces. File paths in tool calls or file attribution entries may attempt directory traversal. Implementations MUST apply appropriate sanitization before rendering content, executing it in agent contexts, or using paths for file system operations.

Non-Repudiation The signed form of a vCon and the signed-agent-record envelope alone provide authenticity and integrity, not non-repudiation. A signer can claim key compromise or dispute the signing time without independent evidence. Non-repudiation requires additional infrastructure such as transparency services that provide independent timestamp proof via registration receipts, append-only logs preventing retroactive denial, and third-party witnesses to the signing event.

Detection and Trust Boundaries Verifiable agent conversation records primarily enable detection of anomalous behavior rather than prevention. Detection requires that records accurately reflect actual agent behavior; an agent that controls its own recording can omit or falsify entries. The recording_agent parameter distinguishes the recording tool from the conversing agent, enabling Relying Parties to assess trust in the recording process. Trust boundaries exist between the agent runtime and recording system, between the recording system and storage, between storage and verification, and between verification and decision-making. Attacks at any boundary may compromise record integrity or confidentiality.

IANA Considerations

vCon JSON Registry Additions

vCon Extensions Names Registry The following extension name is added to the vCon Extensions Names Registry.

Extension Name	Extension Description	Change Controller	Specification Document(s)
ai_agent	AI Agent conversation records	IESG	RFC XXXX

vCon Object Parameter Names Registry The following defines additional values for the vCon Object Parameter Names Registry.

Parameter Name	Parameter Description	Change Controller	Specification Document(s)
recording_agent	tool that generated the record	IESG	RFC XXXX
vcs	record-level version control context	IESG	RFC XXXX
file_attribution	attribution of modified files	IESG	RFC XXXX

Party Object Parameter Names Registry The following defines additional values for the Party Object Parameter Names Registry.

Parameter Name	Parameter Description	Change Controller	Specification Document(s)
agent_meta	agent and model metadata	IESG	RFC XXXX

Session Object Parameter Names Registry The following defines additional values for the Session Object Parameter Names Registry.

Parameter Name	Parameter Description	Change Controller	Specification Document(s)
agent_session_id	native agent session identifier	IESG	RFC XXXX
format	agent session style	IESG	RFC XXXX
environment	agent execution environment	IESG	RFC XXXX

Dialog Object Parameter Names Registry The following defines additional values for the Dialog Object Parameter Names Registry.

Parameter Name	Parameter Description	Change Controller	Specification Document(s)
model_id	model that generated the response	IESG	RFC XXXX
token_usage	token consumption metrics	IESG	RFC XXXX
entry_id	native agent entry identifier	IESG	RFC XXXX
parent_id	native agent parent entry identifier	IESG	RFC XXXX

Event Object Parameter Names Registry The following defines additional values for the Event Object Parameter Names Registry.

Parameter Name	Parameter Description	Change Controller	Specification Document(s)
tool_name	name of the invoked tool	IESG	RFC XXXX
input	tool arguments	IESG	RFC XXXX
call_id	tool call and result correlation	IESG	RFC XXXX
output	tool output	IESG	RFC XXXX
status	tool execution status	IESG	RFC XXXX
is_error	tool execution error flag	IESG	RFC XXXX
content	reasoning content	IESG	RFC XXXX
encrypted	encrypted reasoning content	IESG	RFC XXXX
subject	reasoning topic label	IESG	RFC XXXX
event_type	system event classifier	IESG	RFC XXXX
data	system event payload	IESG	RFC XXXX
entry_id	native agent entry identifier	IESG	RFC XXXX
parent_id	native agent parent entry identifier	IESG	RFC XXXX

Event Type Name Registry The following defines additional values for the Event Type Name Registry.

Event Type Name	Event Type Description	Change Controller	Specification Document(s)
tool-call	agent tool invocation	IESG	RFC XXXX
tool-result	agent tool result	IESG	RFC XXXX
reasoning	agent reasoning	IESG	RFC XXXX
system-event	agent system lifecycle event	IESG	RFC XXXX

New Object Parameter Names Registries

Editor's Note:

recommends requesting a parameter names registry for each new Object. This extension defines the Recording_Agent, File_Attribution, File, File_Conversation, Range, Contributor, Resource, Agent_Meta, Environment, Token_Usage, and VCS_Context Objects. The registries will be requested once the assignment of these Objects to extension points is settled.

References Normative References JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. SIPez LLC vCon is a standardized framework for the exchange of conversational data. Conversations, which may involve one or more participants, occur across a wide variety of modes and application platforms. This document defines a JSON format for representing conversational data, encompassing metadata, conversation media, related documents, and analysis. The goal of this standard is to provide an abstracted, platform-independent data format for conversations, regardless of the mode or application platform. By doing so, it facilitates the integration and seamless exchange of conversational data across application platforms, enterprises, and trust boundaries. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Data Definition Language (CDDL), as defined in RFCs 8610 and 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in Concise Binary Object Representation (CBOR) or JSON. This document updates RFC 8610 by addressing related errata reports and making other small fixes for the ABNF grammar defined for CDDL. ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Autonomous agents based on large language models increasingly perform consequential tasks on behalf of humans and other agents. Demonstrating that recorded agent behavior truthfully represents actual behavior is essential for accountability, compliance, and human oversight. This document defines a data format for verifiable agent conversation records using CDDL, with representations in both JSON and CBOR. The format captures session metadata, message exchanges, tool invocations, reasoning traces, and system events in a structured, extensible CDDL definition for verifiable agent conversation records. COSE is used as the signing method to allow for native interoperability in SCITT Transparency Services and the CDDL definition allows for seemless integration in Evidence as specified in RFC 9334. The specification supports cross-vendor interoperability by defining a common representation that accommodates translation from multiple existing agent implementations with distinct data structure layouts that are typically represented in JSON. VCONIC This document defines an "agent_session" extension for Virtualized Conversations (vCon) that profiles the use of vCon parties, dialog, analysis, and attachments to carry the record of an autonomous AI agent's internal session - its prompts, tool invocations, tool results, reasoning, and file or artifact provenance - alongside the human-facing conversation that the agent participated in or acted upon. The extension is a Compatible vCon extension. It introduces no new top-level fields and does not alter the semantics of existing ones. Instead, it specifies (a) how an autonomous agent is represented as a vCon party, (b) how agent message turns are placed in the dialog array, (c) how the internal agent trace (tool calls, results, reasoning, system events) is carried as a structured analysis entry whose body conforms to the Verifiable Agent Conversations (VAC) CDDL schema [I-D.draft-birkholz-verifiable-agent-conversations], and (d) how files and artifacts modified by the agent are carried as attachments. By projecting agent-session data into the vCon model, implementations inherit vCon's party/identity model, the lawful basis framework [I-D.draft-howe-vcon-lawful-basis], the lifecycle and redaction machinery [I-D.draft-howe-vcon-lifecycle], and JWS-based signing, without re-specifying any of those concerns. VCONIC This document defines a "provenance" extension for Virtualized Conversations (vCon) that records how a piece of generated content was produced by a generative model: the model and provider, the decoding parameters (for example temperature and top_p), the prompt or a hash of it, the vCon elements that were given to the model as input, and a hash of the output. The record is carried as a named provenance member on the analysis object it describes (and, for machine-generated dialog, on the dialog object), so that an analysis has a real, named home for "how this was generated" rather than overloading the analysis body or schema. The extension is a Compatible vCon extension. It introduces no new top-level fields and does not alter the semantics of existing ones. Because the provenance record binds an output to its model, prompt, and inputs by hash, a signed vCon, or a SCITT transparency receipt over it, can attest to a verifiable derivation: not only that the analysis exists, but how it came to be. jdrosen.net The Virtualized Conversations (VCON) specification provides a structured format for storing recordings of conversations, including phone calls, email threads and multi-party chats. VCONs also store metadata like call transcripts and mid-call events, like a call hold or addition of a party. Its structure is well suited for 2-party and basic multiparty phone calls. However, there is a need for the VCON format to also act as a record of AI Agent conversations, which are just another type of conversation. This document proposes changes to the object model in VCON to make it a more suitable format for handling AI Agent conversations, as well as more complex conferencing use cases. European Parliament Council of the European Union European Parliament Council of the European Union European Parliament Council of the European Union European Telecommunications Standards Institute American Institute of Certified Public Accountants Chartered Institute of Management Accountants National Institute of Standards and Technology Office of Management and Budget PCI Security Standards Council International Organization for Standardization International Electrotechnical Commission Federal Financial Institutions Examination Council Bundesamt fuer Sicherheit in der Informationstechnik National Institute of Standards and Technology International Organization for Standardization International Electrotechnical Commission

Compliance Requirements for AI Agent Conversation Records This section identifies the intersection of logging, traceability, and record-keeping requirements across major compliance frameworks applicable to AI systems. The verifiable agent conversation format defined in this document addresses these requirements by providing a standardized, cryptographically verifiable record of AI agent interactions.

Applicable Requirement Frameworks The following frameworks were analyzed for their requirements on AI agent traceability and session logging:

Framework	Jurisdiction	Sector	Status
EU AI Act	EU	Cross-sector	In force Aug 2024
Cyber Resilience Act	EU	Products with digital elements	In force Dec 2024
NIS2 Directive	EU	Essential/important entities	Transposed Oct 2024
ETSI TS 104 223	EU/International	AI systems	Published Apr 2025
SOC 2 Trust Services Criteria	US/International	Service organizations	Active
FedRAMP	US	Federal cloud services	Active
PCI DSS	International	Payment card industry	Mandatory Mar 2025
ISO/IEC 42001	International	AI management systems	Published 2023
FFIEC IT Handbook	US	Financial institutions	Updated 2024
BSI AI Finance Test Criteria	Germany	Financial sector AI	Published 2024
NIST AI 100-2	US	Cross-sector	Published 2025

Common Requirements Intersection The analysis of the frameworks listed above results in eleven categories of requirements that appear across ALL or MOST frameworks. These categories frame and represent a minimum baseline that verifiable agent conversation records MUST support.

REQ-1: Automatic Event Logging All frameworks require automatic, system-generated logging of events without reliance on manual recording. Explicit requirements are listed as follows:

Framework	Requirement
EU AI Act Art. 12	"High-risk AI systems shall technically allow for the automatic recording of events (logs)"
ETSI TS 104223 5.4.2-1	"System Operators shall log system and user actions"
SOC 2 CC7.2	"Complete and chronological record of all user actions and system responses"
FedRAMP AU-12	"Audit Record Generation" control requirement
PCI DSS 4.0 Req 10	"Audit logs implemented to support detection of anomalies"
ISO 42001 A.6.2.8	"AI system recording of event logs"

Mapping to this specification: The Dialog Objects and Event Objects of a Session Object capture all events automatically. Each of them represents a discrete, system-recorded event with structured metadata.

REQ-2: Timestamp Requirements Most frameworks require precise temporal information for each logged event. Explicit requirements are listed as follows:

Framework	Requirement
EU AI Act Art. 12(2)	"Precise timestamps for each usage session" (biometric systems)
PCI DSS 4.0 Req 10.6	"Time-synchronization mechanisms support consistent time settings"
SOC 2	"When the activity was performed via timestamp"
NIS2	"Precise logging of when an incident was first detected"

Mapping to this specification: The start parameter of each Dialog Object and the time parameter of each Event Object use the Date type of , which is an RFC 3339 string, ensuring interoperability across implementations.

REQ-3: Actor Identification Most frameworks require some attribution of actions to identifiable actors (human or system). Explicit requirements are listed as follows:

Framework	Requirement
EU AI Act Art. 12(3)(d)	"Identification of the natural persons involved in the verification of results"
SOC 2	"The process or user who initiated the activity (Who)"
PCI DSS 4.0	Attribution to "Who" performed each action
FedRAMP AC-2	Account management and identification

Mapping to this specification: The contributor type captures actor attribution with type (human/ai/mixed/unknown) and optional model_id. The agent_meta parameter of the Party Object identifies the AI system.

REQ-4: Action/Event Type Recording All frameworks require recording of what action or event occurred. Explicit requirements are listed as follows:

Framework	Requirement
EU AI Act Art. 12	"Events relevant for identifying situations that may result in...risk"
ETSI TS 104223 5.2.4-3	"Audit log of changes to system prompts or other model configuration"
SOC 2	"The action they performed such as file transferred, created, or deleted (What)"
PCI DSS 4.0	"What" component of audit trail

Mapping to this specification: The type parameter of Dialog Objects and Event Objects discriminates event types: text (messages), tool-call, tool-result, reasoning, system-event.

REQ-5: Input/Output Recording (AI-Specific) All AI-specific frameworks require recording of inputs (prompts) and outputs (responses). Explicit requirements are listed as follows:

Framework	Requirement
EU AI Act Art. 12(3)(c)	"The input data for which the search has led to a match"
PCI DSS AI Guidance	"Logging should be sufficient to audit the prompt inputs and reasoning process"
ETSI TS 104223 5.1.2-3	"Operation, and lifecycle management of models, datasets and prompts"
FFIEC VII.D	"Lack of explainability...unclear how inputs are translated into outputs"

Mapping to this specification:

• text Dialog Object contributed by the user: User/system input (prompt)
• text Dialog Object contributed by the agent: Model response
• tool-call Event Object input: Tool invocation parameters
• tool-result Event Object output: Tool execution results
• reasoning Event Object content: Chain-of-thought (where available)

REQ-6: Retention Period Requirements Most frameworks specify minimum retention periods for audit logs. Explicit requirements are listed as follows:

Framework	Minimum Retention
EU AI Act Art. 19	6 months (longer for financial services)
FedRAMP (M-21-31)	12 months active + 18 months cold storage
PCI DSS 4.0	12 months total, 3 months immediate access
NIS2	Per member state law

Recommendation: Implementations SHOULD retain verifiable agent conversation records for at least 12 months to satisfy the most common requirement threshold.

REQ-7: Tamper-Evidence and Integrity Protection All frameworks require some protection against unauthorized modification of logs. Explicit requirements are listed as follows:

Framework	Requirement
PCI DSS 4.0 Req 10.5	"Tamper-proof audit trails...logs cannot be altered retroactively"
FedRAMP	"Effective chain of evidence to ensure integrity"
SOC 2	Log integrity as security control
CRA	"Tamper-proof SBOMs and vulnerability disclosures"

Mapping to this specification: The signed form of a vCon and the signed-agent-record type (COSE_Sign1 envelope, ) provide cryptographic integrity protection. The content-hash field in trace-metadata enables verification of payload integrity.

REQ-8: Incident Response Support All frameworks require some logs to support incident investigation and response. Explicit requirements are listed as follows:

Framework	Requirement
NIS2 Art. 23	24-hour initial notification, 72-hour assessment
CRA	24-hour vulnerability notification to ENISA
ETSI TS 104223 5.4.2-1	Logs for "incident investigations, and vulnerability remediation"
FedRAMP	Incident reporting and continuous monitoring

Mapping to this specification: The structured format enables rapid extraction of relevant entries by timestamp range, event type, or tool invocation for incident reconstruction.

REQ-9: Anomaly and Risk Detection Support All frameworks require some logs to enable detection of anomalous or risky behavior. Explicit requirements are listed as follows:

Framework	Requirement
EU AI Act Art. 12(2)(a)	"Identifying situations that may result in...risk"
ETSI TS 104223 5.4.2-2	"Detect anomalies, security breaches, or unexpected behaviour"
FedRAMP SI-4	"Anomaly detection"
SOC 2	"Anomaly detection" for security monitoring

Mapping to this specification: The standardized entry types and structured tool-call/tool-result pairs enable automated analysis for detecting:

• Unusual tool invocation patterns
• Failed operations (via status and is_error fields)
• Unexpected reasoning patterns
• Token usage anomalies

REQ-10: Human Oversight Enablement All AI-specific frameworks require logs to support human review and oversight. Explicit requirements are listed as follows:

Framework	Requirement
EU AI Act Art. 26(5)	"Monitoring the operation of high-risk AI systems"
ETSI TS 104223 5.1.4-1	"Capabilities to enable human oversight"
ISO 42001	Human responsibility and accountability
FFIEC VII.D	"Dynamic updating...challenges to monitoring and independently reviewing AI"

Mapping to this specification: The reasoning Event Object type captures chain-of-thought content (where available), enabling human reviewers to understand AI decision-making processes. The entry_id and parent_id fields and the hierarchy of Session Objects preserve conversation structure.

REQ-11: Traceability and Reproducibility All frameworks require some ability to trace system behavior and reconstruct events. Explicit requirements are listed as follows:

Framework	Requirement
EU AI Act Art. 12	"Level of traceability of the functioning...appropriate to the intended purpose"
ISO 42001	"Traceability" as key factor including "data provenance, model traceability"
CRA	"Traceability in the software supply chain"
ETSI TS 104223 5.2.1-2	"Track, authenticate, manage version control"

Mapping to this specification:

• Session Object and agent_session_id: Links entries to sessions
• entry_id and parent_id: Enables conversation tree reconstruction
• vcs_context: Git commit/branch for code state
• agent_meta: Model version and CLI version
• file_attribution: Code provenance tracking

Framework-Specific Requirements

EU AI Act (High-Risk Systems) For AI systems classified as high-risk under Annex III of the EU AI Act , additional requirements apply:

1. Biometric identification systems (Annex III, 1(a)) require logging of:
   • Precise timestamps for start/end of each usage session
   • Reference database used during input data validation
   • Input data leading to matches
   • Natural persons involved in result verification
2. Log retention: Minimum 6 months; financial services may require longer per sector-specific regulation.
3. Authority Access: Art. 19 of requires provision of logs to competent authorities upon reasoned request.

ETSI TS 104 223 Session Logging Requirements ETSI TS 104 223 provides the most detailed AI-specific logging requirements:

Provision	Requirement	This Spec Mapping
5.1.2-3	Audit trail for "operation, and lifecycle management of models, datasets and prompts"	Session Object, agent_meta
5.2.4-1	"Document and maintain a clear audit trail of their system design"	recording_agent, open maps
5.2.4-3	"Audit log of changes to system prompts or other model configuration"	system-event Event Object with prompt changes
5.4.2-1	"Log system and user actions to support security compliance, incident investigations"	Dialog Objects and Event Objects
5.4.2-2	"Analyse their logs to ensure...desired outputs and to detect anomalies"	Structured format enables analysis
5.4.2-3	"Monitor internal states of their AI systems"	reasoning Event Object, token_usage

PCI DSS AI-Specific Guidance The PCI Security Standards Council has published guidance on AI in payment environments : "Where possible, logging should be sufficient to audit the prompt inputs and reasoning process used by the AI system that led to the output provided." This specification directly addresses this requirement through:

• text Dialog Object contributed by the user: Captures prompt inputs
• reasoning Event Object: Captures chain-of-thought (where available)
• text Dialog Object contributed by the agent: Captures model outputs
• tool-call / tool-result Event Objects: Captures agentic actions

Financial Sector Requirements (FFIEC, BSI) Financial institutions face additional scrutiny for AI systems per and :

Requirement Area	FFIEC	BSI AI Finance
Explainability	"Lack of transparency or explainability" risk	Test criteria for explainability
Dynamic updating	"Challenges to monitoring and independently reviewing AI"	Continuous validation
Audit trail	Log management (VI.B.7)	Complete audit trail

Compliance Mapping Table The following table maps this specification's data elements to compliance requirements:

Data Element	EU AI Act	ETSI 104223	SOC 2	FedRAMP	PCI DSS	ISO 42001	NIS2
start / time	Art. 12(2)	5.4.2-1	CC7.2	AU-8	10.6	A.6.2.8	Art. 23
agent_session_id	Art. 12	5.2.4-1	CC7.2	AU-3	10.2	A.6.2.8	-
type	Art. 12(2)	5.4.2-1	CC7.2	AU-3	10.2	A.6.2.8	-
contributor	Art. 12(3)(d)	5.1.4	CC6.1	AC-2	10.2	A.6.2.8	-
Dialog Content	Art. 12(3)(c)	5.1.2-3	-	-	AI Guide	-	-
reasoning	Art. 12	5.4.2-3	-	-	AI Guide	A.7.1	-
tool-call / tool-result	Art. 12	5.4.2-1	CC7.2	AU-12	10.2	A.6.2.8	-
signed-agent-record	Art. 19	5.2.4-1.2	CC6.1	AU-9	10.5	-	-
vcs_context	-	5.2.1-2	-	CM-3	-	A.6.2.8	-
token_usage	-	5.4.2-4	-	-	-	-	-

Security Requirements addressing Regulatory Compliance

Log Integrity Per PCI DSS Req 10.5 and FedRAMP AU-9, logs MUST be protected against modification. Implementations SHOULD:

1. Use the signed form of the vCon or the signed-agent-record envelope () for cryptographic integrity
2. Store the content-hash for offline verification
3. Implement write-once storage for log archives

Access Control Per FedRAMP AC-3 and ETSI 5.2.2-1, access to logs MUST be controlled:

1. Logs containing sensitive prompts or outputs require access control
2. Reasoning content may contain confidential information
3. Authority access (EU AI Act Art. 19) requires audit of log access itself

Data Protection Logs may contain personal data subject to GDPR/privacy regulations:

1. Dialog Content of text Dialog Objects may contain PII
2. output of tool-result Event Objects may contain query results with PII
3. Retention periods must balance compliance requirements with data minimization

Related Standards and Emerging Work The ISO/IEC JTC 1/SC 42 committee is developing , a draft international standard specifically addressing AI system logging requirements. This work aligns with and complements the verifiable agent conversation format defined in this document. Research on emergent misalignment demonstrates that narrow fine-tuning can produce broadly misaligned LLMs, underscoring the importance of comprehensive conversation logging for detecting behavioral anomalies that may not be apparent from individual interactions.

Application of SCITT and COSE for Transparency and Authenticity The signed form of a vCon uses JWS. This appendix describes a signing envelope that provides cryptographic integrity protection for vCons that carry agent conversation records using COSE_Sign1 (), which is encoded in CBOR . The vCon is the payload of the envelope, and the content type header parameter carries the media type "application/vcon" defined in . This makes a signed agent record a Signed Statement that can be registered with a SCITT Transparency Service . No extension point of the vCon schema is used by the envelope. The reader is assumed to be familiar with the vocabulary and concepts defined in and .

Editor's Note:

The use of COSE and SCITT for vCons is expected to progress together with the SCITT related vCon work.

The collated CDDL definition for the envelope is specified as follows:

CDDL for the Signed Agent Record Envelope CWT_Claims ? &(alg: 1) => int ? &(content_type: 3) => tstr / uint ? &(kid: 4) => bstr ? &(x5t: 34) => COSE_CertHash ? &(x5chain: 33) => COSE_X509 * label => any } CWT_Claims = { &(iss: 1) => tstr &(sub: 2) => tstr * label => any } unprotected-header = { ? &(trace-metadata-key: 100) => trace-metadata ; 100 is placeholder ? &(x5chain: 33) => COSE_X509 ? &(receipts: 394) => [ + Receipt ] * label => any } trace-metadata = { session-id: session-id agent-vendor: tstr trace-format: trace-format-id timestamp-start: abstract-timestamp ? timestamp-end: abstract-timestamp ? content-hash: tstr ; SHA-256 hex digest of \ payload ? content-hash-alg: tstr } ; Known values: "ietf-vac-v3.0" (canonical), "claude-jsonl", "gemini\ -json", ; "codex-jsonl", "opencode-json", "cursor-jsonl". Extensible via \ tstr. trace-format-id = tstr COSE_X509 = bstr / [ 2*certs: bstr ] COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ] label = int / tstr ; COSE Receipt CDDL for use in SCITT compliant COSE Envelope Receipt = #6.18(COSE_Sign1) cose-label = int / tstr cose-value = any Protected_Header = { * cose-label => cose-value } Unprotected_Header = { &(receipts: 394) => [+ bstr .cbor Receipt] * cose-label => cose-value } COSE_Sign1 = [ protected : bstr .cbor Protected_Header, unprotected : Unprotected_Header, payload : bstr / null, signature : bstr ] ; SCITT-interoperable COSE Envelope ; including from draft-ietf-cose-merkle-tree-proofs and ; draft-ietf-scitt-architecture for validation ; RFC 3339 string OR epoch milliseconds (for interop). abstract-timestamp = tstr .regexp date-time-regexp / uint ; Opaque string: UUID, SHA-256 hash in base64url, etc. session-id = tstr / bstr ; RFC 3339 date-time pattern date-time-regexp = "([0-9]{4})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[\ 01])T([01][0-9]|2[0-3]):([0-5][0-9]):(60|[0-5][0-9])([.][0-9]+)?(Z|[\ +-]([01][0-9]|2[0-3]):[0-5][0-9])" ]]>

The signed-agent-record Structure A signed-agent-record is a COSE_Sign1 envelope (CBOR Tag 18) that wraps a vCon with a cryptographic signature. Signing provides data provenance and tamper evidence, satisfying some requirements of RATS Evidence generation () and SCITT auditability () requirements. The payload may be included or detached (null); in detached mode, the vCon is supplied separately during verification. The following describes each element of this structure.

protected:

The serialized protected header containing the algorithm identifier, content type, and CWT claims .

unprotected:

The unprotected header carrying trace metadata at label 100 and, after registration, the receipts of a SCITT Transparency Service.

payload:

The serialized vCon bytes, or null for detached payloads.

signature:

The cryptographic signature over the protected header and payload.

The x5chain and x5t header parameters are defined in .

The trace-metadata Map The trace-metadata type carries summary information about the signed record in the COSE_Sign1 unprotected header. This enables consumers to inspect key properties of a signed record without deserializing the full payload. The following describes each member of this map.

session-id:

The session identifier from the signed record.

agent-vendor:

The agent provider name (e.g., "anthropic", "google").

trace-format:

Identifies the format of the signed payload (e.g., "ietf-vac-v3.0" for canonical records).

timestamp-start:

When the session began.

timestamp-end:

When the session ended.

content-hash:

SHA-256 hex digest of the payload bytes, enabling integrity checking independent of the COSE signature.

content-hash-alg:

The hash algorithm used (default: "sha-256").

Editor's Note:

The label 100 for trace-metadata is a placeholder. A COSE Header Parameter registration is for further discussion.

Mapping of Verifiable Agent Conversation Record Data Items The following table maps the data items of to their representation in this document. Mapping of VACR Data Items

VACR data item	vCon representation	Extension point
verifiable-agent-record	vCon Object	(core)
version	extensions parameter, "ai_agent"	(core)
id	uuid parameter	(core)
created	created_at parameter	(core)
recording-agent	recording_agent parameter	vcon-ext
vcs	vcs parameter	vcon-ext
file-attribution	file_attribution parameter	vcon-ext
session-trace	Session Object	(core)
session-id	agent_session_id parameter	session-ext
format	format parameter	session-ext
session-start	start parameter	(core)
session-end	duration parameter	(core)
environment	environment parameter	session-ext
agent-meta	agent_meta parameter of the agent Party Object	party-ext
entries	Dialog Objects and Event Objects of the Session Object	(core)
message-entry	"text" type Dialog Object	(core)
message-entry model-id	model_id parameter	dialog-ext
token-usage	token_usage parameter	dialog-ext
tool-call-entry	"tool-call" type Event Object	event-type-ext
tool-call-entry name	tool_name parameter	event-type-ext
tool-result-entry	"tool-result" type Event Object	event-type-ext
reasoning-entry	"reasoning" type Event Object	event-type-ext
event-entry	"system-event" type Event Object	event-type-ext
timestamp	start (Dialog Object) or time (Event Object) parameter	(core)
id, parent-id	entry_id, parent_id parameters	dialog-ext, event-type-ext
children	parent_id parameter of the nested entries	dialog-ext, event-type-ext
abstract-timestamp	Date ()	(core)
signed-agent-record		(none)
trace-metadata		(none)

All other member names of are converted from kebab-case to snake_case, as required by . The CDDL in is not part of the vCon schema and is used as in . The media type "application/agent-conversation", the CoAP Content-Format, and the CBOR Tag requested by are not needed, as a vCon uses the media type "application/vcon".

Editor's Note:

The Event Object of requires the time parameter, while the timestamp of an entry in is optional. The epoch milliseconds form of abstract-timestamp is not supported by the Date type of .

Example vCons The following (artificailly created) example is an unsigned vCon of a short coding agent session. A user asks a question, the agent reasons, reads a file using a tool, and answers.

Example vCon with an Agent Session

CDDL for the ai_agent Extension This appendix provides a definition for the parameters defined by the ai_agent extension. The text in the preceding sections of this document defines the normative definition of these parameters. If the CDDL provided below differs from that in the text of the preceding sections, the text is the definitive definition and the CDDL below is to be considered incorrect. This CDDL extends the vcon-ext, party-ext, session-ext, dialog-ext, and event-type-ext sockets of the vCon CDDL of . It is to be used together with the vCon CDDL, which comes first so that its first rule is the root of the combined definition. The fragments below are the same ones that are included in the preceding sections, in the order in which they are included by the main CDDL file of this extension, which starts with the root rule "vcon-with-ai-agent = vcon" and includes the vCon CDDL first.

Collated CDDL for the ai_agent Extension any } ; File_Attribution Object file_attribution_type = { files: [* file_type], * $$file-attribution-ext } ; File Object file_type = { ; relative path from the repository root path: tstr, conversations: [* file_conversation_type], * $$file-ext } ; File_Conversation Object file_conversation_type = { ? url: uri_type, ; default contributor for all ranges ? contributor: contributor_type, ranges: [* range_type], ? related: [* resource_type], * $$file-conversation-ext } ; Range Object range_type = { ; 1-indexed start_line: uint, ; 1-indexed, inclusive end_line: uint, ? content_hash: tstr, ; default: "sha-256" ? content_hash_alg: tstr, ; overrides the conversation level contributor ? contributor: contributor_type, * $$range-ext } ; Contributor Object contributor_type = { type: "human" / "ai" / "mixed" / "unknown", ? model_id: tstr, * $$contributor-ext } ; Resource Object resource_type = { type: tstr, url: uri_type, * $$resource-ext } ; URI (RFC 3986) uri_type = tstr .regexp "(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?" $$party-ext //= ( agent_meta: agent_meta_type ) ; Agent_Meta Object agent_meta_type = { ; e.g., "claude-opus-4-5-20251101" model_id: tstr, ; e.g., "anthropic", "google" model_provider: tstr, ; all models (multi-model sessions) ? models: [* tstr], ; e.g., "claude-code", "gemini-cli" ? cli_name: tstr, ? cli_version: tstr, * tstr => any } $$session-ext //= ( agent_session_id: tstr ) ; "interactive" / "autonomous" / vendor specific $$session-ext //= ( format: tstr ) $$session-ext //= ( environment: environment_type ) ; Environment Object environment_type = { working_dir: tstr, ? vcs: vcs_context_type, ; sandbox mount paths ? sandboxes: [* tstr], * tstr => any } $$dialog-ext //= ( model_id: tstr ) $$dialog-ext //= ( token_usage: token_usage_type ) $$dialog-ext //= ( entry_id: agent_entry_id_type ) $$dialog-ext //= ( parent_id: agent_entry_id_type ) ; Token_Usage Object token_usage_type = { ; input tokens ? input: uint, ; output tokens ? output: uint, ; cached input tokens ? cached: uint, ; reasoning or thinking tokens ? reasoning: uint, ; total tokens ? total: uint, ; monetary cost in US dollars ? cost: number, * tstr => any } $$event-type-ext //= (event_tool_call_type,) $$event-type-ext //= (event_tool_result_type,) $$event-type-ext //= (event_reasoning_type,) $$event-type-ext //= (event_system_event_type,) ; "tool-call" type Event Object event_tool_call_type = ( type: "tool-call", event_common_type, ; e.g., "Bash", "Edit", "Read" tool_name: tstr, ; tool arguments input: any, ; links call and result ? call_id: tstr, agent_entry_reference_type, * $$tool-call-event-ext ) ; "tool-result" type Event Object event_tool_result_type = ( type: "tool-result", event_common_type, ; tool output output: any, ; links call and result ? call_id: tstr, ; "success" / "error" / "completed" ? status: tstr, ? is_error: bool, agent_entry_reference_type, * $$tool-result-event-ext ) ; "reasoning" type Event Object event_reasoning_type = ( type: "reasoning", event_common_type, ; plaintext reasoning or structured content content: any, ; provider protected content ? encrypted: tstr, ; topic label ? subject: tstr, agent_entry_reference_type, * $$reasoning-event-ext ) ; "system-event" type Event Object event_system_event_type = ( type: "system-event", event_common_type, ; event classifier event_type: tstr, ; event specific payload ? data: { * tstr => any }, agent_entry_reference_type, * $$system-event-ext ) vcs_context_type = { ; "git" / "jj" / "hg" / "svn" type: tstr, ; commit SHA or change ID ? revision: tstr, ? branch: tstr, ; repository URL ? repository: tstr, * tstr => any } ; Reference to an entry of the native agent trace agent_entry_reference_type = ( ? entry_id: agent_entry_id_type, ? parent_id: agent_entry_id_type ) ; Per-entry unique reference within a session agent_entry_id_type = tstr ]]>

Editor's Note:

A JSON schema for the ai_agent extension will be added.

Acknowledgments

Contributors XOR

tobias@xor.tech

NVIDIA

tfossati@nvidia.com

Ericsson

jaime@iki.fi

Ericsson

jari.arkko@ericsson.com

AWS

swaym@amazon.co.uk

Huawei Technologies France S.A.S.U.

houda.labiod@huawei.com