Cross-Protocol Translation Governance requires that when AI agents translate state, tasks, instructions, or data between different communication protocols — whether from one agent protocol to another, from an agent protocol to a legacy API, from an orchestration protocol to a tool-invocation protocol, or between any other protocol boundary — the translation process preserves semantic fidelity, security properties, authorisation constraints, and regulatory metadata across the boundary. Protocol translation is not a lossless operation: every protocol encodes different assumptions about authentication, authorisation scope, data typing, error semantics, transaction boundaries, and regulatory context. A translation layer that naively maps fields between protocols can silently drop security constraints, widen authorisation scopes, lose audit metadata, or transform regulated data into unregulated data flows. This dimension mandates that every protocol translation boundary is formally documented, that translation rules are explicit and verifiable, and that security and compliance properties are validated after translation rather than assumed to be preserved.
Scenario A — Authorisation Scope Widened During Translation: A financial services firm operates a hybrid agent infrastructure. Internal agents communicate via a structured orchestration protocol that encodes fine-grained authorisation scopes: each task message carries an auth_scope field specifying permitted actions (e.g., trade:equity:execute:max_value:50000:GBP). The firm integrates with an external market-making partner whose agents use a different protocol that encodes authorisation as a binary flag: authorised: true/false. The translation layer maps any non-empty auth_scope to authorised: true. An internal agent initiates a cross-protocol task to the external partner's system with scope trade:equity:quote_only — a read-only scope that permits obtaining price quotes but not executing trades. The translation layer converts this to authorised: true. The partner's agent, receiving authorised: true, interprets this as full trade execution authority and executes a £1.8 million equity trade on behalf of the firm. The firm discovers the unauthorised trade during end-of-day reconciliation.
What went wrong: The translation layer performed a lossy conversion of the authorisation scope. The source protocol's rich authorisation model was reduced to the target protocol's binary model without preserving the constraint. No post-translation validation checked whether the translated message preserved the authorisation restrictions of the original. The translation rules were not documented — the mapping was implemented as a utility function by a developer who did not understand the authorisation semantics of either protocol. Consequence: £1.8 million unauthorised trade execution, potential market abuse investigation by the FCA, breach of MiFID II best execution obligations, contractual dispute with the external partner, and suspension of the cross-protocol integration pending remediation.
Scenario B — Regulatory Metadata Lost in Translation: A cross-border agent deployment processes insurance claims across EU and Swiss jurisdictions. The EU agent protocol carries GDPR-mandated metadata on every message: data_subject_jurisdiction, legal_basis, processing_purpose, retention_period, and dpia_reference. Claims data is translated from the EU protocol to the Swiss agent protocol, which does not have equivalent metadata fields. The translation layer strips the GDPR metadata as "unsupported fields" and forwards the claim data without regulatory context. The Swiss processing agents handle EU citizen claim data without awareness of GDPR constraints — they retain data beyond the specified retention period, share it with a third-party analytics provider without the processing_purpose restriction, and store it on infrastructure that does not meet the data localisation requirements implied by the data_subject_jurisdiction field. A GDPR audit reveals that 34,000 EU citizen records were processed in Switzerland without adequate safeguards. The Irish Data Protection Commission issues a preliminary finding of €12.4 million.
What went wrong: The translation layer treated GDPR metadata as optional protocol fields rather than as regulatory constraints that must be preserved across the protocol boundary. The Swiss protocol's lack of equivalent fields was treated as a reason to drop the metadata rather than as a signal that the translation could not be performed without compliance risk. No post-translation validation verified that regulatory constraints survived the protocol boundary. Consequence: €12.4 million proposed fine, mandatory data deletion for 34,000 records, 9-month remediation programme, suspension of EU-to-Swiss data transfers pending Standard Contractual Clause implementation, and personal liability risk for the Data Protection Officer.
Scenario C — Transaction Boundary Mismatch Causes Double Execution: A logistics company uses agents to coordinate warehouse operations. The warehouse management protocol supports transactional task execution: a task is either fully committed or fully rolled back. The fleet management protocol used by delivery agents does not support transactions — each instruction is fire-and-forget. A warehouse agent initiates a cross-protocol task: "pick order #47291, load to vehicle Bay-7, confirm dispatch." The translation layer sends three separate instructions to the fleet management protocol: pick, load, confirm. The pick and load instructions succeed. The confirm instruction fails due to a network timeout. The warehouse management protocol rolls back the entire transaction, restoring the order to "pending" status. But the fleet management protocol has already executed the pick and load — the physical goods have been moved. A retry mechanism on the warehouse side re-initiates the full transaction. The translation layer sends three new instructions. The goods are picked again from a different inventory location (the original location now shows empty) and loaded onto a second vehicle. Order #47291 is dispatched twice: once from the physical execution before rollback and once from the retried transaction. The customer receives duplicate shipments. The inventory system shows a discrepancy of €23,400 in missing stock.
What went wrong: The translation layer did not account for the transaction boundary mismatch between the two protocols. The warehouse protocol's transactional guarantee (all-or-nothing execution) was lost during translation to the fleet protocol's fire-and-forget model. No mechanism ensured that a rollback on the warehouse side propagated to the fleet side. No idempotency control prevented the retried transaction from creating a duplicate physical execution. Consequence: €23,400 in inventory discrepancy, duplicate customer shipment, manual reconciliation across warehouse and fleet systems, and loss of confidence in automated warehouse-to-fleet coordination.
Scenario D — Safety Constraint Dropped During Protocol Bridge: An autonomous vehicle fleet uses a safety-rated vehicle-to-infrastructure (V2I) protocol that encodes safety constraints in every message: max_speed_ms, geofence_polygon, emergency_stop_priority. A new parking management system uses a general-purpose task protocol without safety-specific fields. The translation bridge maps park_vehicle commands from the parking protocol to the V2I protocol but does not inject safety constraints into the translated messages because the parking protocol does not carry them. A parking command is translated and sent to a vehicle without max_speed_ms or geofence_polygon constraints. The vehicle, receiving a valid V2I message without safety constraints, applies its default maximum parameters. It traverses a pedestrian zone at 30 km/h (the vehicle's default, not the zone's 5 km/h limit) en route to the designated parking bay. A pedestrian is struck, sustaining serious injuries.
What went wrong: The translation bridge assumed that safety constraints were optional metadata. The target protocol (V2I) required safety constraints on every movement command, but the source protocol (parking management) did not carry them. The translation layer did not inject required safety constraints from context (the vehicle's operational zone, local speed limits). No post-translation validation verified that safety-critical fields were present in the translated message. Consequence: Serious pedestrian injury, criminal investigation under the Road Traffic Act 1988, civil liability estimated at £2.1 million, fleet-wide suspension of automated parking operations, regulatory investigation by the Vehicle Certification Agency.
Scope: This dimension applies to any AI agent deployment where data, state, tasks, instructions, or control signals are translated between two or more distinct protocols. A "protocol translation" occurs whenever a message originating in one protocol's format is transformed into another protocol's format for consumption by a system or agent that speaks the target protocol. This includes: agent-to-agent protocol bridges (e.g., between different agent framework protocols), protocol-to-API translation (e.g., from an orchestration protocol to a REST API), protocol version translation (e.g., between v1 and v2 of the same protocol when semantic changes occurred), and protocol-to-legacy-system adapters. The scope includes both real-time translation (message-by-message as agents communicate) and batch translation (converting stored protocol artefacts from one format to another). The scope excludes serialisation format changes that preserve full semantic fidelity (e.g., converting JSON to Protocol Buffers of the same schema) — these are encoding changes, not protocol translations. The test is: does the transformation require any semantic interpretation, field mapping, scope conversion, or structural reorganisation beyond mechanical format change? If yes, it is a protocol translation and this dimension applies.
4.1. A conforming system MUST maintain a protocol translation registry documenting every active translation boundary, including the source protocol, target protocol, translation direction (unidirectional or bidirectional), the translation rules applied, and the security and compliance properties that must be preserved across the boundary.
4.2. A conforming system MUST define explicit translation rules for every field, method, and semantic construct that crosses a protocol boundary, specifying how the source construct maps to the target construct, what information is lost, gained, or transformed, and what compensating controls are applied for lossy translations.
4.3. A conforming system MUST implement post-translation validation that verifies, after translation, that security properties (authentication, authorisation scope, encryption requirements) present in the source message are preserved or equivalently enforced in the translated message.
4.4. A conforming system MUST implement post-translation validation that verifies, after translation, that regulatory metadata (data subject jurisdiction, legal basis, processing purpose, retention requirements) present in the source message is preserved in the translated message or that compensating controls are documented and active.
4.5. A conforming system MUST block translation of messages where the target protocol cannot represent a security or regulatory constraint present in the source message and no compensating control is available, rather than silently dropping the constraint.
4.6. A conforming system MUST handle transaction boundary mismatches explicitly: where a transactional source protocol is translated to a non-transactional target protocol, the translation layer must implement compensating transaction controls (idempotency keys, saga patterns, or compensation actions) to preserve the source protocol's transactional guarantees.
4.7. A conforming system MUST log every protocol translation event with sufficient detail to reconstruct the source message, the translation rules applied, and the resulting target message, for audit and incident investigation purposes.
4.8. A conforming system MUST inject required fields that the target protocol mandates but the source protocol does not carry, sourcing the values from an authoritative context (configuration, operational parameters, or safety constraints) rather than using defaults or omitting them.
4.9. A conforming system SHOULD implement bidirectional fidelity testing: periodically translate a corpus of test messages from source to target and back, verifying that the round-trip preserves semantic content within defined tolerance.
4.10. A conforming system SHOULD implement translation circuit breakers that halt translation when error rates, validation failures, or semantic drift exceed defined thresholds, preventing cascading failures across protocol boundaries.
4.11. A conforming system SHOULD version translation rules independently, linking each version to the source and target protocol versions it supports, and blocking translation when the active translation rules do not match the detected protocol versions.
4.12. A conforming system MAY implement semantic equivalence scoring that quantifies the fidelity of each translation on a per-message basis, flagging translations that fall below a defined fidelity threshold for manual review.
4.13. A conforming system MAY implement protocol translation sandboxes where new or modified translation rules can be evaluated against production-representative traffic before deployment.
Protocol translation is one of the most dangerous operations in a multi-agent system because it is where assumptions are silently converted into different assumptions. Every protocol embeds a worldview: what constitutes identity, what authorisation means, what happens when something fails, what metadata is mandatory, and what guarantees the protocol provides. When a message crosses a protocol boundary, it moves from one worldview to another. If the translation is not governed, the message arrives in the target protocol carrying the source protocol's assumptions — assumptions that may be incompatible with the target protocol's expectations or, worse, that may be silently violated.
The history of integration failures in enterprise IT is dominated by protocol translation errors. The 2012 Knight Capital incident — where a software deployment error caused $440 million in losses in 45 minutes — involved, at its root, a mismatch between the semantics of old and new protocol versions. The 2016 Bangladesh Bank heist — where attackers stole $81 million through the SWIFT network — exploited translation boundaries between the bank's internal systems and the SWIFT messaging protocol. In both cases, the technical root cause was a failure to preserve constraints across a system boundary where message formats and semantics changed.
AI agent systems face these same risks at greater scale and speed. Modern agent deployments routinely bridge multiple protocols: an orchestration protocol coordinates agent tasks, a tool-invocation protocol executes external actions, a messaging protocol handles inter-agent communication, and legacy APIs connect to existing enterprise systems. Each protocol boundary is a translation point. Each translation point is a potential constraint-dropping point. The risk is compounded by the speed at which agents operate: a human developer translating between protocols might notice that the target protocol lacks an authorisation scope field and raise a question. An automated translation layer processes thousands of messages per second and will silently drop the field unless explicitly programmed to detect and handle the gap.
The regulatory implications are substantial. Under GDPR, the controller must ensure that personal data is processed in accordance with the stated legal basis and purpose limitation throughout its lifecycle. If a protocol translation drops the legal basis metadata, downstream processing may violate the purpose limitation principle (Article 5(1)(b)) without any system or person being aware. Under the EU AI Act, the risk management system must address risks introduced by the AI system's interfaces and integrations. Protocol translation boundaries are interfaces where risks concentrate. Under DORA, financial entities must ensure operational resilience across their ICT infrastructure, including third-party interfaces. A protocol translation that loses transaction guarantees (as in Scenario C) undermines operational resilience.
The safety implications are equally severe. In safety-critical deployments — autonomous vehicles, industrial robotics, medical devices — protocol translation boundaries can drop safety constraints that prevent physical harm. The target protocol may lack fields for safety parameters, or the translation layer may treat safety constraints as optional metadata. The result is a safety-critical command that arrives at its destination without the constraints that make it safe. Scenario D illustrates this failure mode: a parking command translated without speed and geofence constraints because the source protocol did not carry them. The fundamental principle is that protocol translation must be treated as a security-critical, safety-critical, and compliance-critical operation — not as a utility function.
The protocol translation registry is the foundational artefact. For each translation boundary, it must document: source protocol (name, version, schema reference), target protocol (name, version, schema reference), translation direction, every field mapping (source field to target field, with transformation logic), fields present in the source but absent in the target (with disposition: preserved via compensating control, or translation blocked), fields required in the target but absent in the source (with injection source), security property preservation strategy, regulatory metadata preservation strategy, and transaction boundary handling strategy.
Recommended patterns:
trade:equity:quote_only mapped to a binary authorised field must map to the most restrictive interpretation available in the target protocol — in this case, read_only: true if such a field exists, or translation blocked if no restrictive mapping is available.Anti-patterns to avoid:
authorised: true, max_speed: DEFAULT) is extremely dangerous. The default may grant permissions the source did not intend, or set parameters that create safety risk. Missing fields must trigger injection from an authoritative source or translation blocking — never silent defaulting.Financial Services. Protocol translations in financial agent systems frequently involve payment instruction formats (ISO 20022, SWIFT MT, FIX), regulatory reporting formats (MiFID II transaction reports, EMIR trade reports), and risk parameter encoding. Each of these carries regulatory significance: a payment instruction that loses its payment purpose code during translation may violate anti-money laundering requirements. A trade instruction that loses its client identifier may violate MiFID II best execution reporting requirements. Financial protocol translations must be reviewed by compliance functions with specific expertise in the regulatory significance of each protocol field. The FCA expects firms to demonstrate end-to-end data integrity across all system boundaries in their trading and payment infrastructure.
Safety-Critical / Industrial. Protocol translations in safety-critical environments must preserve functional safety properties. IEC 61508 requires that safety-related communications maintain their integrity levels across system boundaries. A translation from a SIL-3 rated protocol to a general-purpose protocol must either maintain SIL-3 integrity guarantees in the translation layer or block the translation. Safety constraint injection (requirement 4.8) is particularly critical: translated commands to physical actuators must always carry appropriate safety parameters regardless of whether the source protocol includes them.
Healthcare. Protocol translations involving patient data must preserve HL7 FHIR resource integrity, HIPAA privacy metadata, and clinical safety constraints. A translation that converts an HL7 FHIR medication order to a general-purpose task protocol must preserve dosage constraints, allergy alerts, and prescribing authority. Loss of clinical safety metadata during translation can result in patient harm and constitutes a reportable patient safety incident.
Basic Implementation — The organisation maintains a protocol translation registry documenting all active translation boundaries. Translation rules are explicitly defined for each boundary. Post-translation validation checks that required target fields are populated and that security credentials are present. Translation events are logged. Transaction boundary mismatches are handled with basic retry logic and manual reconciliation. This level meets minimum mandatory requirements but has weaknesses: validation may not verify semantic preservation (only field presence), authorisation scope preservation may rely on developer judgment rather than explicit mapping tables, and safety constraint injection may be ad hoc.
Intermediate Implementation — Translation contracts are machine-readable and versioned. Post-translation validation verifies semantic preservation — not just field presence but value fidelity, authorisation scope restriction, and regulatory metadata completeness. Compensating transaction patterns (Saga or equivalent) handle transaction boundary mismatches automatically. Authorisation scope mapping uses explicit, reviewed mapping tables that default to the most restrictive interpretation. Safety constraint injection sources are documented and authoritative. Bidirectional fidelity testing is performed periodically. Translation circuit breakers halt operations when error rates exceed thresholds.
Advanced Implementation — All intermediate capabilities plus: semantic equivalence scoring quantifies translation fidelity per message, with continuous monitoring and alerting when fidelity degrades. Translation rules are independently audited against regulatory requirements. Adversarial testing evaluates whether a crafted source message can exploit translation to widen authorisation scope, drop security constraints, or bypass safety controls. Translation sandboxes allow testing new rules against production-representative traffic. Translation metrics (fidelity scores, error rates, blocked translation rates, circuit breaker activations) are reported to governance boards. The translation layer has been independently verified by a safety assessor for safety-critical deployments.
Required artefacts:
Retention requirements:
Access requirements:
Testing AG-378 compliance requires verifying that translation preserves critical properties, blocks unsafe translations, handles transaction mismatches, and injects required fields.
Test 8.1: Authorisation Scope Preservation
read_only, quote_only, max_value:50000). The target protocol has a less granular authorisation model.read_only mapped to authorised: true), or the constraint is silently dropped.Test 8.2: Regulatory Metadata Preservation
Test 8.3: Transaction Boundary Mismatch Handling
Test 8.4: Required Field Injection
Test 8.5: Constraint-Dropping Detection and Blocking
Test 8.6: Translation Logging Completeness
Test 8.7: Bidirectional Fidelity Verification
Test 8.8: Translation Version Mismatch Detection
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| EU AI Act | Article 12 (Record-Keeping) | Supports compliance |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Direct requirement |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, MAP 3.2, MANAGE 2.3 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
| DORA | Article 9 (ICT Risk Management Framework), Article 11 (ICT Response and Recovery) | Direct requirement |
Article 9 requires that the risk management system for high-risk AI systems identify and analyse risks that may emerge when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse. Protocol translation boundaries are locations where risks concentrate — authorisation widening, constraint dropping, and semantic distortion are all risks that emerge during intended use of multi-protocol agent systems. The requirement that risk mitigation measures be tested maps directly to the post-translation validation and bidirectional fidelity testing requirements of AG-378. A translation layer that silently drops safety constraints constitutes a deficiency in the risk management system.
Article 12 requires that high-risk AI systems include logging capabilities that enable the recording of events relevant to the identification of risks and post-market monitoring. Protocol translation events — including what was translated, what rules were applied, what validation occurred, and what constraints were dropped or blocked — are events relevant to risk identification. The translation logging requirement (4.7) directly implements Article 12's record-keeping obligation for the protocol translation layer.
For AI agents processing financial transactions across protocol boundaries, the integrity of the translation directly affects internal controls over financial reporting. A translation that widens authorisation scope (Scenario A) is a control failure. A translation that loses transaction boundaries (Scenario C) can cause duplicate financial entries. SOX auditors assessing multi-protocol agent systems will examine whether data integrity is maintained across all system boundaries, including protocol translations. The translation contract, post-translation validation, and logging requirements of AG-378 provide the auditable evidence needed to demonstrate control integrity across protocol boundaries.
SYSC 6.1.1R requires adequate policies and procedures for systems and controls. For firms operating AI agents across multiple protocols — a common architecture in financial services where agents bridge internal orchestration protocols, market data protocols, and payment protocols — the FCA expects end-to-end data integrity. A protocol translation that alters the semantics of a trade instruction, drops a client identifier, or widens an authorisation scope represents inadequate systems and controls. The FCA's Principles for Businesses (Principle 3: Management and control) requires firms to take reasonable care to organise and control their affairs responsibly and effectively. Ungoverned protocol translations in agent infrastructure fail this standard.
GOVERN 1.1 addresses legal and regulatory requirements; MAP 3.2 addresses risk context mapping for AI systems; MANAGE 2.3 addresses risk controls for AI system interfaces. AG-378 supports compliance by ensuring that regulatory requirements are preserved across protocol boundaries (GOVERN 1.1), mapping translation boundaries as risk concentration points (MAP 3.2), and implementing validation and blocking controls at those boundaries (MANAGE 2.3).
Clause 6.1 requires actions to address risks within the AI management system. Clause 8.2 requires AI risk assessment. Protocol translation boundaries are risk points that must be addressed within the AI management system. The translation registry, contracts, and validation mechanisms implement risk treatments for translation-specific risks. The evidence requirements provide the documentation needed for Clause 8.2 risk assessments covering protocol translation.
Article 9 requires comprehensive ICT risk management covering all interfaces and dependencies. Protocol translation boundaries are ICT interfaces where data integrity, security properties, and transaction guarantees may be compromised. Article 11 requires ICT response and recovery capabilities. Transaction boundary mismatch handling (requirement 4.6) — particularly compensating transaction patterns — implements recovery capability for cross-protocol transaction failures. DORA's emphasis on operational resilience requires that protocol translations do not become single points of failure in agent operations; the circuit breaker requirement (4.10) addresses this directly.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Cross-organisation — protocol translations frequently span organisational boundaries, and constraint loss propagates to all downstream consumers of the translated message |
Consequence chain: Without cross-protocol translation governance, every protocol boundary in the agent infrastructure becomes a potential constraint-dropping point. The immediate technical failure is silent semantic distortion: a message arrives at its destination with different authorisation scope, missing regulatory metadata, absent safety constraints, or broken transaction guarantees. The recipient system processes the message in good faith — it has no way to know that constraints were lost in translation. The operational consequence depends on the nature of the lost constraint: authorisation widening leads to unauthorised actions (potentially millions in governed exposure, as in Scenario A); regulatory metadata loss leads to compliance violations across entire data populations (potentially millions in fines, as in Scenario B); transaction boundary loss leads to data inconsistency and duplicate execution (operational disruption and financial discrepancy, as in Scenario C); safety constraint loss leads to physical harm (injury, equipment damage, and criminal liability, as in Scenario D). The blast radius extends across organisational boundaries because protocol translations frequently bridge internal and external systems. A constraint dropped during translation to an external partner's protocol cannot be recovered — the external system processes the unconstrained message, and the consequences propagate through the partner's operations. The compounding effect is that protocol translation failures are silent by nature: unlike a service outage that triggers immediate alerts, a translation that silently drops a constraint produces correct-looking messages that cause harm downstream, potentially for weeks or months before detection. The cumulative exposure grows linearly with message volume and can reach catastrophic levels before any incident triggers investigation.