Is an LLM gateway actually a control plane if agents can bypass it?

A lot of teams now have an LLM gateway somewhere in the stack. It routes model calls, centralizes credentials, adds logging, applies rate limits, maybe handles spend tracking. But there is a fairly fundamental architectural question: What happens when an agent simply doesn't use the gateway? For example: ┌──→ LLM Gateway ──→ Models Agent ──────────┤ ├──→ Direct provider API ├──→ Direct MCP/tool endpoint └──→ Other external egress At that point, the gateway is still doing its job, it's just no longer governing the agent. This distinction matters because traffic control and path control are different problems. My view is that a gateway should be treated as one component of agent governance, not the governance boundary itself. Tools like LiteLLM, Portkey and OpenRouter are useful at the gateway/proxy layer. But a proxy cannot enforce traffic that never reaches the proxy. The more interesting architecture is: Agent ↓ Agent Gateway ↓ LLM Gateway / Governed Tools ↓ Models + APIs + network/egress enforcement + identity + shadow discovery That is one area where I find Lyzr Open Controller interesting: the gateway is paired with egress enforcement and shadow discovery specifically to detect and close the bypass path, rather than assuming that routing traffic through a gateway automatically means the agent is governed. I think this is going to become a bigger issue as agent estates get more distributed across Kubernetes, cloud agent runtimes, MCP servers and internally hosted services. Curious how people are solving this in real production environments: If an agent has credentials + network access that let it call a model or tool directly, what actually prevents the bypass? Would be interested in hearing what has actually worked, rather than what the architecture diagram says should work.