SLIM as a transport layer beneath A2A and MCP

--- title: "Most agent protocols ship on HTTP. SLIM bets the transport itself has to change." date: 2026-06-03 summary: "AGNTCY's SLIM protocol (IETF draft, February 24, 2026) sits below A2A and MCP as a transport layer. It adds publish-subscribe and MLS end-to-end encryption that survives intermediate hops. The bet is that agent networks need a transport HTTP plus TLS cannot provide." slug: slim-transport-agent-protocols author: "Sebastiaan Hilbers" hero_glyph: waveform --- The agent protocols this blog has been writing about all year ([MCP](https://agenstry.com/blog/mcp-spec-vs-probe-evidence), [A2A](https://agenstry.com/blog/a2a-signed-cards-key-not-identity), [AP2](https://agenstry.com/blog/agent-payments-stack-identity-gap)) ship over the same transport: HTTP with JSON-RPC, with TLS providing the encryption. That choice was almost invisible because it is the default for every web-shaped API anyone has built in the past two decades. [AGNTCY's SLIM protocol](https://docs.agntcy.org/messaging/slim-core/), with its [IETF draft published February 24, 2026](https://datatracker.ietf.org/doc/draft-mpsb-agntcy-slim/), bets that the default isn't enough at the agent-network scale the field is heading toward, and proposes a transport that sits one layer below the agent protocols themselves. SLIM stands for Secure Low-Latency Interactive Messaging. It is not an agent protocol. It is the layer A2A and MCP can run on top of if they want native publish-subscribe, end-to-end encryption that survives compromise, and forward secrecy at the message level rather than the transport level. The choice to add this layer at all is the argument worth understanding. ## Where SLIM sits in the stack The interesting layer is the middle one. SLIM accepts that A2A and MCP have done their work above it and that gRPC has done its work below it. What it adds is two specific things HTTP cannot offer natively: a publish-subscribe primitive for many-to-many communication, and end-to-end encryption via [Message Layer Security (MLS, RFC 9420)](https://datatracker.ietf.org/doc/rfc9420/) that survives intermediate hops. ## Why agent networks need pub/sub HTTP is fundamentally a request-response protocol. Even with HTTP/2 streaming and HTTP/3 multiplexing, the underlying mental model is "one client asks one server one thing, then they trade messages." That fits the architecture of [most MCP servers](https://agenstry.com/blog/mcp-discovery-fragmentation): an agent picks a server, calls a tool, gets a result. It fits less well when the topology is many agents talking to many agents. A coordination event ("the user just changed their goal," "a new piece of context just landed in the shared memory store") needs to reach every agent that subscribes to it. The HTTP equivalent is N agents polling N+1 endpoints, with all the latency and overhead that implies. The right shape is a single publish event that fans out to subscribers. That primitive doesn't exist in HTTP at the protocol level; SLIM puts it at the transport level. The other communication patterns SLIM names are familiar from message-queue infrastructure: fire-and-forget for high-frequency non-critical updates, reliable exactly-once delivery for critical coordination messages, request-reply for the conventional pattern. What's notable is that SLIM treats them as a single QoS spectrum rather than as separate protocols. An agent doesn't need to switch between gRPC and Kafka and a streaming API to get those semantics; it declares the QoS level it wants per message. ## Why MLS, specifically The encryption choice is the part most coverage understates because it doesn't visibly change anything. SLIM ships with [Message Layer Security](https://datatracker.ietf.org/doc/rfc9420/), an IETF standard published in 2023 for end-to-end encrypted group communication. The signal-protocol-style design family (used by Signal, WhatsApp, recent Matrix) built MLS to handle one specific property HTTP-with-TLS does not: encryption that survives across intermediaries. TLS protects an HTTP connection between two endpoints. If the message hops through three intermediaries (a gateway, a router, a relay), each one can read the message and re-encrypt for the next hop. MLS encrypts the message at the sender once and lets each authorized recipient decrypt it independently; intermediaries handle the ciphertext without the keys. The relevant property for the agent web is that a message sent through multiple agent-gateway hops remains opaque to those intermediaries. MLS also provides forward secrecy and post-compromise security through key rotation. If a long-running agent's signing key is compromised tomorrow, an attacker who logs today's encrypted traffic cannot decrypt it. If the same key is rotated next week, even messages sent after the original compromise become unreadable to the attacker. These properties are inherited by SLIM-delivered messages regardless of which application protocol (A2A, MCP, AP2) is encoded on top. This matters operationally for agent gateways like [Uber's MCP gateway](https://agenstry.com/blog/uber-1500-agents-gateway). A gateway architecture is, by design, an intermediary. A gateway that operates on plain TLS-over-HTTP can see every tool call its agents make. A gateway that brokers SLIM-encrypted traffic between end-to-end authenticated agents cannot, by construction. That's a useful property for trust separation across organizational boundaries — and it's the property AGNTCY's [Internet-of-Agents framing](https://agenstry.com/blog/agntcy-vs-aaif-foundation-bets) was structured around from the beginning. ## What SLIM does not do The transport layer is not where identity verification, agent card distribution, or conformance probing happen. Those concerns sit above SLIM, at the A2A/MCP layer and at the registry layer. A SLIM- delivered MCP tool call is not automatically a trusted tool call; the [signature on the agent card](https://agenstry.com/blog/a2a-signed-cards-key-not-identity) and the [behavioral probe](https://agenstry.com/blog/mcp-spec-vs-probe-evidence) are still the load-bearing claims about what the agent is and what it has been observed to do. SLIM provides confidentiality, ordering, delivery guarantees, and a pub/sub primitive. It does not provide trust. That separation is the right one for the same reason TCP did not specify HTTPS and HTTP did not specify TLS. The transport layer has enough work without owning the trust model. The trust model has enough work without owning the transport. ## What this means for the registry layer A registry that catalogs MCP servers today does not publish what transport the server speaks. The default assumption is HTTP-with-JSON-RPC. As SLIM adoption picks up (the [IETF draft progressing through review](https://datatracker.ietf.org/doc/draft-mpsb-agntcy-slim/) is the formal signal) the assumption stops holding. An MCP server running over SLIM has different security properties than an MCP server running over plain HTTP, even when the two expose the same tools and publish the same agent card. The registry-relevant signal that should appear in a card is the list of transports the server speaks (SLIM, HTTP/JSON-RPC, both), the encryption posture (MLS-end-to-end, TLS-only), and any gateway-traversal requirements. None of those are spec items today. All of them affect what a consumer can rely on when they connect. This is the same shape of registry work [we keep coming back to](https://agenstry.com/blog/agent-web-certificate-transparency): the card has to describe the trust properties the consumer needs to verify, and the transport is one of them. ## What we're watching Three things, observable in the next two quarters: 1. **Whether A2A's next revision adds a SLIM transport binding.** The [A2A specification](https://a2a-protocol.org/latest/specification/) already supports multiple protocol bindings. A specified SLIM binding would make agent-to-agent communication over the AGNTCY transport stack the explicit alternative to plain HTTP. The first agents shipping that binding will define the integration patterns for the rest. 2. **Whether MCP's transport list grows beyond stdio and HTTP.** The [STDIO architectural injection class](https://agenstry.com/blog/mcp-spec-vs-probe-evidence) that dominated this spring's security coverage is partly a transport-design problem; MCP currently offers stdio and HTTP and nothing else. A SLIM transport for MCP would provide both a pub/sub primitive and the MLS guarantees, which would change what "MCP server" can mean in production. 3. **Whether gateway operators adopt SLIM specifically for trust separation.** The technical property SLIM offers an operator like Uber is that the gateway cannot inspect content it brokers. That's a significant deployment shift; few large gateways today operate that way. The first one that publicly ships SLIM-end-to-end traffic between agents and external tools will be the test case that determines whether the property is actually load-bearing. The agent web has so far inherited HTTP because every other distributed system inherited HTTP. SLIM is the first specifically- designed transport layer for agent networks, and it ships with guarantees TLS cannot match. Whether it becomes the default or remains an alternative is the open question; the existence of the alternative is the part that's newly settled. ## Sources - [Secure Low-Latency Interactive Messaging (SLIM)](https://docs.agntcy.org/messaging/slim-core/) — AGNTCY Documentation, accessed May 2026. - [draft-mpsb-agntcy-slim-01](https://datatracker.ietf.org/doc/draft-mpsb-agntcy-slim/) — IETF Internet-Draft, February 24, 2026. - [agntcy/slim on GitHub](https://github.com/agntcy/slim) — SLIM source repository, accessed May 2026. - [agntcy/slim-spec on GitHub](https://github.com/agntcy/slim-spec) — SLIM Protocol Specification, accessed May 2026. - [Linux Foundation Welcomes the AGNTCY Project](https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-agntcy-project-to-standardize-open-multi-agent-system-infrastructure-and-break-down-ai-agent-silos) — Linux Foundation, July 29, 2025. - [RFC 9420: The Messaging Layer Security (MLS) Protocol](https://datatracker.ietf.org/doc/rfc9420/) — IETF, July 2023.