娇色导航

Keith Shaw: Hi, everybody. Welcome to DEMO, the show where companies come in and show us their latest products and platforms. Today, I'm joined by Christian Posta. He is a VP and Global Field CTO at Solo.io. Welcome to the show, Christian.

Christian Posta: Thank you, Keith, for having me. Excited to be here. Keith: Yeah, Solo.io is the name of the company, right? You wouldn’t just say "Solo," would you?

Christian: Some people do. I've been here one of the longest—about six and a half years—and I say Solo.io. Keith: All right.

So tell us about the company, and then let us know what you're going to show us in the demo today. Christian: Yeah.

So what we work on is application-layer cloud networking. That translates into things like modern API gateways and service mesh. With all the hype—and now realities—around AI and AI agents, we’re working closely with our customers, and a lot of that happens on the network.

There are some big differences between how we talk to APIs versus how agents interact and communicate with AI models. We’re digging in headfirst with our customers. We’ve also released a handful of open-source projects that help solve agent communication patterns.

Keith: Okay, so within the enterprise, who is this mainly designed for? You mentioned the word "network." I'm assuming some of the network teams in the enterprise space—or is it more of a developer tool? Christian: Definitely network.

Definitely security. So far, the primary consumers have been platform engineering teams—and now AI platform teams. Keith: All right.

So what's the big problem you're solving for these companies? Why would someone be interested in watching this demo?

Christian: Whenever you put something on the network, you need it to be secure. You need those interactions to be observable. You probably have compliance and governance procedures to adhere to.

Especially in the world of AI—where things are not as deterministic as they are in the microservice and API world—you need to put guardrails and boundaries around what these systems can do.

If you look at the emerging protocols in the AI inferencing space—things like Model Context Protocol (MCP), or Agent-to-Agent (A2A)—they don't solve for security, observability, or guardrails. That’s where we come in: to bring AI agentic architectures to the enterprise and fill those gaps, because those protocols likely won’t.

Keith: So if a company didn't have something like what you're about to show, would they just be introducing new vulnerabilities as they develop more agentic AI? Or is it something else?

Christian: That's a big concern. A lot of leaders are saying, "Do AI, do AI!" But they’re also realizing—"Wait a minute. This introduces a lot of new security vulnerabilities we don’t fully understand yet." So yeah, companies need help.

Keith: All right, so let’s get into the demo. Show us what you’ve got. Christian: Right.

I’ll start with a high-level architecture of what an agentic system might look like. You might be building your own agents, or using off-the-shelf ones like copilots or coding agents. We have an open-source project called KAgent that allows you to build agents quickly on top of Kubernetes.

The important part is these agents communicate with AI models or LLMs, with other agents, and with backend APIs—called tools. But those protocols like MCP or A2A don’t natively provide security.

When you give an agent access to APIs and workflows inside your enterprise, you want authentication, fine-grained authorization, and auditability. You want to know the path the agent took. These things communicate over the network, and that’s why we built a new open-source project at Solo called Agent Gateway.

It understands MCP and A2A protocols and can enforce security, collect metrics, provide tracing, and more. So the demo I’m showing is about Agent Gateway. If we go to GitHub and look up Agent Gateway, you’ll see the project.

It’s built in Rust, which is important for performance and resource usage. The proxy is configured via a JSON file—or optionally using an XDS-type protocol, which I won't demo today.

With the JSON file, we can define a single endpoint that clients can connect to, which then routes to multiple backend MCP servers. Each of those servers can expose its own tools, and now you can apply governance and policy on top. Agent Gateway has a UI.

We can see the exposed listeners, the target MCP servers, and tools available. For example, you might see tools like Everything Echo or Everything Else Add. It’s helpful to visualize the tools available. Now, what if you have RESTful APIs and want to expose them over the MCP protocol?

Let’s take a look at OpenAPI. We’ll run the proxy in OpenAPI mode. If you check out the config, you’ll see we’re now proxying not just MCP servers, but an OpenAPI REST service as well.

When I refresh and look at our targets, we see that the Pet Store backend is a RESTful API—exposed to MCP clients, making it available in agents or LLMs. When we connect to the playground, we can see both the Everything Server tools and Pet Store tools.

If I call something via MCP, Agent Gateway performs the transformation between MCP and REST automatically. Lastly, let’s look at authentication, authorization, and policies around MCP. The JSON file specifies that a JWT token must be included in the HTTP request.

The policy says: “Yes, you can access this, but only the Echo tool.” So if I try to connect without the token—no luck. I’ll go find the right token (hopefully it's in the README). Got it. I’ll paste that in, connect… and we’re in.

Now, remember—our policy only allows the Echo service. If I try to use the Add tool (say, 1 + 2), nothing happens, because I’m not authorized. But if I call the Echo tool—say “Hello, Agent Gateway”—it works successfully. Agent Gateway is just one piece of the agentic puzzle.

It enforces security, observability, and guardrails between agents and LLMs, between agents and other agents, and between agents and backend MCP tools. We also include a registration portal for governance—approval workflows, agent registration, and tool management.

This is what we’re calling Agent Mesh, and I believe Solo.io is leading the cloud-native community in building these tools.

Keith: So when you're adding all these Agent Gateways, is that going to slow down transactions? Or is it still relatively fast for companies to adopt this without adding latency?

Christian: That’s a great question. It’s actually why we built Agent Gateway in Rust. Rust is a high-performance, resource-efficient language. At the end of the day, you should think of agents as smart workflow engines. Workflows take steps, they involve interaction and feedback.

They're not like high-frequency trading systems—you're not talking nanoseconds here. Still, performance matters, and that’s why we built it in Rust. Keith: Okay.

How can people get more information? Is there a free trial? Or can people just start playing around with this?

Christian: The tools I mentioned—KAgent, Agent Gateway—are open source. KGateway, which I didn’t mention earlier, is the umbrella project for our gateway tools and is also CNCF-related. Agent Gateway is potentially going to be donated to CNCF too. Visit Solo.io to work with us or partner on these tools.

But yeah—go check them out! Keith: Very cool.

Christian Posta, thanks again for being on the show and for the demo. Christian: Thank you, Keith. Keith: That’s going to do it for this week’s episode of DEMO. Be sure to like the video, subscribe to the channel, and share your thoughts in the comments.

Join us every week for new episodes of DEMO. I’m Keith Shaw. Thanks for watching! ?