agentgateway: Open Source Proxy for MCP, A2A and LLMs

What agentgateway is

Agentgateway is an open source proxy built for AI-native protocols, the Model Context Protocol (MCP) and Agent-to-Agent (A2A), that adds security, observability and governance to agent-to-LLM, agent-to-tool and agent-to-agent traffic. The documentation describes it as an AI-first, cloud-native gateway control plane and proxy data plane. It is written in Rust, licensed under Apache-2.0, was donated to the Linux Foundation in 2025 and, per its docs, was accepted as an Agentic AI Foundation (AAIF) project in 2026.

The problem it targets is the gap between what MCP and A2A specify and what production systems need. The protocols define how an agent describes a task, calls a tool or hands work to another agent, but the docs point out that they do not address authentication, authorization and auditing of those interactions, policy enforcement across autonomous workflows, visibility into what agents are doing, or latency, retries and failure handling at scale.

Agentgateway is also a general-purpose HTTP and gRPC data plane with load balancing, timeouts, retries, TLS, rate limits and authorization, so the same proxy can front ordinary APIs and microservices alongside LLM, MCP and A2A traffic. The stated aim is that teams do not need to operate separate "regular" and "AI" gateways.

How it works

The docs argue that traditional API gateways and reverse proxies, Envoy among them, were optimised for short-lived RESTful requests with no session state. MCP is different: a stateful JSON-RPC protocol in which clients and servers keep long-lived sessions, servers can send messages back asynchronously, and a single client request such as listing tools may require the proxy to query several backend MCP servers, merge their answers and filter the result according to what that particular client is allowed to see. Agentgateway is built around that session- and message-aware model.

There are two deployment modes. Standalone is the agentgateway binary driven by a flat YAML configuration file; it runs anywhere, can be installed as a binary, a Docker container or a single-Deployment Helm chart, and ships a UI that can edit the configuration. Kubernetes mode installs a control plane with two Helm charts (CRDs and controller) and is configured through agentgateway custom resources and the Kubernetes Gateway API, with a read-only UI; the docs aim it at teams already running GitOps-driven Kubernetes infrastructure. Both modes come with the agctl CLI.

In standalone mode the proxy watches its configuration file and reloads it on change, so routes and policies can be edited without a restart. Configuration can also be updated over an xDS interface without downtime. An optional database, SQLite by default in the generated configuration, powers the UI's Analytics and Logs pages and features such as API key budgets.

Key features

• LLM gateway: routes requests to providers including OpenAI, Anthropic, Gemini and Amazon Bedrock behind a unified OpenAI-compatible API, with budget and spend controls, prompt enrichment, load balancing and failover. The LLM quickstart lists many more providers, from Azure and Vertex AI to Groq, DeepSeek and local Ollama models.
• MCP gateway: connects LLMs to tools via MCP with tool federation across multiple servers, stdio, HTTP, SSE and Streamable HTTP transports, OpenAPI integration so existing REST APIs become agent-native tools, and OAuth authentication.
• A2A gateway: secures agent-to-agent communication with capability discovery, modality negotiation and task collaboration.
• Inference routing: routes to self-hosted models using Kubernetes Inference Gateway extensions, with decisions based on GPU utilisation, KV cache, LoRA adapters and queue depth.
• Guardrails: layered content filtering with regex rules, OpenAI moderation, AWS Bedrock Guardrails, Google Model Armor and custom webhooks.
• Security: JWT, API key and OAuth authentication, fine-grained RBAC with a CEL policy engine, external authorization, local and remote rate limiting, CORS and backend TLS.
• Resiliency policies: request mirroring, timeouts and retries with backoff and configurable retryable status codes.
• Observability: OpenTelemetry metrics, logs and tracing for MCP client and backend tool interactions.
• Gateway API conformance: in Kubernetes mode it acts as a Gateway API implementation.

Getting started

The standalone install script downloads the latest release binary and verifies its checksum:

curl -sL https://agentgateway.dev/install | bash

A specific version can be pinned with --version, and the installation can be checked with:

agentgateway --version

Running the binary with no arguments starts the proxy with a generated configuration:

agentgateway

The generated config.yaml is written to $XDG_CONFIG_HOME/agentgateway or ~/.config/agentgateway, defines a default gateway on port 4000, attaches the UI to it and points at a SQLite database in the same directory. Agentgateway never overwrites an existing file, so later runs reuse it. The UI is then served at http://localhost:4000/ui. To run your own configuration instead:

agentgateway -f config.yaml

A file without a ui section serves the UI only on the admin interface at http://localhost:15000/ui, reachable from the local host only, and a supplied file gets no database unless config.database is added by hand. The LLM quickstart then has you export a provider credential before adding a route, for example:

export OPENAI_API_KEY='<your-api-key>'

Separate quickstarts cover MCP servers, including a playground for trying tools, and plain non-agentic HTTP backends. Kubernetes users start from the Kubernetes quickstart, which deploys the built-in controller with the Gateway API.

Use cases

• Central LLM access for a team: give every application one OpenAI-compatible endpoint while the gateway holds provider keys, enforces budgets and fails over between providers.
• MCP server sprawl: federate many MCP servers behind a single endpoint and expose only the tools each client is authorised to use.
• Securing agent tool calls: put JWT or OAuth authentication and CEL-based RBAC in front of MCP tools, with guardrails filtering prompts and responses.
• Turning REST APIs into tools: use the OpenAPI integration to expose existing services to agents without writing MCP servers.
• Self-hosted inference: route requests across model servers in Kubernetes based on GPU utilisation, KV cache and queue depth.
• One gateway for all traffic: serve ordinary HTTP and gRPC APIs from the same proxy as agent traffic.

How it compares

The project frames itself mainly against traditional API gateways and reverse proxies such as Envoy, which its docs say lack the session and message awareness MCP and A2A require and can be overwhelmed by long-lived, fan-out communication patterns. The team's blog has also published benchmarks against LiteLLM, another LLM gateway; those are the project's own measurements and worth reproducing on your own workload before relying on them. The docs separate agentgateway from kagent, a related project: agentgateway governs communication between agents, tools and LLMs that already exist, while kagent is for building and running MCP servers and agents in Kubernetes. Compared with LLM-only proxies, the distinguishing point is the single data plane that covers LLM, MCP, A2A and ordinary HTTP/gRPC traffic.

Things to know before adopting

• Young and fast-moving: the repository was created in March 2025, v1.0.0 shipped in March 2026, and v1.6.0 and v1.7.0 landed less than four weeks apart in October 2026; the README says the project is in active development.
• Versioned docs: standalone and Kubernetes docs are maintained per minor version, so check that the page matches the release you run.
• Two modes, different UIs: the standalone UI can edit configuration, while the Kubernetes UI is read-only and configuration lives in custom resources.
• Install script: the quick install pipes a remote script into bash and may prompt for a password to write to /usr/local/bin; manual downloads from GitHub releases are the alternative.
• UI exposure: the generated configuration serves the UI on the gateway port; the docs have dedicated pages on securing and exposing it.
• Commercial edition: Solo.io sells Solo Enterprise for agentgateway, built on the open source project.
• Licence: Apache-2.0; vulnerabilities are reported privately through GitHub security advisories.

Project activity

As of October 2026 the repository has about 5,800 stars and 1,030 forks. It was created in March 2025, is written in Rust and is licensed under Apache-2.0. v1.7.0 was released on October 27, 2026, after v1.7.0-rc.1 and v1.6.0 on October 2. The project is governed under the Linux Foundation, publishes changelogs in its GitHub releases, tracks work in milestones and holds weekly community meetings. Source is at github.com/agentgateway/agentgateway and documentation at agentgateway.dev.