AI agent governance: a checklist for the questions security will ask
Governing an assistant is mostly about what it may read. Governing an agent adds what it may do, and a wrong action changes a system rather than a sentence on a screen. Five controls carry most of the weight: the agent acts under its own scoped identity, it can only call an approved list of tools, decisions are tested against the roles allowed to make them, high-impact steps stop for a named human, and every run leaves a record. The control teams most often miss is authority, not access.
What changes when an assistant becomes an agent
An assistant returns text. If it is wrong, a person reads it, disagrees, and moves on. The blast radius of a mistake is one screen.
An agent pursues a goal across several steps, choosing actions and calling tools as it goes. If it is wrong, the mistake is a sequence of real operations against real systems, each individually plausible, usually discovered later by someone who was not in the loop.
That is the whole reason agent governance is a separate discipline rather than a stricter version of assistant governance. You are no longer governing an answer. You are governing an actor.
Control one: give the agent its own identity
The fastest way to ship an agent is to let it run under a service account that already has broad access, because then nothing blocks it. That is also the fastest way to fail a review, and correctly so.
An agent should hold an identity of its own, with permissions scoped to the job it was built for, and those permissions should be visible in the same place your team reviews human access. If an auditor asks what this agent can reach, the answer should come from your identity system rather than from the person who built it.
The useful test: can you revoke one agent's access to one system without affecting any other agent or person? If not, the identity is shared and the scope is fiction.
MindKeepr captures what your team knows and keeps it usable, even after people leave.
Control two: an approved tool list, not an open toolbox
Agents act through tools: a search call, a ticket update, an email send, a database write. The set of tools an agent may call is the practical definition of what it can do to your organisation.
Keep the list explicit and small, and treat adding a tool as a change that goes through review rather than a configuration detail. The gap between reading a record and writing one is where most of the risk sits, so separating read tools from write tools is worth the extra work.
Anything that sends a message outside the company, moves money, or changes an entitlement belongs in its own category with its own approval, regardless of how routine it looks.
Control four: stopping points a human cannot click through
Human in the loop is often used for any screen a person glances at. A control only counts if the process genuinely cannot proceed without the person, and if the person can see enough to refuse.
Approval fatigue is the real enemy here. An agent that asks for sign-off on every step trains its reviewers to approve reflexively, which produces the audit trail of a control and none of its effect. Fewer, better-scoped stopping points hold up far better than blanket review.
Bind each approval to the exact version it was given for. If the content changes after sign-off, the approval should not silently carry forward. This sounds pedantic until the first time a document is edited between approval and execution.
Control five: a record you can reconstruct a decision from
Most teams have logs. Far fewer can answer the question an auditor actually asks, which is not what happened but why it was allowed.
A usable record names the agent, the identity it acted under, the tools it called, the material it relied on, the human who approved the step that needed approval, and the version of the thing they approved. If any one of those is missing, the reconstruction stops at an assertion.
The test is simple and worth running before anyone else runs it for you. Pick an action an agent took last week and try to rebuild the case for it from the record alone, without asking the person who built the agent.
Where governance usually breaks first
In our experience the first break is almost never the model. It is scope creep in the tool list, because a new capability gets added to unblock a team and nobody re-runs the review that originally approved the agent.
The second is silent staleness: the agent still has access to a data source whose ownership changed, so it is answering from material nobody is maintaining any more.
The third is the one nobody plans for. The agent gets a question the organisation has never actually settled, and answers anyway, because nothing in the design forces it to say that it does not know. A system that stops and names what is missing gives you a signal. A system that is right most of the time and gives no signal when it is not is the harder problem to detect.
A short version to take into a review
Does the agent have its own identity, with permissions you can revoke independently? Is there an explicit, reviewed list of tools it may call, with writes separated from reads? Are decisions tested against the roles allowed to make them, not just against access? Do high-impact steps stop for a named human, with approval bound to a version? Can you reconstruct, from the record alone, what the agent did and on whose authority?
Five questions. If you can answer all five with evidence rather than intention, you are ahead of most teams currently deploying agents.
- ✓An agent's permissions should be its own, not a broad service account borrowed from a human.
- ✓Access answers what the agent can reach. Authority answers who is allowed to decide, and they are different checks.
- ✓Approval only counts if the process cannot proceed without it and the approver can see enough to refuse.
- ✓Bind an approval to the exact version it was given for, so a later edit does not inherit the sign-off.
- ✓If you cannot reconstruct what an agent did and on whose authority, you do not have governance, you have logs.
FAQ
AI agent governance is the control of AI agents that take actions rather than only produce text. It covers which identity the agent acts under, which tools and data it may use, which steps require human approval, and what record it leaves behind. It differs from assistant governance because a wrong action changes a system rather than a sentence on a screen.
AI governance is the wider programme covering which AI systems are approved, what data they may process, who is accountable, and how use is evidenced. Agent governance is the subset that deals with systems that act: scoped identity, approved tools, authority checks, stopping points for humans, and a reconstructable record of each run.
Access is whether the agent can reach a record. Authority is whether the decision it is about to record is one that someone in the conversation is permitted to make. An agent can have valid access and still record an approval nobody was allowed to grant, which a permissions model will not flag because no permission was violated.
Yes. An agent running under a shared service account inherits access that cannot be reviewed or revoked independently. Giving each agent a scoped identity of its own means its permissions appear alongside human access in your identity system, and one agent's access can be withdrawn without affecting anything else.
It should name the agent, the identity it acted under, the tools it called, the material it relied on, the human who approved any step that required approval, and the specific version of what they approved. The test is whether you can reconstruct the case for an action from the record alone, without asking the person who built the agent.
Start free in minutes, or get a demo on your own tools and team.
Sarim Zafar is the co-founder and CEO of MindKeepr. He has spent twelve-plus years building and scaling cloud and AI platforms for large organisations, and still writes the code behind MindKeepr's governed memory.