AI Governance
The Smallest Artifact That Turns an Ungoverned Agent Into a Governed One
AI agent security is the top concern in the field, twice the size of the next one. The fix is not a platform. It is one row per agent, filled in before it runs: identity, data class, allowed actions, a human-in-the-loop line, and a tested stop.
September 14, 2026 · 7 min read

A CISO at Team8, Tim Brown, has a line I keep coming back to. It is easy to build a guardrail that is one hundred percent effective: unplug the agent and throw it in the ocean. Perfectly safe. Also useless. The hard part is the guardrail that keeps the utility and removes the blast radius, and that is exactly the part most teams have not built yet.
The pressure is real. In one recent survey of security leaders, AI and agent security came back as the single biggest pain point at 78 percent, almost exactly twice the size of the second concern at 39 percent. That is not a rounding difference. That is the field telling you where the fire is. And the fire is not the model returning a wrong answer. It is the agent that plans, calls tools, holds memory, and acts on production systems at machine speed without waiting for anyone to check.
Here is the awkward truth underneath the survey number. Your employees are already running these agents. Someone on your team has Claude Code, Cursor, or Codex wired into a repository that touches production data right now. None of it went through procurement, because nobody procured it. You cannot write an enforceable policy for an agent you have not named, and you cannot grant privilege you have not scoped. So most organizations are in the worst position: real autonomy, real reach, and no record that it exists.
Why the platform pitch does not fit the problem
Walk any expo floor and the answer on offer is a platform. Buy the agent-security suite, route everything through it, and trust the dashboard. There is a place for that eventually. But it is the wrong first move, and not because the products are bad. It is the wrong first move because you cannot secure what you have not inventoried, and no purchase does the inventory for you.
The buyer problem is smaller and more stubborn than a platform. It is that a developer spun up an agent last Tuesday, gave it a token that can read the production database because that was the fast way to make it work, and never told anyone. The failure mode is not a missing feature. It is a missing record. And a missing record is fixed with an artifact, not a subscription.
One row per agent, filled in before it runs
The artifact is a table. One row per agent in production, and one per agent someone is about to ship. Five columns carry the weight, and each one is a boundary you can defend.
Identity. Every agent gets its own credential and a named human who owns that credential. No shared service account standing in for three agents. When the token authenticates somewhere new, the owner is the one who gets asked whether that was expected.
Data class. Name the highest class of data the agent can reach: public, internal, confidential, or regulated such as PHI, PCI, or CJIS. That is your blast radius on the data side. If an agent can read regulated data, someone set that boundary on purpose and can say why.
Allowed actions. Scope by blast radius, not by feature. Three tiers is enough to start. Read-only on a named scope. Write to non-production, meaning staging, drafts, or ticket queues. Write to production, send external, or move value, which always requires a named human in the loop. The tiers map to reversibility, and reversibility is what actually matters when an agent goes wrong.
Human-in-the-loop trigger. State the exact line the agent cannot cross alone. Vague triggers like "sensitive actions" are not enforceable. "Any write to the production customer table" is. If you cannot write the line as a specific event, you do not yet understand what the agent does.
Stop control. How you halt this specific agent, tested, with a named owner and a known time to stop. Revoke the token, disable the endpoint, kill the session. An untested stop control is a hope, not a control, and the difference shows up at the worst possible moment.
The rows you cannot complete are not a gap in the template. They are your real exposure, ranked. An agent you cannot describe in five columns is an agent you do not control.
The policy is the table. The enforcement is the alert.
A table in a wiki drifts out of date the week after you write it. So the matrix has to bind to something that runs. The trigger worth catching first is narrow and high signal: an agent token authenticating to a resource it has never touched before. That is the earliest sign an agent has exceeded its scope, whether from prompt injection, a misconfiguration, or a developer quietly widening its reach.
The logic is a first-seen rule. Take the set of identity-and-resource pairs the agent used across a clean thirty-day window, call that the baseline, and raise an alert on anything new. If you run Wazuh or Specter, our Wazuh and Suricata triage layer, you do not need a new data source for this. You enumerate the agent identities from column one of your matrix as a list, tag every authentication event those identities generate, and fire a high-severity rule when the identity-and-resource pair is absent from the baseline. The full rule, with MITRE mappings for valid-account abuse and account manipulation, ships in the toolkit.
The part that makes it work is the routing. Send that alert to the identity owner from column one, not to a shared inbox where it dies. The owner is the one person who can say in seconds whether the new resource was expected. If it was, the matrix row is out of date and the fix is to update it. If it was not, you have caught an agent exceeding its scope at the first hop instead of the fifth.
Where this fits, and where it stops
None of this is a parallel governance track bolted on the side. Each column of the matrix is the one-page expression of a control that already belongs in a real program: agent identity and registration, memory and context governance, tool and action authorization, human oversight, and the decision trace. If you already run a governance framework, the matrix is how a developer plugs one agent into it in ten minutes. If you do not, the matrix is a starting point small enough that you will actually fill it in.
I published the Agent Privilege Matrix as a free template in the CarbeneAI AI Governance Toolkit, alongside the worked example rows and the detection rule. It is CC BY 4.0. Copy it, adapt it, and delete what does not apply to you. It is not legal advice and it is not a finished policy. It is the smallest thing that turns an ungoverned agent into a governed one, which is the move you can make this week.
The judgment to map it to your specific risk, your regulatory reality, and the agents your own people are running is where the real work happens. That is the conversation worth having. If you want help having it, that is what CarbeneAI does. Reach out at carbene.ai.