Who Controls Your AI Agents? Jim Bugwadia on Policy as Code for AI Governance
You govern AI agents the same way Kubernetes governs workloads: write the rules as code, keep them outside the applications they apply to, and enforce them on every request, whether it’s an LLM, MCP or agent-to-agent call. That is the argument Nirmata CEO Jim Bugwadia makes on Techie Talks with Kuldeep.
Host Kuldeep Singh asks how AI changes policy and governance, why Kyverno is built on Kubernetes CRDs, and how to keep guardrails from slowing developers down. This post summarises Jim’s answers. The full interview is below.
Why does AI governance need policy as code?
Jim starts with the OODA loop, a decision model from US Air Force research by Colonel John Boyd: observe, orient, decide, act. Systems have followed those four steps for decades, but the loop keeps getting tighter. Kubernetes controllers codify it: they observe state, gather data, decide, and act.
Applied to AI, the lesson is that policy has to be decoupled from applications. “If every time you change a policy, you have to update all your applications, that whole loop becomes very slow,” Jim says. Kuldeep gives an example: if a model must be disabled in one location, a rule embedded in application code can’t do it quickly. A rule held as policy can.
Jim describes governance as two layers:
| Layer | Job | Example |
|---|---|---|
| Enforcement | Deterministic allow, deny, mutate, generate | Kyverno |
| Decision | Observe, orient and decide before handing an action to enforcement | What Nirmata is building on top, first for infrastructure and now for AI |
What are the risks of AI in the enterprise?
Jim names four: privacy, data leakage, token cost, and productivity. He sees the last one as the biggest. When databases emerged, every developer had to learn to use them. LLMs are the same shift: developers now use them to write code and call them from their applications. Governance applies to both.
He defines governance plainly. Whenever several roles share a system, like developers, operators and security teams in Kubernetes, you agree on the rules of engagement: who can do what. Policy as code is those rules written down in a form a system can enforce.
How AIControls applies Kyverno to AI requests
Kubernetes has a well-defined admission pipeline for API requests. AIControls applies the same idea to the full lifecycle of an AI request, covering LLM requests, MCP requests and agent-to-agent (A2A) calls, using the same Kyverno engine. Jim walks through the phases:
| Phase | What happens |
|---|---|
| Pre-flight | Checks that decide how the request is handled |
| Mutate | Change the request before it goes out, for example to apply a budget |
| Validate | Allow or deny the request |
| Dispatch | Send the request on |
Because one engine covers Kubernetes admission, runtime checks and the AI protocol layer, Jim argues it can deliver zero trust for AI agents across all layers. The alternative is separate systems with separate reporting and separate exception management, “a nightmare and a big mess to manage.”
Does it add latency?
Some, Jim says, but typically microseconds. The bulk of an AI request’s time goes to the model, “which is where it rightly belongs.” The same techniques keep Kyverno fast in Kubernetes. A matching step selects only the policies that apply to a request. Since Kyverno moved to CEL, policies are compiled, sandboxed and cached in memory, with no interpretation or data fetching at evaluation time. Jim mentions meeting a KubeCon attendee running more than 1,000 policies, which still evaluate in microseconds to milliseconds.
Why Kyverno uses CRDs instead of a new language
When Kyverno started, Open Policy Agent had already proven policy as code. Users told the Kyverno team they liked the idea but found Rego hard to learn and hard to scale. So the team asked who the user is, and the answer was the Kubernetes admin. They already know the Kubernetes resource model, so Kyverno policies, exceptions and reports are all Kubernetes resources.
The same reasoning drove the move from JMESPath to CEL: Kubernetes itself standardised on CEL, so Kyverno did too. The learning curve stays short, and the engine got faster.
How to keep guardrails from blocking developers
“Doing nothing is very secure,” Jim says, but no business wants developers sitting idle. Developers understand why security matters; they put it off when it becomes a chore, like filing a ticket and waiting a week in the middle of their work.
His answer is self-service. Take a prompt that appears to contain a credit card or social security number. A naive guardrail blocks it. But the developer may be testing with fake data. A better system warns them, lets them vouch for the data and say why it is safe, and records that decision so security can review it later. Kyverno already handles policy exceptions as reviewable resources, and Jim describes bringing the same self-service model to AIControls.
Rapid fire
| Question | Jim’s answer |
|---|---|
| One language for the next five years | Go: powerful and flexible, and designed for teams |
| Most common Kyverno mistake in production | Trusting the defaults. They are for getting started; tune resource limits, turn off features you don’t need, and monitor it like any critical controller |
| An emerging CNCF-space project to watch | Agent Substrate. With agents, the unit of work is a conversation, not a pod. It multiplexes requests from many users as actors on executor pods, for high-density agent infrastructure |
Watch the interview
Where to go next
Jim’s closing advice: governance and policy as code can look daunting, but they exist to make developers and platform teams more productive. To try the open-source engine, start with Kyverno. For AI agents and coding assistants, see AIControls or the AIControls launch post. For more on enforcing policy outside Kubernetes admission, read governance beyond the admission webhook, and for agent sandboxes, our OpenShell guide for platform engineers.
Frequently asked questions
How do you govern AI agents with policy as code?
Write the rules of engagement as code, keep them outside the applications and agents they govern, and enforce them on every request: LLM calls, MCP tool calls and agent-to-agent calls. Jim Bugwadia describes two layers: a deterministic enforcement layer such as Kyverno, and a decision layer above it that observes, orients and decides before enforcement acts.
Why decouple policy from application code?
If every policy change requires a change to every application, the loop from new rule to enforced rule is too slow. A policy kept separately can be changed, tested and rolled out on its own, for example disabling a model in one region, without redeploying the applications that call it.
Does adding AI governance slow down agent requests?
According to Jim, policy execution adds microseconds, or a few milliseconds at most. Policies are compiled CEL expressions held in memory, and a matching step picks only the policies that apply to each request. Almost all of an AI request's time is spent in the model itself.
How do you stop AI guardrails from blocking developers?
Make policies readable by developers, and give them self-service exceptions. If a prompt looks like it contains a credit card number but the developer is testing with fake data, the system can warn and let them vouch for it, recording the decision so security can review it later instead of blocking the work.
What is the most common Kyverno mistake in production?
Assuming the defaults fit every environment. The defaults are tuned for getting started, not for scale. Kyverno's resource limits, enabled features and policies should be tuned and monitored like any other critical Kubernetes controller.