Picture this.
An AI agent with read access to your customer database. Deployed six months ago by a developer who has since moved to another team. Running quietly in the background, making hundreds of API calls a day.
Nobody remembers exactly what it’s allowed to do. Nobody has a record of who approved its permissions. Nobody can tell you what it accessed last Tuesday.
Your auditor calls on a Monday morning.
This isn’t a far-fetched scenario. It’s the default outcome when enterprises deploy AI agents without a governance layer. And right now, most enterprises are heading straight toward it.
Last week we wrote about why AI agent governance is the defining infrastructure challenge of the next three years. This week we want to get more concrete — what does good governance actually look like?
Start With the Right Mental Model
The instinct most security teams have is to treat AI agent governance as an AI problem. It isn’t.
It’s an identity and authorization problem with an AI agent on one end.
Every question that matters about a running AI agent is a question you already know how to ask about any privileged system in your environment:
- Who is this?
- What is it allowed to do?
- What did it actually do?
- Can I prove it?
The difference is that with AI agents, nobody has built the layer that answers those questions yet. That’s the governance gap we’re focused on at Nirmata — and it maps to four concrete problems every enterprise needs to solve.
Layer 1: Agent Identity
You can’t govern what you can’t identify.
Every AI agent in your environment needs a verifiable identity — not just a name in a spreadsheet, but a cryptographically verifiable identity that travels with every request the agent makes.
Without this, you have no way to distinguish one agent from another, no way to enforce agent-specific policies, and no way to build an audit trail that means anything. An agent without a verified identity is a privileged process running in your environment with no accountability attached to it.
| Good governance starts here. Before permissions. Before policies. Before anything else. |
Layer 2: Permissions
Once you know who the agent is, the next question is what it’s allowed to do.
This sounds obvious. In practice it’s where most enterprises are flying blind.
AI agents typically inherit permissions from the service accounts they run under. Service accounts are routinely over-provisioned — because it’s faster to give broad access than to scope permissions carefully. The result is agents with far more access than they need, approved by nobody, documented nowhere.
Good governance means defining agent permissions explicitly — what data can it access, what APIs can it call, what actions can it take — and enforcing those permissions at runtime, not just at deployment time.
The principle is the same one you’d apply to any privileged user in your environment: least privilege, explicitly approved, regularly reviewed.
Layer 3: Audit Trail
Your auditor’s question isn’t just “what is this agent allowed to do?”
It’s “what did it actually do — and when?”
Those are different questions. An agent can be configured correctly and still behave in ways that need explaining. Good governance means every action an agent takes is logged in a way that’s tamper-evident, queryable, and mappable to a compliance framework.
| Not logs that exist somewhere in a system nobody checks. An audit trail that you can hand to an auditor on a Monday morning and say: here is every action this agent took, here is the policy that authorized it, here is the timestamp. |
Layer 4: Policy Enforcement
Identity, permissions, and audit trail are only as good as the policy engine enforcing them.
This is where we think the Kubernetes governance model has something important to teach us. Kyverno — the policy engine we steward at Nirmata — governs what runs inside Kubernetes clusters using a consistent, declarative policy language that security teams can audit and developers can work with.
The same model applies to AI agents. A policy layer that defines what agents are allowed to do, enforces those policies at runtime, and generates audit evidence automatically — using the same language and the same control plane your team already knows.
One policy engine. From workloads to agents.
That’s the direction we’re building toward at Nirmata. Not because it’s the obvious next product. Because we watched enterprises spend years recovering from getting Kubernetes governance wrong, and we don’t want to watch the same thing happen with AI agents.
The Window Is Still Open
Most enterprises are still in the experimentation phase with AI agents. That’s actually good news.
The governance layer is far easier to build before agents go to production than after. The patterns are clear. The framework exists. The window to get this right — before the auditor calls on a Monday morning — is still open.
But it won’t stay open long.
If you want to go deeper on the technical implementation — how to wire AIBOM attestation, cosign, and Kyverno admission policies together so governance happens at build time, not after deployment — read: Shadow AI Is the New Shadow IT: Governing AI Agents from Code to Runtime.
Next in this series: what good AI governance looks like for developers — the people building with AI every day.
