This is the third in a three-part series on the AI Governance market. Part 1: Understanding AI Governance: A Market Map. Part 2: The Cloud Security Playbook for AI Governance.
Across the first two posts in this series, we mapped the AI governance market into three distinct problems and traced the consolidation arc from cloud security to show where things are headed. This post is about the specific layer that’s missing from almost every enterprise AI governance stack — and what happens when it isn’t there.
The Gap Nobody Is Talking About Honestly
Ask most enterprises what their AI governance strategy looks like and you’ll get a coherent answer. There’s a policy document. There’s an acceptable use framework. There’s a model risk committee. There’s a dashboard showing token consumption by team.
What you won’t find — in almost any enterprise running agents in production today — is something that actually stops a bad action before it executes.
The policy document tells people what they’re supposed to do. The dashboard tells you what already happened. The model risk committee reviews systems before they’re deployed. None of these things sit in the execution path of an AI agent making a decision right now.
That gap has a name. We call it the enforcement gap. According to Gravitee’s 2026 State of AI Agent Security report, which surveyed over 900 executives and practitioners, 88% of organizations confirmed or suspected AI agent security incidents in the past year. The same report found that only 21.9% of those organizations treat AI agents as independent, identity-bearing entities with their own access controls.
Deployment is outrunning governance by a wide margin. That’s the enforcement gap.
What Actually Goes Wrong
The scenarios that expose the enforcement gap aren’t exotic. They’re the predictable consequences of putting autonomous systems into production without controls in the execution path.
An agent with more access than it needs. A developer provisions a service account for an AI agent during a proof of concept. The account has broad database read permissions because it was easier to set up that way. The POC becomes a production deployment. Nobody revisits the permissions. The agent now has access to customer records it was never intended to touch — and uses them, because nothing in its execution path tells it not to.
A tool call that shouldn’t have been made. A coding agent is given access to internal systems via MCP. During a task, it identifies what looks like a relevant API endpoint and calls it — a production endpoint, not a development one. The call succeeds. Data is written. There was no policy check at the moment the tool call was made. The audit log captured it after the fact.
A budget that nobody set. An autonomous agent is tasked with a research workflow. It loops — a common failure mode when agents don’t have clear termination conditions. Each loop costs tokens. Nobody set a budget limit at the proxy layer. By the time someone notices, the agent has consumed $3,000 in a single session. The spend was visible in the provider console the next morning.
Prompt injection at the boundary. An agent ingests external content as part of its task — a document, a web page, an email. That content contains instructions designed to manipulate the agent’s behavior. There’s no content safety layer scanning inputs before they reach the model. The agent follows the injected instructions. In mid-2025, Microsoft Copilot was found to have exactly this vulnerability — infected emails could trigger autonomous data exfiltration with no user interaction required, earning a CVE with a 9.3 severity score.
What all four scenarios have in common: they could have been stopped at the moment of execution by a control that was in the critical path. Not a policy document. Not a morning report. Something that evaluated the action before it happened and made a decision — allow, deny, or hold for human review.
That’s what runtime enforcement means. And most enterprises don’t have it.
Why Dashboards Aren’t Enforcement
This distinction matters because the majority of AI governance vendors sell visibility, not enforcement.
Visibility is valuable. Knowing which agents are running, which models they’re calling, what they’re spending — that’s useful operational data. But visibility without enforcement is a post-mortem tool. It tells you what went wrong. It doesn’t prevent it.
The pattern we’ve seen in cloud security makes the same point. You can have perfect logging of every network packet and still get breached, because logging doesn’t stop the packet. You can have comprehensive vulnerability scanning and still get compromised, because scanning tells you about the risk after the code is deployed. The tools that actually prevented incidents in cloud security were the ones in the execution path — the runtime enforcement layer that evaluated actions as they happened.
The same logic applies to AI governance. A dashboard that shows an agent accessed a database it shouldn’t have is useful. A control that prevented the access in the first place is what you actually needed.
What Runtime Enforcement Requires
There’s a useful analogy from Kubernetes that makes this concrete.
Every request to the Kubernetes API server — whether it’s deploying a workload, creating a service, or modifying a configuration — passes through a chain of admission controllers before it’s admitted to the cluster. Those controllers evaluate the request against policy in real time. If the request violates policy, it’s denied before anything is created. If it needs modification, it’s mutated before it reaches the cluster. Nothing gets through without passing the gate.
Kyverno is an admission controller. That’s the architectural reason it works. It doesn’t analyze Kubernetes workloads after the fact — it intercepts them before they exist. Every bad configuration, every overpermissioned workload, every policy violation — stopped at the gate, not discovered in a post-incident review.
AI agents need the same pattern. Every action an agent takes — every tool call, every LLM request, every API access, every data read — needs to pass through an enforcement gate before it executes. Not a log that captures it afterward. A gate that evaluates it first.
Building that gate requires solving several problems simultaneously.
Identity at the agent level. You need to know which agent is making a request — not just which user, not just which service account, but which specific agent, running which task, on behalf of which human or system. Without verified agent identity, you can’t apply meaningful policy. You’re governing a category, not an actor. In Kubernetes terms, this is the equivalent of knowing not just which namespace a workload is in, but which specific deployment, which replica, which service account — and what it’s authorized to do.
Policy that lives in the execution path. The governance rules need to be evaluated at the moment the action is attempted — before the tool is called, before the token is spent, before the API request goes out. Policy that runs after the fact is audit, not enforcement. Kyverno enforces at admission time. AI enforcement needs to enforce at execution time.
Human-in-the-loop for high-stakes actions. Not everything should be a binary allow or deny. Some actions need human review before they proceed — a budget exception, an agent requesting access to a sensitive data source, a tool call to a production system during an unusual session. The enforcement gate needs to hold the action, route it for approval, and resume or deny based on the response. Kubernetes doesn’t have a concept of “hold for human review” because Kubernetes workloads don’t make autonomous decisions mid-task. AI agents do.
Immutable audit trail. Every decision the enforcement gate makes — allow, deny, hold — needs to be logged in a way that can’t be altered. Not for operational debugging, but for the compliance and legal questions that will follow any incident.
Content safety in the critical path. Inputs to AI agents need to be scanned — for PII, for data classification violations, for prompt injection — before they reach the model. This isn’t a separate security tool bolted on the side. It needs to be part of the enforcement gate, running on every request.
These five requirements share something in common: they all require being in the execution path. You can’t satisfy them from a dashboard. You can’t satisfy them with a policy document. You need a gate — infrastructure that sits between the agent and everything it can touch, and makes a decision on every action before it happens.
Why We Built AIControls
We’ve spent a decade building Kyverno — the policy engine that became the standard for Kubernetes governance. It’s now a graduated CNCF project with over 3.2 billion downloads. The reason it works is the reason we described above: Kyverno is an admission controller. It sits in the gate. Every resource request passes through it before it’s admitted to the cluster.
When we started seeing AI agents exhibit the same ungoverned behavior that Kubernetes workloads exhibited before Kyverno — overpermissioned, unattributed, invisible to the teams responsible for them — the problem was familiar. And the architecture of the solution was familiar too.
AIControls is the AI enforcement gateway. Think of it as the Kubernetes API server and Kyverno combined — but for AI agents. It sits in the execution path between your agents and everything they can access: LLMs, MCP tools, APIs, data sources. Every action passes through the gate. Every action is evaluated against policy. Every decision is logged. Every high-stakes action can be held for human review.
Specifically:
- MCP Policy Proxy sits in the path of every tool call an agent makes via MCP — evaluating, enforcing, and logging before the call goes to the downstream server
- Kyverno AuthZ applies the same policy-as-code model we built for Kubernetes to AI agent authorization decisions — policies live in Git, reviewed like any infrastructure change
- Human-in-the-loop holds agent actions that exceed policy thresholds and routes them for approval via Slack or other channels before proceeding
- Content safety scans every input for PII, data classification violations, and prompt injection using a pluggable layer that supports Presidio, LlamaGuard, and custom scanners
- Token budget enforcement applies hard limits at the proxy layer — by agent, by team, by task type — before the spend happens, not after
- Immutable audit trail logs every decision with full context — identity, model, cost, policy outcome — ready for SOC 2, PCI-DSS, and NIST CSF evidence requirements
Kubernetes needed an admission controller before it was safe to run production workloads at scale. AI agents need an enforcement gateway for the same reason. We built the admission controller for Kubernetes. We’ve built the enforcement gateway for AI.
Where We Are
AIControls is in early access. We’re working with a small number of enterprises who are moving AI agents from development into production and need the enforcement layer in place before they scale.
If you’re dealing with the enforcement gap — agents in production without runtime controls, AI spend with no attribution, tool calls with no policy — we’d like to talk.
Read the full series: Part 1 — Understanding AI Governance: A Market Map · Part 2 — The Cloud Security Playbook for AI Governance
