AI agent governance is the set of rules, owners and records that decide which AI agents may run in your company, what they can touch, who approves their actions, and how you prove it afterwards. It is not one product. It is a working agreement that tools can then enforce.
The definition, piece by piece
An agent is software that uses a language model to decide what to do next and then calls tools to do it. Governance answers five questions about every one of them.
| Question | What you record or enforce |
|---|---|
| Which agents exist? | An inventory with an owner per agent |
| What can each one reach? | Tools, data and credentials, scoped per agent |
| Which actions need a person? | An approval rule for high-impact actions |
| What happened? | Logs of tool calls, tied to an identity |
| What happens when it goes wrong? | A way to stop it and a runbook |
Governance is different from security testing. Testing asks whether an agent can be tricked. Governance asks whether you would know, limit and recover if it were.
Why the "excess" is the usual problem
OWASP describes excessive agency as a system that takes damaging actions in response to unexpected, ambiguous or manipulated model output, and names three root causes: too much functionality, too many permissions, and too much autonomy. Each one is a governance decision made, or skipped, before any attack happens. Nobody chose to give the agent a shell tool or a broad token on purpose, but nobody decided against it either.
First steps that fit in a month
- Build the list. Ask each team which agents, assistants and tool servers they use. Add what you find from developer machines and cloud accounts. A short, wrong list beats no list.
- Name an owner for each. A person, not a team alias. If the owner leaves, the agent is flagged.
- Set a default access rule. Read-only first. Write access needs a reason on file.
- Pick the actions that need approval. Deleting data, sending messages outside the company, spending money, changing production. The MCP specification says there should always be a human in the loop with the ability to deny tool invocations, which is a sensible default for these.
- Turn on logging. Capture which tool was called, with what input, under which identity. Logging does not prevent excessive agency, as OWASP notes, but it limits the damage and speeds the review.
What governance is not
It is not a policy PDF nobody reads. A rule that lives only in a document depends on every agent and every developer remembering it. Where you can, move the rule into something that checks it, such as a pull request gate or a tool allowlist.
It is also not a reason to block everything. A framework such as the NIST AI Risk Management Framework is explicitly intended for voluntary use and organises the work under functions including Govern. Use it as a vocabulary, then fit the effort to the risk of each agent.
Try it yourself
Click through it at your own pace, or open it full screen.
Click a framework and watch how one control maps to several requirements, which is how a single agent rule can serve more than one audit.
Safeguard offers policies, gates and guardrails, agent identity, asset discovery and an MCP Guardrail, so the rules above can be enforced and recorded in one place. You can start with the free scan.
Quick check
Is AI agent governance the same as AI governance?
No. AI governance is broader and covers models, data, fairness and legal duties. Agent governance is the narrower slice about autonomous software that calls tools and takes actions.
Do we need a tool before we start?
No. An inventory, an owner per agent and an approval rule can be written down this week. Tools help you enforce and prove it later.
Sources
- OWASP, LLM06:2025 Excessive Agency
- Model Context Protocol, Tools specification
- NIST, AI Risk Management Framework
Last reviewed: 19 October 2026.
