Agent Security › Governance
A small business with five agents should be able to use the same principles as an enterprise with 500, without building a bureaucracy. Eight practical parts, scaled to risk.
AI governance can sound enormous: policies, committees, risk frameworks, compliance programmes, documentation, audits. For large organisations deploying AI at scale, some of that may be necessary. But if you're a business beginning to use AI agents, governance can start with something much simpler.
You need to know: which agents exist? Why do they exist? Who is responsible for them? What can they access? What are they allowed to do? Where must a person step in? Can you see what they're doing? What happens when something goes wrong?
That's agent governance. At its core, it means making deliberate decisions about how AI agents operate inside your organisation, and making sure those decisions remain true after the agent starts working.
AI agent governance is the system of rules, responsibilities, controls and review processes used to manage AI agents throughout their lifecycle: creating agents, approving them, assigning owners, granting access, setting authority, defining human approval, monitoring activity, managing changes, responding to incidents, and eventually retiring them.
Who decides what this agent is allowed to do? Good governance answers that, and then makes sure those decisions can actually be enforced.
The two overlap, but they aren't identical. Agent security asks: how do we protect systems, information and operations from inappropriate agent actions? Agent governance asks: how does the organisation decide what appropriate agent behaviour actually is?
For example, security might enforce a £500 spending limit. Governance determines why £500, who approved it, which agents receive it, when it is reviewed, who can change it, and what happens if the agent's role changes. Security implements controls. Governance determines and maintains them.
You can write: "AI agents must only access information necessary to perform their approved business function." That's a sensible policy. But if nobody knows which agents exist, what they access, who owns them, or whether anyone has reviewed them, the policy doesn't achieve much. Governance needs to connect written rules to operational reality. That's why practical agent governance starts with the agent itself.
You don't need to start with a 70-page governance framework. Start with eight things.
If you can do those eight things consistently, you already have the foundations of an agent governance system.
Start with an AI Agent Register. For every agent, record Agent ID, name, purpose, owner, department, model/provider, platform, systems, data, tools, authority, approval requirements, risk, status, last review and next review. This becomes your central inventory, because you cannot govern agents you don't know exist.
Every significant agent should have a named human owner who can answer why the agent exists, what it accesses, why it needs that access, what it can do, where it requires approval, and when it was last reviewed. The owner doesn't need to approve every action, but somebody needs responsibility for the agent itself. Avoid ownership such as "everyone", "AI Team" or "IT" where a specific responsible person can reasonably be identified. Shared responsibility can easily become no responsibility.
An agent's purpose should be clear enough to determine whether an action is inside or outside its job. Weak: "help with sales." Better: "research prospective companies using approved public sources and selected CRM data, then prepare prospect briefings for sales representatives." Now you can ask whether it needs email SEND (probably not), payment access (no) or CRM READ (yes). Purpose gives you the basis for authority.
Once you know the job, decide how much independent power the agent needs, using the Creative Sauce AI Authority Ladder: READ, RECOMMEND, PREPARE, CHANGE, SEND, SPEND, PUBLISH, DELETE. Don't automatically give the agent every capability available through a connected system. Ask what the minimum useful authority is. Start there. Expand deliberately.
Some actions shouldn't depend solely on the agent deciding whether they're appropriate: maximum payment, maximum refund, restricted data, restricted systems, external destinations, production deployment, deletion, credential creation, permission changes, public publishing, agent creation. High-consequence boundaries should increasingly be enforced outside the model itself. Instructions tell an agent what it shouldn't do. Controls determine what it cannot do.
"Keep a human in the loop" isn't a complete governance model. Define where the human actually sits: research autonomous, internal CRM update autonomous and monitored, external customer email conditional autonomy, large refund approval, production deletion approval plus additional control, high-impact decision about a person a human decision. The goal isn't human approval everywhere. Put humans where consequences begin.
Governance cannot stop at "this is what the agent is supposed to do". You also need visibility into what the agent actually did. Depending on the agent, monitor systems accessed, tools used, actions completed, actions blocked, external communications, approvals, financial activity, data movement, agent-to-agent requests and unusual behaviour. The purpose isn't surveillance for its own sake. It's verifying that the agent continues to operate within its intended authority.
Every organisation using consequential agents should be able to answer: what do we do if an agent behaves unexpectedly? That may include pause agent, stop task, revoke credentials, disable integration, preserve logs, check data movement, review actions, notify appropriate people, investigate cause, change controls and review before restart. Don't wait for an incident to decide who has permission to stop the agent.
Agent governance shouldn't happen once at deployment. Think about the whole lifecycle: CREATE (what problem is the agent solving, who owns it), ASSESS (what systems and data does it need, what consequences could its actions create), AUTHORISE (what authority will it receive, where are its limits, who approves it), DEPLOY (is identity configured, are permissions correct, are monitoring and containment available), OPERATE (what is the agent actually doing, are there unusual actions), CHANGE (has its purpose changed, has another integration been added, has its authority increased), REVIEW (does it still need everything it has, are the controls still appropriate) and RETIRE (stop schedules, revoke credentials, remove integrations, remove delegated authority, archive required records).
An agent is not governed simply because somebody approved it once.
Imagine a research agent originally has browser READ. Six months later someone adds CRM, then email, then Drive, then code execution. Nobody has fundamentally changed the agent's original purpose, but its effective authority has changed dramatically. Governance should recognise capability creep. When meaningful capabilities are added, review the agent again.
Authority can quietly increase over time. At launch the agent drafts emails. Three months later it sends internal emails, then selected customer emails, then all routine customer emails. Then someone removes the approval step because it slows things down. Each decision may seem small. Together, the agent has moved from PREPARE to SEND autonomously. That may be perfectly appropriate, but it should be a conscious governance decision.
Not every agent needs the same process. Agent A summarises public news articles. Agent B reads customer records and sends customer emails. Agent C accesses financial systems and prepares payments. Treating all three identically would make little sense. A practical risk model can consider whether the agent accesses sensitive information, communicates externally, changes records, executes code, spends money, publishes, deletes, uses credentials, operates autonomously, accesses production or controls other agents. Higher consequence should mean stronger controls and more frequent review.
| Level | Typical characteristics |
|---|---|
| LOW | Limited access, low-consequence actions, little or no sensitive data, easy to reverse |
| MEDIUM | Business system access, some internal changes, external communication, moderate consequences |
| HIGH | Sensitive information, financial actions, production access, public publishing, significant autonomy |
| CRITICAL | Broad high-consequence authority, irreversible actions, highly sensitive systems, major financial authority, security administration, control over other powerful agents |
These categories are prioritisation tools. They aren't security certifications.
That depends on its risk. A small business might have: low risk, agent owner approves; medium risk, agent owner plus technical review; high risk, business owner, security or appropriate functional leader; critical, formal review by relevant decision-makers. Larger organisations may need more structured processes. The important principle is that approval should match consequence.
Larger organisations may legitimately need formal governance committees. But governance shouldn't become a process where every tiny AI experiment requires six people, three meetings and a 14-page form. If governance makes safe experimentation impossible, people may simply work around it. Good governance should make the safe route easier: a low-risk agent gets a short registration, a clear template, standard permissions and deploy; a high-risk finance agent gets more detailed review, stronger controls, approval and monitoring. The process should scale with risk.
One way to make governance easier is to create standard agent profiles so teams aren't inventing security from scratch every time. For example a Research Agent (public web READ, approved internal documents READ, external SEND deny, SPEND deny, DELETE deny, risk LOW); a Content Agent (research READ, CMS PREPARE, PUBLISH approval, DELETE deny, risk MEDIUM); a Customer Support Agent (support platform READ/CHANGE, CRM limited READ, email conditional SEND, refund limited, sensitive data restricted, risk MEDIUM/HIGH); a Finance Agent (accounting limited, payment PREPARE, SPEND approval, credentials deny, DELETE deny, risk HIGH).
Multi-agent systems introduce additional questions. For every agent relationship, consider who can call whom, what they can request, what authority can be delegated, what data can be returned, whether one agent can trigger another agent's tools, whether authority can escalate through a chain, and whether the original requester can be identified. For example: Sales Agent may request research from Research Agent, but cannot call Finance Agent. Governance increasingly needs to cover the relationships between agents, not just individual agents.
Not every agent will be built by your organisation. You may use agents supplied by software vendors, platforms, consultants, partners or external services. Still ask: what does it access, what data does it receive, what actions can it perform, what credentials does it use, who controls it, can you disable it, what happens to your data, how is activity recorded, and who is responsible when something goes wrong? "Third-party agent" shouldn't mean "someone else's security problem".
Agents may operate continuously. That creates an interesting governance question: what authority should exist when nobody is available to intervene? You might decide routine research continues, internal low-risk actions continue, external communication is limited, a large transaction is queued, an unexpected security event pauses the agent, and a critical action waits for a human. Autonomy shouldn't silently increase because it's 3am.
Sometimes the normal rule won't fit. That's fine. But exceptions should be visible. Standard rule: agent cannot publish. Exception: Product Data Agent may publish approved stock availability automatically. Record what the exception is, why it exists, who approved it, when it expires and when it will be reviewed. Otherwise temporary exceptions have a habit of becoming permanent permissions.
If a business says "all high-value agent transactions require human approval", you should ideally be able to demonstrate that, from permission configuration, approval records, activity logs, the Agent Register, monitoring and review history. Governance becomes much stronger when policy and evidence connect.
Models will change. Businesses may move between OpenAI, Anthropic, Google, Microsoft, open models and future providers. If your governance framework is built entirely around which model you're using, you may have to redesign it constantly. Instead, much of agent governance can focus on identity, purpose, access, authority, data, actions, approval, monitoring and containment. Those questions survive model changes.
Govern what the agent can do, not just which model powers it.
If you're starting today, do these ten things: create an Agent Register; give every agent a named owner; write down each agent's purpose; record the systems and data it can access; assign its authority (READ / RECOMMEND / PREPARE / CHANGE / SEND / SPEND / PUBLISH / DELETE); define high-consequence boundaries; define human approval points; record and monitor important actions; make sure you can pause the agent and revoke access; and set a review date. That's a governance framework. You can make it more sophisticated later.
For every significant agent, ask:
If the answer to those is mostly yes, you have the beginnings of meaningful agent governance. Not just an AI policy sitting in a folder.
There isn't one answer. In a small organisation, it may be the founder, technical lead, operations lead or security lead. In larger organisations, responsibility may span security, IT, risk, compliance, legal, data protection, AI governance and business functions. But there should be clarity over who owns the agent, the governance process, and the individual high-consequence decisions.
This is ultimately what we're building Agent Control to make easier. Instead of governance existing across spreadsheets, AI policies, API settings, individual platforms, emails, approval messages and people's memories, the goal is to bring the operational picture together: register (which agents exist), identity (who they are), owner (who is responsible), purpose (why they exist), authority (what they can do), boundaries (what they cannot do), approval (where humans step in), activity (what they are actually doing), risk (which agents deserve the most attention), review (when someone needs to check them again) and containment (can they be stopped). That's agent governance translated into something operational.
Agent Control is in build. Leave your email and we will let you know when it is ready.
Good AI agent governance shouldn't exist to stop businesses using agents. It should make it easier to use them with confidence. Because the alternative isn't "agents with governance" versus "no agents". Increasingly, it may be "agents we understand and control" versus "agents appearing across the organisation without anyone having a complete picture".
Start with visibility. Assign ownership. Define purpose. Limit authority. Put humans where consequences begin. Monitor the boundaries. Review when things change. And make sure you can stop what you start.
You don't need to build a bureaucracy around every AI agent. You need to know who has authority over the authority.