Govern the Request, Not Just the Model

What we heard from teams already using AI gateways — and what it still didn’t answer.

Talking to platform and engineering teams putting AI into production, we kept hearing the same three questions — and the AI gateways they’d looked at answered none of them:

• Who just made that call — which developer, which team, which agent?
• What did it actually do — which tools did it touch, against which systems?
• Did any of it produce something worth the spend?

The stories behind those questions were specific. A team in a regulated industry needed to prove which model had handled sensitive data — with real deadlines attached, not a next-quarter aspiration. A large engineering org was hand-building a developer-productivity scoreboard in a spreadsheet because nothing tied AI spend to shipped work. A platform team already running Kyverno across their clusters asked why their AI agents were the one workload with no policy layer at all.

Model routing wasn’t the thing keeping these teams up at night. When it came up at all, it was table stakes. Routing governs one thing — which model handles a request — a real decision, and the narrowest one in the request path. It’s the floor of governance, not the ceiling, and none of the three questions above live at that layer.

That’s the gap we built AIControls to close.

What we heard, and what we shipped

Each question our users raised maps to something concrete in the product.

“Who made this call?” Routing sees an API key. Governance needs an identity. AIControls attributes every request to a named developer or service account via OIDC — Kubernetes SA tokens, Google, device flow — and applies the policy that belongs to them. Identity is the precondition for everything downstream: per-developer budgets, audit, attribution.

“What did the agent do?” A model call is the easy case. The call that matters is the MCP tool call that reaches production Postgres, deletes a branch, or moves money — and no routing decision governs that surface. AIControls does, with five decision modes: allow, audit, warn, deny, and require human approval. Here’s a gate that a routing table has no vocabulary for:

# Require human approval before any agent writes to production Postgres
match:
  - object.tool.name == "postgres.query"
    && object.tool.args.statement.matches("(?i)^(insert|update|delete|drop)")
    && object.tool.target.env == "production"
decision: RequireApproval

“Can I prove where regulated data went?” This one had the hardest deadline behind it. Jurisdiction is expressible as policy — but the team didn’t just need the request routed to a compliant model, they needed to prove it did, per request, tied to who asked. AIControls enforces the jurisdiction rule as a CEL policy and writes an identity-attributed audit record for every call. Not “which region did traffic go to,” but “which identity sent which request to which model, under which policy, at what time.” That’s the artifact an auditor actually wants.

“Why is my AI the only ungoverned workload?” For the teams already on Kyverno, this was the one that landed hardest. AIControls uses the same Kyverno CEL policy language that already governs their clusters, pipelines, and infrastructure — now extended to AI requests, tool calls, and model access. One policy language, from Kubernetes workloads to AI agents. Nothing new to learn, nothing new to adopt.

Here’s the shape of it, side by side:

One thing we learned the hard way

Early on, we assumed governance meant rewriting the request — swapping the model on the wire to the one policy preferred. It doesn’t, and here’s why we stopped.

The model ID is part of the prompt-cache key. Swap the model mid-session and you invalidate the cache — the single largest cost lever in AI infrastructure. You also sever attribution: once the wire no longer matches what the client asked for, your audit trail describes a request that never happened. You end up destroying the two things governance exists to protect, at the moment it acts.

So we built on a different principle — steer, don’t substitute. Influence the client’s own model selection through policy; never silently rewrite the model on the wire. Cache locality stays intact. The audit trail matches reality. Governance that corrupts its own evidence isn’t governance.

The layer this sits at

There’s a useful analogy going around: routing does for models what Kubernetes did for containers. We agree — and it’s worth finishing.

Kubernetes governance was never the scheduler. The scheduler decides where a pod lands. Governance — admission control, RBAC, policy — decides whether it’s allowed at all, by whom, and leaves a record. That’s the layer Kyverno owns, and it’s what made policy-as-code the standard for cloud-native security.

AIControls is the admission controller for AI. Routing is the scheduler. Both matter. They’re just different layers — and the teams asking us those three questions had used the scheduler already. What they needed was the layer above it.

The product is the outcome

Routing proves which model answered a request. Useful, sometimes necessary.

AIControls proves which developer, on which ticket, produced code that shipped and survived. Identity, to work item, to outcome — the line from a governance decision to a business result. That’s the conversation our users were trying to have, and it’s the one a routing table structurally can’t. We called it valuemaxxing over tokenmaxxing back in June, and it’s still the point: not cheaper tokens, provable value.

Routing is welcome. We drive routers ourselves, as one dimension among several — under a policy engine that sits above them all. But the product our users want is the governance of the request, the identity, and the outcome.

The gate belongs above the router. That’s where we built it.

AIControls is generally available today — not a preview, not a roadmap. See it. Check out the docs.

More on how we think about this: Understanding AI Governance and The Gate That’s Missing from Every AI Governance Stack.