API Evangelist Conversation with Christian Posta on AI Capabilities, Agent Security, and Building a Purpose-Built Gateway for the MCP Era

The way I look at capability is through the lens of accurately conveying to an AI model what a particular function or API can do. In the past, we documented APIs mostly for humans who would write services and applications to consume them — they’d read the docs, understand the data formats, contracts, and exchanges, then build accordingly. In the AI world, models themselves are making decisions about when to call external tools. So now we need to convey to the model not just what the API does, but when to call it, what it provides, and what examples look like. This context around what a tool or API offers forms the foundation of capability. It’s what helps an AI model make the right decision about which tool to invoke and when. Getting this right is what will make AI systems more reliable and accurate over time, and it’s why the conversation around capabilities has become so central to the API space right now.

Large language models take natural language and try to semantically understand what’s being said, predicting the right words to compose a meaningful response. If I say “what should I wear today,” I might also provide my schedule and weather data as tools the model can call. The model figures out it needs to check those tools to give a useful answer. What matters is that the capability description — what the model reads to decide whether and how to invoke a tool — is written in natural language, and natural language has a lot of nuance. You might describe a capability in a way that seems clear to humans but doesn’t give the model the right signals. And since this is natural language, it is also a prompt-injection surface: someone can sneak malicious instructions into your RAG data or tool descriptions and trick the model into doing something unintended. A natural language description of capability bridges the gap between what an API technically does and what an AI model needs to understand in order to use it correctly in context.

A capability clip is a short-form video that captures one focused insight about APIs, AI, and the intersection between them. Rather than watching a full-length interview, a capability clip distills a single concept — like what a gateway does, or how identity and access management fits into AI agents — into a concise, self-contained take. These clips are built from longer conversations but edited to stand alone. The idea is that the capability itself — the knowledge, the perspective, the practical insight — can be surfaced quickly for the people who need it without requiring them to sit through an entire recording. It’s a way of making expertise more accessible, more shareable, and easier to discover across the teams and communities working through these problems in real time. We are seeing a lot of important thinking happen in long-form conversations, and capability clips are a way to make sure that thinking reaches the people who need it most.

Applications have always needed authentication — you need to know which apps are talking to which, and which humans are invoking them. But in the AI agent world things get more interesting. You’re writing an application that leverages an AI model to make decisions about which steps to take to complete a goal. Unlike a microservice where you define exactly what happens when input arrives, an AI agent’s behavior is non-deterministic at runtime — the model decides. That makes identity critical. You need to know who the agent is, who invoked it, whether it was another agent or a human, and what that agent is allowed to do. We need causality — the full chain of who did what. Authentication and authorization, which were nice-to-have in the microservices world where teams often cut corners, are now mandatory. Without tight controls, agents can be manipulated through prompt injection, RAG poisoning, or malicious tool descriptions into doing things they absolutely should not — reading your file system, accessing banking data, leaking keys.

The role of the gateway remains very similar to what it was in the API world — offloading cross-cutting, non-differentiating concerns like security, observability, authentication, and authorization. What’s changing is how the gateway has to operate. Traditional API gateways were optimized for REST-style traffic — take an HTTP/2 request, evaluate headers, make routing decisions, forward to the backend as fast as possible. Very rarely did you need to inspect the body deeply. In the MCP and agent-to-agent world, the body is everything. MCP uses JSON-RPC, so almost nothing useful is in the headers — you have to unpack and parse the body to understand what’s happening. On top of that, MCP services are stateful and return session IDs that require sticky routing, which was a pattern REST APIs deliberately avoided. This is such a dramatic shift that Solo built Agent Gateway from scratch in Rust to handle these new realities properly, rather than trying to tweak Envoy and risk destabilizing a mature, stable project.

It’s going to have to be flexible — all of the above. When you look back at fifteen years of API gateways and API management, there was a lot of power consolidation in enterprises, similar to what happened with databases. I think the AI shift is going to shake that up again, but in ways we can’t fully predict yet. Agent Gateway was designed with maximum flexibility in mind. It can run as a traditional ingress gateway where requests come in from the outside. It can run as an egress gateway, especially for calling externally hosted LLMs. And written in Rust, it’s extremely performant and lightweight enough to handle internal east-west traffic as well. For LLM use cases we see more egress patterns; for MCP we see more east-west and ingress. We are still pretty early, and the right topology will emerge from practice rather than from design. Having a piece of technology that is extremely flexible was the most important thing — we want to adapt as the landscape settles.

We open sourced Agent Gateway in March 2025 and donated it to the Linux Foundation in August, in the same space as the Agent-to-Agent protocol, Agency, and a few others. It is fully open source and has gotten its own legs — a number of major players from the large cloud providers have jumped in. From a commercial standpoint, we announced an enterprise offering built on top of the open source core. The enterprise layer handles things the open source project intentionally does not — MCP authentication and authorization, cross-domain identity resolution for external MCP servers in different identity domains, and a registry and onboarding layer for MCP servers, agents, and LLMs. Critically, the gateway cross-references approved registrations at runtime. If someone configures an unapproved MCP server the gateway blocks it. And if an approved MCP server’s tool descriptions are changed after approval — one of the primary vectors for prompt injection — the gateway detects the fingerprint mismatch and can alert or block traffic according to policy.

The beauty of open source is that people bring use cases you would never dream of. Solo works with a certain segment of the market, but in open source you see so much more. The main ask is: if you’re connecting agents to MCP services, or connecting agents to LLMs, take a look at Agent Gateway. Whether you’re using Claude Code, VS Code, Chat GPT, or building your own custom agents — all of those need to talk to LLMs and MCP-style tools, and that’s exactly where Agent Gateway helps. You get observability, authentication, authorization, routing controls, rate limiting, and failover. These are the cross-cutting concerns you need in production. And the feedback loop with open source is invaluable — the use cases that come in from the community shape the roadmap in ways internal customer work cannot. So use it, push on it, and come back with what you find. That feedback is what makes an open source project actually matter.