Agent Communication Protocols: The Infrastructure Shift Reshaping Enterprise Security

I spent years building NetScaler at Citrix and participating in IETF protocol standardization. After 18 months building AI products at OutSystems, I'm seeing the same infrastructure transition pattern I watched with TCP to HTTP/2 and plaintext to TLS—but compressed from 5-7 years to 18 months.

I recognize this pattern from NetScaler during the TLS transition. Companies that waited to see "if TLS would really win" spent 2013-2015 in emergency migration mode while early adopters had 5 years of competitive advantage. The difference? Early adopters saw protocol convergence happening in IETF meetings 18 months before it became obvious in the market. I'm seeing that same convergence now with agent protocols.

Over the next 7 weeks, I'll break down the infrastructure buildout required for agentic applications. This is Week 1: Agent Communication Protocols.

The Protocol Landscape

April 2025: Google launches A2A (Agent-to-Agent Protocol). June 2025: Linux Foundation adopts A2A with AWS, Microsoft, Cisco, Salesforce, SAP, and ServiceNow.

Note on Governance: The immediate transfer of A2A to the Linux Foundation is critical. It signals that this isn't a "Google proprietary toy" (like AMP) but a neutral industry standard, following the Kubernetes adoption pattern.

Two protocols are emerging: MCP (Model Context Protocol) by Anthropic for agent-to-tool communication, and A2A for agent-to-agent communication. Both use Agent Cards—metadata defining what an agent can do, not just which endpoints it can call.

Why not just use REST and OpenAPI? You might ask: Aren't Agents just REST clients? Why do we need a new layer? For deterministic workflows, REST is fine. If an agent simply needs to GET /invoice/123, standard OpenAPI works. But Agentic workflows are probabilistic and negotiated. Before an agent acts, it must negotiate context ("Do you have the 'Finance' capability?", "What schema version are you using?"). Doing this over stateless REST requires dozens of round-trips. MCP and A2A compress this into a stateful, persistent session, managing the ambiguity that standard REST descriptors cannot handle.

Three Predictions

Prediction 1: MCP and A2A converge into a unified standard within 18 months. The Velocity Factor: A typical IETF standard takes 5-7 years. I am predicting 18 months not because bureaucracy has accelerated, but because capital pressure forces de facto standards. Just as the market adopted SPDY (working code) before it became HTTP/2 (standard), the trillions of dollars flowing into Agentic AI will force companies to bypass committees and ship working protocols. We are in a "Ship first, Standardize later" cycle.

Prediction 2: WIMSE (IETF working group) standardizes Identity. Within 18 months:

• Intra-organization agents use SPIFFE X.509-SVID for service mesh mTLS.
• Cross-organization federation uses WIMSE tokens (SPIFFE-compatible JWTs).
• The Shift: We are moving from Static Keys (API Keys pasted in secrets managers) to Dynamic Attestation. We won't trust the whole partner domain, but we will trust specific, attested exchange tokens signed by a mutually trusted 3rd party.

Prediction 3: When protocols adopt QUIC, current egress gateways go blind. QUIC provides 0-RTT connection resumption and connection migration. Most egress gateways block QUIC entirely. Those that inspect it require enterprise TLS certificates on all agents—breaking cross-organizational federation.

The Critical Problem: Egress Gateway Obsolescence

Think of current egress gateways as airport security that can only check if you have a passport—they can't tell if you're carrying approved cargo. Agent Cards are like detailed manifest declarations, but current gateways can't read them.

The Silent Killer: Connection Migration The issue isn't just encryption; it's Identity. In a QUIC world, a session is defined by a Connection ID, not an IP address. This renders IP-based allowlisting obsolete. If your security relies on the 5-tuple (Source IP, Dest IP, Port), you are blind to agents roaming across K8s pods or networks.

The Security Paradox: Dumb Pipes vs. Smart Gateways Security purists often prefer "dumb pipes" (TLS pass-through) to minimize attack surface. However, in an agentic world, blindness is the greater risk. If you cannot read the Agent Card, you cannot enforce: "Internal Agent A can delegate to External Partner B, but CANNOT authorize spend >$500." You are left with a binary choice: Block everything (stifling innovation) or Allow everything (unacceptable risk). We are trading the simplicity of the dumb pipe for the granularity of the smart gateway.

What current egress gateways can't do:

• Parse Agent Cards to validate capabilities at the protocol layer.
• Enforce multi-step delegation chains across organizations.
• Verify cryptographic attestation of agent identity (WIMSE) before allowing external calls.

Two-Track Architecture

Track 1 (Bridge): Run agent traffic through current HTTP-based egress gateways. Validates use cases, handles simple policies (single agent, single destination) for 12-18 months.

• Limitation: Must downgrade to TCP; cannot support high-frequency negotiation loops.

Track 2 (Protocol-Native): Purpose-built egress gateways that parse Agent Cards, validate delegation chains, and enforce stateful policies.

• The "Buy vs. Build" Reality: Can you build this with NGINX and Lua scripts? Yes. But you will spend the next 18 months patching parsers for volatile specs. Protocol-native gateways offload the churn of this shifting layer so you can focus on agent logic.

Winners in protocol transitions position before markets make it obvious. When encryption moved from PGP to TLS, winners architected for protocol-native security early. Organizations that position now have 12-18 months of competitive advantage before this becomes table stakes.

What egress traffic patterns are you seeing in your infrastructure? Share your observations in comments.

This is Week 1 of a 7-part series: The Infrastructure Buildout for Agentic Applications.