Agentgateway Brings LLM, MCP and A2A Traffic Into a Single Open-Source Proxy

Ivan, a systems architect at RED Security, has published a breakdown on Habr of Agentgateway, an open-source gateway that can handle three types of AI traffic at once: requests to language models, tool calls over MCP, and agents talking to each other over A2A. Anyone who has watched AI sprawl across a company will recognize the idea: instead of a dozen direct connections with keys in code and no shared log, you get one managed control point.

A caveat: only the announcement of the article is available in the feed, and the full text is on Habr. So what follows is context drawn from the project's public documentation, not a retelling of the details of the author's analysis.

What problem does the gateway solve?

When teams connect LLMs one at a time, everything looks harmless. One service calls OpenAI, another calls Anthropic, a third calls Gemini. Then agents appear that call internal APIs through MCP servers, and call each other. Every connection has its own keys, its own limits and its own logs. Or none at all.

It is common for a security officer to ask what data left the company last week and for nobody to have an answer. A gateway solves this architecturally: all traffic passes through the proxy, and the rules are defined in one place. For a company with certifications and regulatory requirements, this is not a convenience but a precondition for running AI in production.

What we know about the project itself

Agentgateway was created by Solo.io, and the project was later handed over to the Linux Foundation. That matters for anyone worried about vendor lock-in: the code is open, and governance extends beyond a single company. The core is written in Rust, which usually means low memory use and predictable latency on the hot path.

Key features, according to the documentation:

• three types of traffic in one proxy: LLM requests, MCP, A2A;
• routing to multiple model providers, including cloud platforms and OpenAI-compatible APIs;
• authorization and access policies, including ones based on JWT and CEL expressions;
• rate limits and usage accounting tied to tokens, not just the number of requests;
• guardrail filters for prompts and responses;
• metrics and tracing via OpenTelemetry;
• integration with the Kubernetes Gateway API and a built-in interface for debugging.

Where's the catch?

The gateway becomes a single point of failure and a single point of attack. It needs redundancy, updates and monitoring as strict as those for an external load balancer. Second, the MCP and A2A protocols are young, their specifications are still changing, and compatibility will have to be tested on real servers and agents, not on a demo stand.

There is also an organizational risk. If teams keep going to models directly with personal keys and bypass the gateway, centralization remains on paper. Technically, this is fixed with network policies and by issuing keys only to the gateway, but that is an infrastructure-level decision, not something a single project can handle.

Where to start with adoption

A practical path looks like this. First, bring up the gateway in a test environment and route one non-critical LLM-backed service through it. Compare latency and make sure the logs contain what an audit needs. Then move provider keys out of applications and into the gateway configuration, and cut off direct internet access for services that call models.

Next, define policies for MCP tools. Start with deny by default and allow only the tools an agent actually needs. Finally, set token limits for each team, so AI spending stops being a surprise at the end of the month. For configuration details and examples, see the author's original article on Habr and the project's documentation.