AI Agent Security vs. AI Governance: What's the Difference?

Two disciplines are usually funded from the same budget line and argued about as if they were one problem. Security decides what an AI agent is able to do. Governance decides who is answerable for what it did, and what evidence survives to show it. A stack can be strong on the first and completely silent on the second.

What's the difference between bot governance and AI agent governance?

Bot governance approves a fixed script before it runs. Agent governance has no script to approve. The agent picks its own steps while it is running, so control moves from the release to the individual action: what this agent may do, who allowed it, and what record of that permission survives afterwards.

The difference is a change of unit. A bot is governed at the version. There is a ticket, a reviewer and a sign-off, and the same behaviour then repeats until somebody edits it. An agent is governed at the action, and the action you have to account for happened once, inside a run nobody watched, and was never put to a human in advance. Version-level control does not reach it. By the time anyone looks, the decision is an event in the past rather than a proposal on somebody's desk.

Everything else follows from that shift. The review moves from before deployment to during execution. The artefact under review moves from a document to an event. And the question a supervisor asks moves from "what did you sign off?" to "who allowed this one?"

AI agent security vs AI governance

Security is a question about capability. Governance is a question about authority. The two sound like the same question until an agent does something it was technically permitted to do and nobody in the building can say who permitted it.

The security half has specific published guidance, and it is worth reading rather than summarising. OWASP's Top 10 for Agentic Applications for 2026 carries an entry for excessive agency — numbered LLM03 in the 2026 list, and LLM06 in the 2025 one — and its guidance on complete mediation is direct: implement authorization in your own logic rather than relying on a model to decide whether an action is allowed. That is a control on what is reachable. It is the right control, and it is a security control. It says nothing at all about who inside your organisation stands behind the reachable thing being done.

The governance half has reference material of its own. NIST's AI Risk Management Framework was built in the open, through drafts issued for public comment. A framework of that kind gives you a vocabulary, a structure, and a set of expectations to organise a programme around. What it will not do is produce the record for you. The evidence that a particular action was permitted by a particular person has to come out of your own systems, and if those systems were never built to emit it, no framework fills the hole afterwards.

Is AI governance the same as AI security?

No, and the cleanest demonstration comes from the security literature itself. In the same OWASP entry, monitoring and rate limiting are classified as measures that will not prevent excessive agency, though they can limit the damage it causes. That is worth sitting with if you own a logging pipeline and have been describing it in review meetings as a control. Monitoring is a damage-limitation measure. It is not a preventive one, and it is the security guidance saying so, not a governance vendor.

The converse is just as true and gets said far less often. Prevention is not evidence. A control that blocks an action leaves you with a blocked action and, usually, an alert; it does not leave you with an answer to the question that actually gets asked afterwards, which is always about the action that went through. Security and governance fail in opposite directions. That is the reason to keep them as two disciplines with two owners, rather than one line item that quietly collapses into whichever half the incumbent tool already covers.

Bot governance vs agent governance

Bot governance is change control wearing a different hat. Behaviour is fixed at deployment, so review happens before deployment, and the thing reviewed is a document. Agent governance cannot work that way, because the behaviour that needs reviewing does not exist until the agent is running. Anything settled in advance is settled as a boundary, not as a decision.

So an agent programme collapses into two questions: which actions sit inside the boundary, and what happens to the ones that do not. The first is an access problem, and the discipline for it is ordinary access control applied to a non-human actor — identity, scope, least privilege, revocation. None of that is new, and none of it is where teams get hurt.

The second is a permission problem, and it is new. Somebody has to say yes to the action that falls outside the boundary. That yes has to happen fast enough not to break the workflow. And the record of it has to still mean something when it is read back a year later by a person who was not there and has no reason to trust anyone who was. That is not an access-control question. It is a question about who holds authority, and how their exercise of it is preserved.

Do we need both AI security and AI governance?

Yes, because they answer to two different incidents. The first is the action that should never have been possible: the wrong system reached, the wrong record written, the payment that no policy would have permitted. That is a security failure, the fix is the boundary, and the security profession has been doing that work competently for decades.

The second incident is quieter, and much worse to sit in front of a supervisor with. The action was inside policy. It executed. Weeks later somebody asks who authorised it, and the honest answer is that a model decided and a log recorded the outcome. Nobody signed anything. No security control repairs that after the fact, because the missing thing was never a capability — it was a decision with a name attached to it. We have written separately on what decision governance actually covers, and on accountability when the action fell outside the boundary.

The sequencing question is easier than it looks. Build the boundary first, because an ungoverned capability is an immediate risk while a missing record is a deferred one. Then build the record, before the first time you need it rather than after, because evidence cannot be reconstructed backwards out of systems that never captured it.

What this means if you have to produce evidence

If somebody will one day ask you to account for an agent's action, the test is narrow and you can run it this week. Take one action your agents already perform in a real workflow. Then try to answer four questions using only the systems you already have, without asking the team that built the agent to help you.

• What is this agent allowed to do at all, and where is that written down in a form the agent is actually bound by, rather than a policy document it has never read?
• For one action that executed recently, who or what permitted it, and can you name them?
• If that permission record were edited today, would anybody find out?
• Can you answer the first three without asking the system that took the action to describe its own behaviour?

If the exercise stops at the second question, the cause is structural rather than technical. The permission was never a separate thing. It was an implicit property of the path the agent happened to take, so there is nothing to retrieve and nothing to show. The fourth question decides whether what you do retrieve is worth anything, because a record produced by the system under scrutiny is a statement by the accused.

Two design choices follow, and neither of them requires buying anything. Record the permission as an object in its own right, separate from the action and from the agent that took it, so the evidence does not depend on the good behaviour of the thing being examined. And make the record tamper-evident: written once and checkable afterwards, so that an edit, a reordering or a deletion shows up when somebody verifies it. The guarantee there is detection, not prevention. A tamper-evident record does not stop an administrator from rewriting history; it stops the rewrite from passing unnoticed.

That boundary — the point between an agent proposing an action and that action being permitted, and the record the boundary leaves behind — is the part Crelis works on. The approach is patent-pending. No regulator requires it, and nothing on this page is a compliance obligation. Greenlight is how the permission step is meant to work, and the trust layer is where the resulting record is meant to live.

One disclosure belongs in a comparison piece more than anywhere else. Crelis does not hold SOC 2, ISO 27001 or ISO 42001 certification, and the security page on this site is explicit about it. Designing against the intent of a standard is not certification to it, and a vendor who blurs that line has already told you something useful about how carefully they will handle your evidence.

Related reading

• What is AI decision governance? — the layer this article calls the permission problem.
• AI agent accountability for unauthorised actions — what to do when the action fell outside the boundary.
• AI governance — the rest of our writing on the governance half.
• Access control — the security half, applied to non-human actors.
• Greenlight — how a permission is requested, given and recorded.
• The trust layer — where the record lives, and how anyone checks it.