Start Free Trial
← Back to Blog

Routing Isn't Governing: A Field Note from Building AutoPIL

A gateway routes. It doesn't govern — I made that argument in the abstract a few weeks ago. agentgateway is where we built the concrete version of it first. It won't be the only one.

I wrote a post a few weeks ago arguing that a gateway's job — enterprise API gateway or AI-native LLM proxy, either kind — is to move a request from one place to another correctly, quickly, and observably, and that's a different job from deciding whether the request should have been allowed. It was an abstract argument on purpose, because it was true of the whole category, not any one vendor in it. This is the part where we had to go build the concrete version and find out if the argument actually held up against a real integration, not just a slide.

Where it held up first: agentgateway

agentgateway — the Linux Foundation-hosted, Solo.io-built proxy for MCP, A2A, and LLM traffic — has quietly become the connectivity layer a growing share of agent teams reach for by default. It does what a proxy should: routing, failover, budget controls, a CEL-based policy engine for auth and rate limits. What it doesn't do is enforce data-access policy or produce a tamper-evident record of what an agent actually touched — its own guardrails feature explicitly hands content-safety checks off to someone else. That's not a shortcoming in agentgateway's design. It's the shape of the whole category, exactly as argued. Every team that standardizes on it still has an open governance question sitting precisely where their agent traffic already flows.

Why agentgateway first, and not last

Every AutoPIL integration path up to now has asked something of the customer: add an SDK guard, install a gateway plugin, stand up a sidecar. Sitting behind agentgateway is a different shape of ask, because agentgateway is already the front door for a fast-growing share of MCP deployments — we're not asking a team to adopt a new checkpoint, we're governing the one they already built. That's the reason it went first, not the reason it's the only one. The same pattern — sit behind the AI-native gateway a team already runs instead of asking them to add another one — extends to every proxy in this category, agentgateway included but not exclusive to it. Which one comes next is mostly a question of which teams we're talking to, not a limitation in the approach.

Why now

The EU AI Act's high-risk enforcement window opens in weeks, not quarters. Teams already running an AI-native gateway don't have time to re-architect their agent stack for compliance before then — they need governance to show up where their traffic already is, not somewhere new.

We built our own reference deployment before pitching anyone else's: AutoPIL's SaaS platform now runs agentgateway as a supervised sidecar in front of itself, config and lifecycle managed from inside AutoPIL. That's a harder bar to clear than a slide, and it's the one that actually matters the next time a security review asks how we know what touched the data.

Same argument as the gateway post, just no longer abstract: the more of these proxies multiply across teams, the more it matters to have exactly one governance layer that sits behind all of them the same way, instead of a different answer for every gateway a team happened to pick.


Anil Solleti is the founder of AutoPIL, a governance-first agentic AI platform for regulated enterprises, and a partner at VibrantCapital.ai.

See governance in action

AutoPIL enforces policy at the retrieval layer — before sensitive data enters the agent's context window — and produces a tamper-evident audit trail of every decision.

Start Free Trial