The Encryption Gap: AI Agent Security's Blind Spot — Skytale

In February 2026, Palo Alto Networks closed a $25 billion acquisition of CyberArk to "secure the AI era." The same month, NIST launched an AI Agent Standards Initiative focused on identity and authorization. The Cloud Security Alliance published an Agentic Trust Framework with five pillars for agent governance.

None of them address end-to-end encryption between AI agents.

This is not an oversight by uninformed people. It reflects a deliberate industry consensus: the immediate crisis is identity (who is this agent and what can it access?), not encryption (can anyone else read what agents are saying to each other?). That consensus is correct about priority order. It is wrong about how long encryption can wait.

The state of agent security in 2026

Enterprises are deploying AI agents at scale. Gartner projects 40% of enterprise applications will embed task-specific agents by year-end. The security infrastructure has not kept up.

The Gravitee State of AI Agent Security 2026 report surveyed 900+ executives and practitioners. The findings are stark:

• 45.6% of teams use shared API keys for agent-to-agent authentication
• Only 21.9% treat AI agents as independent, identity-bearing entities
• Only 47.1% of an organization's AI agents are actively monitored or secured
• 88% of organizations reported confirmed or suspected security incidents involving AI agents in the past year

Machine identities now outnumber human ones by ratios approaching 82 to 1 in some enterprises. Only 21% of executives report complete visibility into agent permissions, tool usage, or data access patterns.

These numbers explain why identity dominates the conversation. When nearly half your agents authenticate with shared keys and most aren't monitored at all, figuring out who is doing what takes priority. The identity vendors are solving a real, urgent problem.

But there is a second problem nobody is measuring.

What "encrypted" actually means today

Every major agent protocol — Google's A2A, Anthropic's MCP, IBM's ACP — communicates over HTTPS. Vendors describe these connections as "encrypted." They are, in a specific and limited sense.

TLS (Transport Layer Security) encrypts the connection between two endpoints. It prevents a network eavesdropper from reading traffic on the wire. This is necessary and important. It is also insufficient for multi-agent systems.

TLS protects the pipe. It does not protect the data.

When Agent A sends a message to Agent B through a cloud-hosted relay, MCP server, or orchestration platform, TLS encrypts the hop from A to the platform and from the platform to B. But at the platform layer — where the message is routed, logged, cached, or inspected — it exists as plaintext. The cloud provider, the orchestration framework, and any compromised middleware can read every byte.

This is not a theoretical concern. It is the documented architecture of every production multi-agent framework:

No major agent protocol or framework provides native end-to-end encryption. The platform provider can read everything in transit.

Why this matters now

Three converging forces are turning this gap from an academic concern into a production risk.

1. The attack surface is already being exploited

A timeline of MCP security breaches in 2025 alone shows the pattern:

• April 2025: A malicious MCP server used tool poisoning to exfiltrate WhatsApp chat histories. Messages were disguised as ordinary outbound messages, bypassing DLP tooling.
• May 2025: Prompt injection via the official GitHub MCP server leaked private repository contents — including salary information — to public pull requests.
• July 2025: A command-injection vulnerability in mcp-remote (437,000+ downloads, used by Cloudflare, Hugging Face, Auth0) allowed malicious MCP servers to execute arbitrary commands, exposing API keys, SSH keys, and cloud credentials.
• October 2025: A path-traversal vulnerability in Smithery exposed Docker credentials and a Fly.io API token controlling 3,000+ applications.

Security researchers have identified 8,000+ MCP servers exposed on the public internet, many with admin panels and API routes accessible without authentication. Plaintext HTTP endpoints expose OAuth tokens and credentials to interception.

In January 2026, the BodySnatcher vulnerability (CVE-2025-12420) in ServiceNow demonstrated "agentic amplification" — a broken authentication flaw that, combined with an autonomous AI agent's elevated privileges, allowed an attacker to impersonate any user, bypass MFA and SSO, and take full control of a customer's ServiceNow tenant using nothing but an email address.

These incidents share a common trait: the communication layer between agents and their tools provided no defense. If messages had been end-to-end encrypted, intercepted traffic would yield only ciphertext.

2. The compliance clock is ticking

The EU AI Act's high-risk provisions take effect in August 2026. Systems involving biometrics (computer vision), automated profiling (personalization), and safety-critical operations are classified as high-risk, requiring:

• Lifecycle risk management systems
• Technical documentation and logging
• "Appropriate levels of accuracy, robustness, and cybersecurity"
• Conformity assessments for providers

The Act does not explicitly mandate end-to-end encryption. But "appropriate cybersecurity" for high-risk AI systems processing personal data — under the combined weight of the AI Act, GDPR (Article 32), PCI DSS, and SOC 2 — increasingly means proving that sensitive data cannot be observed in transit by unauthorized parties, including infrastructure providers.

The CSA's Agentic Trust Framework — released the same month — applies Zero Trust principles to agents across five pillars: identity, behavior, data governance, segmentation, and incident response. Encryption of inter-agent communication is not among them.

NIST's February 2026 initiative focuses on identity today. But the accompanying concept paper explicitly acknowledges that agentic systems present unique challenges — "dynamic context acquisition, non-deterministic behavior, and permission escalation across tool chains" — that existing security models do not fully address. Communication-layer encryption is a natural next step once identity standards stabilize.

3. Encryption is getting harder to add later

Multi-agent architectures are being locked in now. LangGraph workflows, A2A integrations, MCP tool chains — these are production systems with established communication patterns. Retrofitting end-to-end encryption after the architecture is set requires changing every message producer and consumer. The longer the industry waits, the more expensive the migration becomes.

As the O'Reilly Radar analysis put it: "The protocol documentation focuses on encryption and handshakes but ignores the emergent failure modes of autonomous collaboration." The assumption is that TLS solves the problem. It does not, and the window to fix that assumption while architectures are still flexible is closing.

TLS vs. end-to-end: the technical difference

The distinction matters enough to be precise about it.

TLS establishes an encrypted channel between two parties for the duration of a connection. It is hop-by-hop: each intermediary (load balancer, API gateway, cloud platform) terminates TLS, decrypts the payload, processes it, and re-encrypts for the next hop. TLS provides confidentiality from network observers but not from infrastructure operators.

End-to-end encryption (E2E) encrypts the message at the sender and decrypts it only at the intended recipient. Intermediaries route ciphertext they cannot read. Even a compromised relay, cloud host, or orchestration platform sees only encrypted bytes.

For group communication — which is what multi-agent channels are — the Messaging Layer Security (MLS) protocol (RFC 9420) provides E2E encryption with two properties TLS lacks:

• Forward secrecy: Compromise of current key material cannot decrypt past messages. Even if an attacker obtains today's keys, yesterday's conversations remain protected.
• Post-compromise security: After a compromised member is removed and remaining members update their keys, the attacker loses access to future messages. The group "heals" cryptographically.

MLS achieves this through a binary tree key structure (TreeKEM) that scales logarithmically with group size — adding a member to a 1,000-agent group requires O(log 1,000) operations, not O(1,000). It was designed for exactly this kind of dynamic, large-scale group communication.

Critically, MLS is designed not to trust the transport. The MLS architecture document states that security guarantees "do not depend on the transport" because MLS is "designed to provide security even in the face of compromised network elements." This is the fundamental design departure from TLS-only approaches.

Why traditional vendors can't solve this

There is a structural reason the major cloud and security vendors have not built end-to-end encrypted agent communication: it conflicts with their business model.

Databricks, Google Cloud, Microsoft Azure, and AWS all provide value by processing customer data on their infrastructure. Observability, analytics, guardrails, content filtering — these services require the platform to see plaintext. A zero-knowledge architecture, where the infrastructure provider routes ciphertext it cannot decrypt, is incompatible with platform-mediated AI services.

This is not a criticism. Guardrails and observability are genuinely valuable. But they create a structural incentive against E2E encryption. When Databricks offers "secure" agent communication, it means secured-to-Databricks: the data is protected from external attackers, but Databricks itself can read everything. The same is true for every cloud-hosted orchestration platform.

The identity vendors (Palo Alto/CyberArk, Strata, Astrix) are not in a better position. Their tools control who agents are and what they can do. They do not — and are not designed to — encrypt what agents say to each other.

This is why the encryption layer needs to be independent of both the cloud platform and the identity provider. It is a different concern, solved at a different layer of the stack.

The identity-encryption complement

The framing of "identity vs. encryption" is misleading. They are not competing priorities. They are complementary layers that answer different questions:

You need both. Identity without encryption means you know who is talking but anyone with infrastructure access can listen. Encryption without identity means the conversation is private but you can't verify who is in it. A complete agent security posture requires answering both questions.

The industry has built robust tooling for the first question. The second question has no standard answer. OWASP's MCP Top 10 recommends mutual TLS, signed payloads, and anti-replay protections. The OWASP Top 10 for Agentic Applications lists Insecure Inter-Agent Communication (ASI07) as a top risk. Both stop short of recommending end-to-end encryption.

What comes next

The industry will solve identity first. That is the right sequence — you cannot encrypt communication between agents you cannot identify. But the encryption gap will not stay theoretical. As multi-agent deployments scale and handle increasingly sensitive data, three things will force the conversation:

• A breach attributed to plaintext agent traffic. The MCP breach timeline shows the trajectory. It is a matter of when, not if, an incident is traced to unencrypted inter-agent communication at a major enterprise.
• Regulatory specificity. The EU AI Act's "appropriate cybersecurity" language will be tested by enforcement actions. NIST's agent standards initiative will expand from identity to communication security. Regulators will ask: "Your AI agents exchange personal data — is it encrypted end-to-end?"
• Customer demand. As enterprises mature their agent security posture — moving from shared API keys to proper identity management — the next question is inevitable: "We know who our agents are. Now how do we prove nobody else can read their conversations?"

Early experiments are already underway. Projects layering MLS group encryption over gRPC for agent channels demonstrate that the technical path exists — the gap is adoption, not capability.

The organizations that add end-to-end encryption to their agent infrastructure now will have an easier migration path than those who wait for a compliance deadline or a breach to force the issue.

Further reading

• RFC 9420: The Messaging Layer Security (MLS) Protocol
• Gravitee: State of AI Agent Security 2026
• OWASP Top 10 for Agentic Applications 2026
• AuthZed: A Timeline of MCP Security Breaches
• O'Reilly Radar: AI, A2A, and the Governance Gap
• CSA: Agentic Trust Framework
• Encrypting OpenClaw Agent Channels After ClawJacked