Research
AI agent governance readiness guide
Framework for assessing AI agent governance readiness across inventory, permissions, approvals, logging, and incident response.
· Cantina
Governance requires mapping policy clauses to runtime checks and audit evidence, not just writing policies.
“AI agent governance” is the phrase every CISO is putting in their 2026 board deck. Writing the policy is the easy part. Making the policy actually fire in production is where teams stall.
Here’s a real sentence from a real policy doc:
“Agents may only access customer data when the access tier permits, and when the action falls within the agent’s defined operating envelope.”
That sentence reads fine in a slide. In runtime, it has to become a sequence of checks that block an agent the moment the request is made, so the breach review never has to happen.
That one policy sentence decomposes into four runtime checks:
Miss any one of those and the policy is decoration.
Most security teams have a written policy. Few have the map from each clause to the runtime checks that enforce it.
The work isn’t in writing the policy. The work is plumbing the checks into the runtime and connecting each one back to the document an auditor will eventually open.
Every clause should produce one or more runtime checks. Every check should produce evidence. Every piece of evidence should close back to the clause it came from.
When the map exists, governance is an operating model. Without it, governance is a phrase.
Three functions own different parts of the same loop. AppSec catches the code-level intent class. SecOps watches the runtime decision. Compliance assembles the evidence trail. The agent runtime controls the action before it lands.
The mistake is treating these as separate workstreams. They are one loop. Anything that breaks the loop breaks governance.
Pick one clause from your current AI agent policy. Just one. Put it on a whiteboard and answer four questions:
Most teams discover they cannot answer all four for any clause in their policy. That is the gap.
We’ve created a flow that maps policy clauses to runtime controls and audit evidence, with examples filled in for the six clauses we most often see in AI agent policies. Contact us to find out more.
What is the difference between AI policy and AI runtime control? AI policy is the written clause that defines what an agent may and may not do. AI runtime control is the live, code-path enforcement of that clause at the moment of action. Policy without runtime control is a document. Runtime control without policy is a black box.
How does AI agent governance differ from traditional IAM? Traditional IAM authorizes a human or service identity once and trusts the session. AI agent governance authorizes each action, because the agent’s intent can drift inside a single session. Per-action checks, not per-session checks.
What evidence does an AI agent governance audit require? At minimum, a correlated log line per agent action capturing who decided, on what evidence, through which channel, with what outcome. The log must trace forward to the policy clause it enforces.
Which frameworks should AI agent governance map to? The NIST AI Risk Management Framework (AI RMF 1.0), the OWASP Top 10 for LLM Applications, and MITRE ATLAS are the three most commonly cited reference frames for AI agent risk and control.
Can existing SIEM and SOAR tools handle AI agent governance? Partially. SIEM and SOAR can ingest the correlated log line and route alerts. They do not produce the action gate, access-tier lookup, or intent classifier. Those have to be plumbed into the agent runtime itself.