Protocol Handshake, Capability Negotiation and Downgrade Protection Governance requires that all inter-agent communications begin with a structured handshake that establishes the protocol version, negotiates the capability set both parties will use, and prevents unauthorised downgrade to weaker protocol versions or reduced governance requirements. In a protocolised ecosystem where agents from different organisations, platforms, and trust domains interact, the handshake is the first line of defence: it determines whether two agents should communicate, at what governance level, and with what mutual assurances. Without this dimension, agents may silently fall back to insecure protocol versions, negotiate away governance requirements, or accept capability claims without verification — creating exploitable gaps in inter-agent governance.
Scenario A — Protocol Downgrade Attack in Financial Settlement: Two settlement agents — one from Bank A and one from Bank B — communicate via an inter-agent protocol that supports versions 1.0 through 3.0. Version 3.0 includes mandatory transaction signing, counterparty verification, and audit trail synchronisation. An adversary performs a man-in-the-middle interception and modifies the handshake response to indicate that Bank B's agent only supports version 1.0, which has no transaction signing. Bank A's agent silently downgrades to version 1.0. The adversary then substitutes their own agent for Bank B's agent and initiates 23 settlement instructions totalling £4.2 million. Because version 1.0 has no transaction signing, Bank A's agent cannot distinguish the adversary's instructions from legitimate ones.
What went wrong: The protocol allowed implicit downgrade without human approval or governance policy check. The handshake did not verify that the downgrade was genuine (Bank B's agent actually supports v3.0). No minimum protocol version was enforced. Consequence: £4.2 million in fraudulent settlement instructions, regulatory investigation for inadequate inter-agent security controls, settlement finality disputes between Bank A and Bank B.
Scenario B — Capability Negotiation Stripping Governance Requirements: An orchestration agent negotiates capabilities with a data-processing agent. The orchestration agent requests: encrypted data transfer, audit logging, PII redaction, and access-scoped queries. The data-processing agent responds that it supports all except PII redaction, and proposes proceeding without it. The orchestration agent accepts the reduced capability set. PII flows unredacted through 14,000 records before a downstream compliance check detects the exposure.
What went wrong: The capability negotiation treated all capabilities as optional. No capability was flagged as a governance-mandated minimum that cannot be negotiated away. The orchestration agent had no policy defining which capabilities are mandatory for the data classification in play. Consequence: 14,000 PII records exposed without redaction, GDPR Article 33 breach notification obligation triggered, potential £8.7 million fine based on annual turnover.
Scenario C — Handshake Replay Enabling Stale Trust Assertion: An agent captures a valid handshake exchange from three months ago and replays it to establish a session with a target agent. The target agent accepts the replayed handshake because it validates the cryptographic signatures (which are genuine) but does not check the handshake timestamp or session nonce. The replaying agent gains access using trust assertions that have since been revoked — the originating agent's permissions were reduced two months ago following a security incident.
What went wrong: The handshake protocol did not include replay protection (timestamp validation, nonce verification, or session binding). Trust assertions from the handshake were accepted without freshness verification. Consequence: Unauthorised access to data and capabilities that should have been revoked, invalidation of the trust revocation that was implemented as a remediation measure.
Scope: This dimension applies to all AI agent systems where two or more agents communicate using a structured protocol — including inter-organisational agent interactions, intra-organisational multi-agent orchestration, agent-to-agent delegation, and any communication where governance requirements must be mutually agreed before data or action exchange begins. It applies to all protocol layers: transport, message format, capability advertisement, and governance assertion. Agents that operate in complete isolation with no inter-agent communication are excluded.
4.1. A conforming system MUST require a structured handshake before any inter-agent data or action exchange, establishing protocol version, supported capabilities, and governance assertions.
4.2. A conforming system MUST enforce a minimum protocol version policy that prevents downgrade below the organisation's configured floor, regardless of what the remote agent advertises.
4.3. A conforming system MUST classify negotiable capabilities as either mandatory (cannot be negotiated away) or optional (may be omitted by mutual agreement), with the classification driven by governance policy — not by the agents' preferences.
4.4. A conforming system MUST reject any handshake that would result in a governance level below the minimum required for the data classification or action type involved in the interaction.
4.5. A conforming system MUST include replay protection in the handshake protocol, using at minimum a cryptographic nonce and a timestamp with a maximum acceptable skew of 300 seconds (5 minutes).
4.6. A conforming system MUST log every handshake attempt — successful and failed — with both parties' identities, requested and agreed protocol version, requested and agreed capabilities, and any capabilities that were negotiated away.
4.7. A conforming system MUST alert governance operators when a downgrade is requested, even if the downgrade is above the minimum floor, as this may indicate either a misconfigured remote agent or a downgrade attack in progress.
4.8. A conforming system SHOULD implement mutual capability verification during the handshake, where each agent proves it actually supports the capabilities it claims — not just declares them.
4.9. A conforming system SHOULD support capability re-negotiation during a session when conditions change (e.g., data classification escalates), with the same governance protections as the initial handshake.
4.10. A conforming system MAY implement handshake caching for repeated interactions between the same agent pair, provided the cache has a maximum TTL of 3,600 seconds (1 hour) and is invalidated on any trust or permission change.
Protocol handshake and capability negotiation governance addresses the attack surface created when agents from different trust domains interact. In traditional software, API contracts are defined at development time and enforced at the infrastructure layer — version negotiation follows well-understood protocols (TLS version negotiation, HTTP content negotiation) with decades of security research behind them. Agent-to-agent communication introduces new challenges because: agents may dynamically discover interaction partners, the capability set may change between sessions, and governance requirements are not static properties of the protocol but contextual properties of the interaction.
The downgrade protection requirement is drawn directly from lessons learned in TLS deployment. The POODLE attack (2014) exploited the ability to force TLS connections to downgrade to SSL 3.0. The DROWN attack (2016) exploited servers that still supported SSLv2. In both cases, the protocol supported strong security but the ability to negotiate weaker versions created an exploitable vulnerability. The same principle applies to inter-agent protocols: if an agent can be persuaded to accept a weaker protocol version or a reduced capability set, the governance guarantees of the stronger version are lost.
Capability negotiation governance prevents a subtler failure mode: the silent erosion of governance requirements through bilateral negotiation. When two agents negotiate capabilities, they may legitimately agree to omit capabilities that neither needs. But some capabilities — audit logging, data redaction, transaction signing — are governance mandates, not features. Allowing agents to negotiate away governance mandates defeats the purpose of having mandates. AG-175 requires that governance-mandated capabilities be classified as non-negotiable.
The handshake is also the point at which trust is established between agents. AG-080 governs the trust framework; AG-175 governs the protocol mechanism by which trust is asserted, verified, and agreed. A handshake that does not verify trust assertions, check their freshness, or prevent replay is a trust establishment mechanism that can be trivially defeated.
The handshake protocol should follow a three-phase structure: (1) protocol version negotiation, (2) capability negotiation, and (3) governance assertion exchange. Each phase must complete successfully before the next begins. Failure at any phase terminates the handshake and prevents communication.
Recommended patterns:
encryption.aes256, audit.full, and redaction.pii. These cannot be negotiated away regardless of what both agents prefer.Anti-patterns to avoid:
Financial Services. Inter-agent handshakes for settlement, trading, and payment protocols should align with ISO 20022 message security requirements and FIX protocol session management patterns. Downgrade protection is critical — a downgrade from a signed to unsigned protocol could invalidate settlement finality. The FCA expects firms to demonstrate that inter-system communication controls are at least equivalent to existing FIX session management controls.
Healthcare. Agent-to-agent data exchange involving PHI must negotiate HIPAA-compliant encryption and access controls as mandatory capabilities. The handshake must verify that the remote agent is authorised to receive the specific data categories being shared. HL7 FHIR security labels should inform mandatory capability classification.
Cross-Border. Agents from different jurisdictions may operate under different regulatory regimes with different minimum security requirements. The handshake must negotiate a capability set that satisfies the most restrictive jurisdiction involved. AG-015 (Organisational Namespace Isolation) intersects here — the handshake must verify namespace isolation between the parties.
Basic Implementation — Agents perform a structured handshake before communication. Protocol version is negotiated bilaterally. A minimum version floor is configured. Handshake failures are logged. Capabilities are declared but all are treated as optional.
Intermediate Implementation — Mandatory capability classification enforced during negotiation. Replay protection via nonce and timestamp. Downgrade alerts generated. Handshake logs include full capability negotiation details. Governance assertions are exchanged and verified during the handshake. Session binding prevents post-handshake hijacking.
Advanced Implementation — All intermediate capabilities plus: mutual capability verification (agents prove they can do what they claim). Graduated downgrade alerting with severity-proportional response. Periodic re-validation during long-running sessions. Cross-organisational handshake federation with standardised protocol. Independent adversarial testing of downgrade resistance, replay protection, and capability negotiation manipulation.
Required artefacts:
Retention requirements:
Access requirements:
Testing AG-175 compliance requires verifying the handshake mechanism, downgrade protection, capability negotiation enforcement, and replay resistance.
Test 8.1: Minimum Version Floor Enforcement
Test 8.2: Downgrade Attack Resistance
Test 8.3: Mandatory Capability Enforcement
redaction.pii, which is classified as mandatory for sensitive data.Test 8.4: Replay Attack Resistance
Test 8.5: Handshake Logging Completeness
Test 8.6: Governance Assertion Verification
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 15 (Accuracy, Robustness, Cybersecurity) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, MANAGE 2.2, MANAGE 4.1 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Annex A.8 (Operating AI Systems) | Supports compliance |
| DORA | Article 9 (ICT Risk Management), Article 14 (Communication) | Direct requirement |
| FCA SYSC | 6.1.1R (Systems and Controls) | Supports compliance |
| PCI DSS 4.0 | Requirement 4 (Protect Cardholder Data with Strong Cryptography During Transmission) | Supports compliance |
Article 15 requires high-risk AI systems to be resilient against attempts by unauthorised third parties to alter their use or performance by exploiting system vulnerabilities. Protocol downgrade attacks and capability negotiation manipulation are precisely the type of vulnerability Article 15 addresses. AG-175 implements the cybersecurity resilience requirement for inter-agent communications by preventing protocol downgrades, ensuring mandatory capabilities cannot be stripped, and protecting against replay attacks.
DORA Article 9 requires financial entities to maintain an ICT risk management framework that addresses communication security. Article 14 specifically addresses communication policies. Inter-agent handshake governance directly implements these requirements by ensuring that agent-to-agent communications begin with verified, tamper-resistant protocol establishment.
For agents handling payment card data, the handshake must negotiate encryption capabilities that meet PCI DSS requirements. Mandatory capability classification ensures that PCI-required encryption cannot be negotiated away.
The FCA expects systems and controls for inter-system communication that are at least equivalent to those applied to traditional financial messaging protocols (SWIFT, FIX). AG-175 provides the governance framework for agent-to-agent communication that satisfies this equivalence requirement.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Cross-organisation — protocol failures affect all parties to inter-agent communications and can propagate through agent networks |
Consequence chain: Without handshake and downgrade protection governance, inter-agent communications are vulnerable to man-in-the-middle attacks that strip governance protections. A successful downgrade attack reduces the security and governance level of the entire interaction, not just one message. In a settlement scenario, this can result in unsigned transactions being accepted as valid, with settlement finality disputes that may be irresolvable. In a data exchange scenario, mandatory protections (encryption, redaction, audit logging) can be silently removed, creating regulatory exposure for both parties. The blast radius is cross-organisational because the handshake is a bilateral mechanism — failure on one side affects both parties. In agent networks where messages are relayed through intermediaries, a single compromised handshake can propagate reduced governance levels across the entire chain. Regulatory consequence includes FCA enforcement for inadequate communication controls, GDPR exposure for PII exchanged without mandated protections, and DORA enforcement for ICT communication failures.
Cross-references: This dimension is closely related to AG-174 (Capability Profile and Dynamic Applicability Governance) which provides the capability profiles exchanged during the handshake; AG-176 (Signed Capability Manifest and Agent Card Authenticity Governance) which provides the cryptographic assurance for capability claims made during negotiation; AG-080 (Inter-Agent Trust and Attestation) which provides the trust framework verified during the handshake; AG-012 (Agent Identity Assurance) which provides the identity verification underpinning both parties' identities; and AG-015 (Organisational Namespace Isolation) which governs the namespace boundaries that the handshake must respect.