An AI Agent Extension for Virtualized Conversations (vCon)

1.1. 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 [RFC9334].¶

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 [RFC9943].¶

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 [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 [VCON-CORE] apply unchanged. The application of COSE [STD96] to vCons that carry agent conversation vCon records is described in the SCITT architecture Appendix B.¶

1.2. 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 [VACR]. 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 [VCON-CORE] defines as CDDL [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 Section 4.7 after the sections for the extension points. Appendix C maps each data item of [VACR] 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 [ROSENBERG-RESTRUCTURE]. [HOWE-AGENT-SESSION] and [HOWE-PROVENANCE] 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 [VCON-CORE] (CDDL syntax version 0.5.0), which introduces the Session Object and the Event Object. Sections of [VCON-CORE] are therefore referenced by name and not by number.¶

2.1. Terminology

See the Terminology section of [VCON-CORE] 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.¶

4.1. 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.¶

Editor's Note:

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

4.2. vCon Object Parameters

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

$$vcon-ext //= ( recording_agent: recording_agent_type )
$$vcon-ext //= ( vcs: vcs_context_type )
$$vcon-ext //= ( file_attribution: file_attribution_type )

; Recording_Agent Object
recording_agent_type = {
    name: tstr,
    ? version: tstr,
    * tstr => 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 [HOWE-AGENT-SESSION].¶

4.3. Party Object Parameters

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

$$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
  }

Editor's Note:

Alternative placements for agent_meta are the Session Object and the generation provenance of [HOWE-PROVENANCE].¶

4.4. 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 [VCON-CORE].¶

This extension adds the following parameters to the Session Object, using the session-ext socket:¶

$$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
  }

4.5. 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:¶

$$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
  }

Editor's Note:

An alternative placement for model_id and token_usage is the generation provenance of [HOWE-PROVENANCE].¶

4.6. 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.¶

$$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
  )

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 (Section 4.7.2) 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 [HOWE-AGENT-SESSION]. It is also an open question whether the "tool-call" and "reasoning" Event Object types apply to human parties.¶

4.7. Reusable Definitions

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

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

7.1. 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.¶

7.2. 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.¶

7.3. 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 [VCON-CORE]. A redactor that removes an Event Object entirely leaves a placeholder in the events array, so that indexes in other Objects do not change.¶

7.4. External References

This extension does not add url and content_hash parameters for externally referenced files as defined in [VCON-CORE], 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.¶

7.5. 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.¶

7.6. 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 (Appendix B) reveals session identifiers, agent vendor, and timestamps even when the payload is encrypted.¶

7.7. 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.¶

8.1. Record Integrity

The signed form of a vCon [VCON-CORE] and the signed-agent-record envelope (Appendix B) 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.¶

8.2. 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.¶

8.3. 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 [RFC9943].¶

8.4. 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.¶

8.5. 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 [RFC9943] that provide independent timestamp proof via registration receipts, append-only logs preventing retroactive denial, and third-party witnesses to the signing event.¶

8.6. 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.¶

9.1. vCon JSON Registry Additions

10.1. Normative References

[JSON]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[VCON-CORE]

Petrie, D., "The JSON format for vCon - Conversation Data Container", Work in Progress, Internet-Draft, draft-ietf-vcon-vcon-core-04, 7 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-vcon-vcon-core-04>.

10.2. Informative References

[AICPA_TSC_2017]

American Institute of Certified Public Accountants and Chartered Institute of Management Accountants, "Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus - 2022)", AICPA Trust Services Criteria, 2017, <https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022>.

[BSI_AI_FINANCE_2024]

Bundesamt fuer Sicherheit in der Informationstechnik, "Test Criteria Catalogue for AI Systems in Finance", BSI AI Finance Test Criteria, 2024, <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/AI-Finance_Test-Criteria.pdf>.

[CDDL]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[EMERGENT_MISALIGNMENT_2025]

Betley, J., Tan, D., Warncke, N., Sztyber-Betley, A., Bao, X., Soto, M., Labenz, N., and O. Evans, "Emergent Misalignment: Narrow finetuning can produce broadly misaligned LLMs", arXiv 2502.17424, PMLR 267:4043-4068, February 2025, <https://arxiv.org/abs/2502.17424>.

[ETSI_TS_104223_2025]

European Telecommunications Standards Institute, "Securing Artificial Intelligence (SAI); Baseline Cyber Security Requirements for AI Models and Systems", ETSI TS 104 223, V1.1.1, April 2025, <https://www.etsi.org/deliver/etsi_ts/104200_104299/104223/01.01.01_60/ts_104223v010101p.pdf>.

[EU_AI_ACT_2024]

European Parliament and Council of the European Union, "Regulation (EU) 2024/1689 (Artificial Intelligence Act)", Official Journal of the European Union L 2024/1689, CELEX: 32024R1689, July 2024, <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.

[EU_CRA_2024]

European Parliament and Council of the European Union, "Regulation (EU) 2024/2847 (Cyber Resilience Act)", Official Journal of the European Union L 2024/2847, CELEX: 32024R2847, November 2024, <https://eur-lex.europa.eu/eli/reg/2024/2847/oj>.

[EU_NIS2_2022]

European Parliament and Council of the European Union, "Directive (EU) 2022/2555 (NIS 2 Directive)", Official Journal of the European Union L 333, CELEX: 32022L2555, December 2022.

[FFIEC_IT_HANDBOOK_2024]

Federal Financial Institutions Examination Council, "Information Technology Examination Handbook", FFIEC IT Examination Handbook, August 2024, <https://ithandbook.ffiec.gov/>.

[HOWE-AGENT-SESSION]

McCarthy-Howe, T., "vCon Agent Session", Work in Progress, Internet-Draft, draft-howe-vcon-agent-session-00, 20 May 2026, <https://datatracker.ietf.org/doc/html/draft-howe-vcon-agent-session-00>.

[HOWE-PROVENANCE]

McCarthy-Howe, T., "vCon Generation Provenance", Work in Progress, Internet-Draft, draft-howe-vcon-provenance-00, 4 June 2026, <https://datatracker.ietf.org/doc/html/draft-howe-vcon-provenance-00>.

[ISO_IEC_42001_2023]

International Organization for Standardization and International Electrotechnical Commission, "Information technology - Artificial intelligence - Management system", ISO/IEC 42001:2023, December 2023, <https://www.iso.org/standard/42001>.

[ISO_IEC_DIS_24970]

International Organization for Standardization and International Electrotechnical Commission, "Artificial intelligence - AI system logging", ISO/IEC DIS 24970, 2025, <https://www.iso.org/standard/88723.html>.

[NIST_AI_100_2_E2025]

National Institute of Standards and Technology, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations", NIST AI 100-2 E2025, March 2025, <https://csrc.nist.gov/pubs/ai/100/2/e2025/final>.

[NIST_SP_800_53_R5]

National Institute of Standards and Technology, "Security and Privacy Controls for Information Systems and Organizations", NIST Special Publication 800-53, Revision 5, September 2020, <https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final>.

[OMB_M_21_31]

Office of Management and Budget, "Improving the Federal Government's Investigative and Remediation Capabilities Related to Cybersecurity Incidents", OMB Memorandum M-21-31, August 2021, <https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf>.

[PCI_DSS_V4_0_1]

PCI Security Standards Council, "Payment Card Industry Data Security Standard", PCI DSS Version 4.0.1, June 2024, <https://www.pcisecuritystandards.org/document_library/>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/rfc/rfc6973>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9360]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, February 2023, <https://www.rfc-editor.org/rfc/rfc9360>.

[RFC9393]

Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", RFC 9393, DOI 10.17487/RFC9393, June 2023, <https://www.rfc-editor.org/rfc/rfc9393>.

[RFC9597]

Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024, <https://www.rfc-editor.org/rfc/rfc9597>.

[RFC9682]

Bormann, C., "Updates to the Concise Data Definition Language (CDDL) Grammar", RFC 9682, DOI 10.17487/RFC9682, November 2024, <https://www.rfc-editor.org/rfc/rfc9682>.

[RFC9942]

Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, <https://www.rfc-editor.org/rfc/rfc9942>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

[ROSENBERG-RESTRUCTURE]

Rosenberg, J., "Virtualized Conversations (VCON) Restructure to Facilitate AI Agent Use Cases", Work in Progress, Internet-Draft, draft-rosenberg-vcon-restructure-00, 11 September 2026, <https://datatracker.ietf.org/doc/html/draft-rosenberg-vcon-restructure-00>.

[STD94]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[STD96]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[VACR]

Birkholz, H., Heldt, T., and O. Steele, "Verifiable Agent Conversation Records", Work in Progress, Internet-Draft, draft-birkholz-verifiable-agent-conversations-01, 31 August 2026, <https://datatracker.ietf.org/doc/html/draft-birkholz-verifiable-agent-conversations-01>.

A.1. Applicable Requirement Frameworks

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

A.2. 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.¶

A.3. Framework-Specific Requirements

A.4. Compliance Mapping Table

The following table maps this specification's data elements to compliance requirements:¶

A.5. Security Requirements addressing Regulatory Compliance

A.6. Related Standards and Emerging Work

The ISO/IEC JTC 1/SC 42 committee is developing [ISO_IEC_DIS_24970], 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 [EMERGENT_MISALIGNMENT_2025] 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.¶

B.1. 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 ([RFC9334]) and SCITT auditability ([RFC9943]) 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 [RFC9597].¶

unprotected:

The unprotected header carrying trace metadata at label 100 and, after registration, the receipts [RFC9942] 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 [RFC9360].¶

B.2. 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.¶