--- title: "Cross-Protocol Agent Translation (CPAT)" abbrev: "CPAT" category: std docname: draft-cpat-cross-protocol-agent-translation-00 submissiontype: IETF number: date: v: 3 area: "ART" workgroup: "DISPATCH" keyword: - agent interoperability - protocol translation - agentic workflows - execution context author: - fullname: Generated by IETF Draft Analyzer organization: Independent email: placeholder@example.com normative: RFC7519: RFC7515: RFC9110: RFC8615: I-D.nennemann-wimse-ect: title: "Execution Context Tokens for Distributed Agentic Workflows" target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/ informative: I-D.nennemann-agent-dag-hitl-safety: title: "Agent Context Policy Token: DAG Delegation with Human Override" target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/ --- abstract This document defines the Cross-Protocol Agent Translation (CPAT) framework, a mechanism enabling AI agents using different communication protocols to interoperate. With over 90 competing agent-to-agent protocol drafts and no interoperability standard, protocol fragmentation is the primary barrier to multi-vendor agent ecosystems. CPAT defines capability advertisement, protocol negotiation, and translation gateways. Translation hops are recorded as Execution Context Token (ECT) DAG nodes, giving every cross-protocol interaction a cryptographic audit trail without inventing a parallel tracing mechanism. --- middle # Introduction The IETF AI/agent landscape includes over 90 drafts proposing agent-to-agent communication protocols, yet no standard exists for agents using different protocols to exchange messages. CPAT takes a pragmatic approach: rather than mandating a single protocol, it defines the minimum machinery for agents to discover each other's protocol support, agree on a common format, and fall back to translation gateways when no common protocol exists. CPAT builds on Execution Context Tokens {{I-D.nennemann-wimse-ect}} as its audit and tracing backbone. Every translation hop produces an ECT, linking into the workflow DAG alongside the source and destination agents. This eliminates the need for a separate tracing or provenance mechanism -- the ECT DAG already provides it. Design principles: 1. Reuse existing standards (HTTP, JSON, TLS, ECT) wherever possible. 2. Keep the core mechanism small enough to implement in a day. 3. Do not require agents to support any protocol beyond their own plus CPAT negotiation. # Conventions and Definitions {::boilerplate bcp14-tagged} The following terms are used in this document: Agent Protocol: : A communication protocol used by an AI agent for peer-to-peer message exchange (e.g., A2A, MCP, SLIM, uACP). Capability Document: : A JSON object describing the protocols an agent supports, served at a well-known URI. Translation Gateway: : A service that converts messages between two agent protocols, recording each translation as an ECT DAG node. # Problem Statement Consider three agents: Agent A speaks Protocol X, Agent B speaks Protocol Y, and Agent C speaks both X and Z. Today there is no standard way for A to discover that B uses a different protocol, negotiate a common format, or route through a translator. Existing work on Agent Name Service (ANS) and agent discovery addresses finding agents but not protocol compatibility. CPAT fills the gap between discovery and communication. # Protocol Capability Advertisement {#capability-ad} Each CPAT-compliant agent MUST serve a capability document at the well-known URI `/.well-known/cpat` {{RFC8615}}. The document is a JSON object: ~~~json { "cpat_version": "1.0", "agent_id": "spiffe://example.com/agent/pricing", "protocols": [ { "id": "a2a-v1", "version": "1.0", "endpoint": "https://agent.example.com/a2a", "priority": 10 }, { "id": "mcp-v1", "version": "2025-03-26", "endpoint": "https://agent.example.com/mcp", "priority": 20 } ], "translation_gateways": [ "https://gateway.example.com/cpat/translate" ], "ect_assurance_level": "L2" } ~~~ {: #fig-capability title="Capability Document Example"} The `protocols` array MUST contain at least one entry. Each entry MUST include `id` (a registered protocol identifier), `version`, and `endpoint`. The `priority` field is OPTIONAL; lower values indicate higher preference. The `ect_assurance_level` field declares the minimum ECT assurance level the agent requires for interactions. This enables gateways to produce ECTs at the correct level. Agents SHOULD also advertise their capability document URI in DNS SVCB records. The DNS record type `_cpat._tcp` SHOULD be used. # Negotiation Handshake {#negotiation} When Agent A wants to communicate with Agent B: Step 1: : Agent A fetches Agent B's capability document from B's well-known CPAT URI over HTTPS. Step 2: : Agent A computes the intersection of its own protocol list with Agent B's. If the intersection is non-empty, the protocol with the lowest combined priority score is selected. Communication proceeds directly using that protocol. Step 3: : If no common protocol exists, Agent A checks whether any translation gateway listed by either agent supports both protocols. Agent A queries the gateway: ~~~ GET /.well-known/cpat/gateway?from=a2a-v1&to=slim-v1 ~~~ The gateway responds with 200 OK if it supports the pair, or 404 if not. Step 4: : If a suitable gateway is found, Agent A sends its message to the gateway, which translates and forwards it to Agent B. The gateway records the translation as an ECT (see {{ect-integration}}). Step 5: : If no gateway supports the required pair, Agent A returns an error to its caller with error code `no_translation_path`. The entire negotiation is stateless and cacheable. Agents SHOULD cache capability documents for the duration indicated by HTTP Cache-Control headers, defaulting to 3600 seconds. # ECT Integration {#ect-integration} Every translation hop produces an ECT {{I-D.nennemann-wimse-ect}} that links into the workflow DAG. This provides cryptographic proof of protocol translation without a separate tracing mechanism. ## Translation ECT Claims A gateway producing a translation ECT MUST set: - `exec_act`: `"cpat:translate"` - `par`: array containing the `jti` of the source agent's ECT - `wid`: the workflow identifier from the source ECT (preserving workflow continuity across protocol boundaries) The `ext` claim carries CPAT-specific metadata: ~~~json { "ext": { "cpat.source_protocol": "a2a-v1", "cpat.dest_protocol": "slim-v1", "cpat.gateway_id": "spiffe://gw.example.com/cpat", "cpat.translation_warnings": [] } } ~~~ {: #fig-translation-ect title="Translation ECT Extension Claims"} The `inp_hash` claim MUST contain the SHA-256 hash of the source protocol message. The `out_hash` claim MUST contain the SHA-256 hash of the translated message. This allows verifiers to confirm that a specific input produced a specific output without accessing the message content. ## Assurance Level Inheritance The gateway MUST produce ECTs at the higher of: - The source agent's declared `ect_assurance_level` - The destination agent's declared `ect_assurance_level` At L3, the translation ECT MUST be recorded in the audit ledger before the translated message is forwarded to the destination agent. ## DAG Continuity The translation creates a three-node subgraph in the workflow DAG: ~~~ Source Agent ECT (exec_act: "send_task") | v [par reference] Gateway ECT (exec_act: "cpat:translate") | v [par reference] Dest Agent ECT (exec_act: "receive_task") ~~~ {: #fig-dag-continuity title="Translation DAG Subgraph"} The Execution-Context HTTP header {{I-D.nennemann-wimse-ect}} survives protocol translation: the gateway includes the translation ECT in the Execution-Context header of the forwarded request to the destination agent. # Translation Gateway Requirements {#gateway-reqs} A CPAT translation gateway MUST: 1. Serve a capability document listing all supported protocol pairs at `/.well-known/cpat/gateway`. 2. Accept messages via HTTP POST at its translate endpoint. 3. Produce an ECT for every translation per {{ect-integration}}. 4. Preserve message semantics: the intent, core payload content, and metadata MUST survive translation. Fields with no equivalent in the destination protocol SHOULD be carried in a protocol-specific extension field or dropped with a warning recorded in `cpat.translation_warnings`. 5. Return the translated message in the response body, or forward it directly to the destination agent. A gateway MUST NOT modify payload semantics during translation. Gateways MUST require TLS 1.3 for all connections and SHOULD implement rate limiting per source agent. # Policy Integration {#policy-integration} When used with the Agent Context Policy Token {{I-D.nennemann-agent-dag-hitl-safety}}, CPAT-related policies can be expressed as DAG node constraints: ~~~json { "dag": { "nodes": [ { "id": "n-translate", "type": "cpat:translate", "agent": "spiffe://gw.example.com/cpat", "constraints": { "allowed_source_protocols": ["a2a-v1", "mcp-v1"], "allowed_dest_protocols": ["slim-v1"], "max_translation_hops": 2 } } ] } } ~~~ {: #fig-policy title="CPAT Policy as DAG Node Constraints"} The `max_translation_hops` constraint prevents messages from being translated through an excessive number of gateways. Agents receiving a message SHOULD reject it if the ECT DAG contains more translation hops than allowed by policy. # Security Considerations Capability documents are served over HTTPS, ensuring transport security. Agents SHOULD verify TLS certificates before trusting capability documents. Gateways are trusted intermediaries with access to message content during translation. For end-to-end confidentiality, agents MAY encrypt the message payload using a shared key established out of band; the gateway translates only the protocol framing, not the encrypted content. The ECT audit trail ({{ect-integration}}) enables detection of: - Unauthorized gateways (unexpected `cpat.gateway_id` in the DAG) - Content tampering (mismatched `inp_hash`/`out_hash` relative to message content) - Routing loops (repeated gateway IDs in the DAG ancestry) At L3, the audit ledger provides tamper-evident proof of all translations for regulatory compliance. # IANA Considerations This document requests the following IANA registrations: 1. A "CPAT Protocol Identifier" registry under Expert Review policy. Initial entries: "a2a-v1", "mcp-v1", "slim-v1", "uacp-v1", "ainp-v1". 2. A well-known URI registration for "cpat" per {{RFC8615}}. 3. Registration of the `exec_act` value "cpat:translate" in a future ECT action type registry. --- back # Acknowledgments {:numbered="false"} This document builds on the Execution Context Token specification {{I-D.nennemann-wimse-ect}} and the Agent Context Policy Token {{I-D.nennemann-agent-dag-hitl-safety}}.