← All posts

July 15, 2026 · Nick Krykunov

Do you need an AI gateway to secure agents? (the no-proxy alternative)

An AI gateway is a central layer that every agent request passes through on its way to a model or a tool. Because all the traffic flows through one point, you can log it, inspect it, and enforce policies on what agents are allowed to do. It’s a real pattern with real benefits, but it’s a proxy, and for most small teams the answer is no: the proxy is more than the problem needs.

What an AI gateway gives you

The appeal is central control. When every agent call goes through one layer, you get one place to log prompts and tool calls, one place to enforce “this agent can read from S3 but not write to production,” and one place to block a known-bad pattern. For a large org with a platform team, that centralization is worth the cost.

The cost of a gateway

A gateway is a proxy, and proxies carry the same three costs wherever they show up. It’s a single point of failure: if the gateway is down, your agents can’t work, and now a security layer is also an availability risk. It adds latency to every call, because everything makes an extra hop. And it only sees what routes through it, so unless you enforce it as the only way out, anything an agent does around it is invisible to it.

There’s also the setup. Standing up and maintaining a gateway that every agent must use is real infrastructure work, the kind of thing that assumes a team you may not have. This is the same tradeoff that makes proxy-based access tools heavy for small teams.

The no-proxy alternative

You don’t have to sit in the path to catch a bad agent. The other option is to watch from the side: observe what agent sessions actually do inside your own cloud account, and step in when one turns destructive.

Nothing routes through you, so there’s no single point of failure and no latency tax on every call. Your agents keep working the way they already do. The tradeoff is that watching from the side reacts to a destructive action rather than blocking a request before it’s sent, which is why it pairs best with scoped, expiring access that limits what a session can reach in the first place. Narrow what an agent can touch, then watch what it does with it.

Where Korvalis fits

Korvalis is the no-proxy version. It installs inside your own cloud account, watches live sessions including agent sessions, and cuts off a destructive one before the command finishes, whether it comes from an engineer, a stolen key, a contractor, or an AI agent. There’s no gateway for your agents to route through and nothing new in their critical path. It pairs access that expires on its own with real-time monitoring of what the session does, which is most of what a gateway is bought for, without the proxy.

Frequently asked questions

What is an AI gateway? A central layer every agent request passes through, so you can log, inspect, and enforce policy on agent traffic in one place.

Do you need one? Not necessarily. It gives central control but it’s a proxy, with the adoption friction, single point of failure, and latency that come with one. A small team can watch sessions from the side instead.

What’s the downside? It’s infrastructure in the critical path. If it’s down, agents can’t work, it adds latency, and it only sees traffic that routes through it.

If you’d rather secure agents without a proxy, see how Korvalis works or join the waitlist.