AI agent governance is the set of enforced controls that decides what an AI agent can do, who can run it, what data and tools it can access, and when a human must approve an action. Good governance is not a policy document beside the agent. It is a set of runtime controls inside the system that stop unsafe work before the agent can carry it out.
That distinction matters once agents move from experiments into real operations. A written policy can say an agent must not access billing, send customer messages, expose secrets, or change records without approval. But if the system still gives the agent those tools, and still lets the action run, the business does not have governance. It has a statement of intent.
We built hmn.plus around a blunt principle: the system should refuse unsafe work before the agent can do it. That means roles, permissions, budgets, tool limits, audit trails, secret redaction, and approval gates have to be enforced by the machinery that runs the agent. Not hoped for in the prompt. Not buried in a policy. Enforced where the action happens.
Most AI governance advice was written for people using AI as a chat assistant. That is not the same problem as governing agents.
A chat assistant produces text. An agent can take steps. It can call tools, search sources, write into systems, prepare files, update records, trigger workflows, and ask for another tool call after the first one finishes. The risk is not just what the model says. The risk is what the system allows the agent to do.
That is why AI agent governance needs a more practical question than “is our AI use responsible?” The better question is:
If the agent tries to do the wrong thing, where does the system stop it?
If the answer is “our policy says it should not”, you have documentation. If the answer is “the prompt tells it not to”, you have guidance. If the answer is “the role check refuses the run”, “the tool is not available”, “the approval gate blocks the action”, or “the runtime rejects the request before it executes”, you have governance.
This is the shift owners need to make. AI agent governance is not about sounding careful. It is about making the wrong action difficult, visible, or impossible.
Most AI agent governance fails because businesses treat agents like staff who read rules and make judgement calls. Agents do not work that way.
A person can read a policy, understand intent, notice an edge case, and ask a manager. An agent follows the environment you give it. If the tool is available, the credential is exposed, the approval step is optional, or the path has no hard stop, the agent may use it.
The common mistake is writing rules around the agent instead of putting those rules into the agent’s execution path.
The policy might say:
Those are sensible rules. But they are not governance until the system enforces them.
If a junior user can still launch the finance agent, the role rule is cosmetic. If logs can still capture raw credentials, the redaction rule is wishful thinking. If the agent can still send an external message without a human approval step, the approval rule is decoration.
Governance is not what you intend. Governance is what the system makes impossible.
Executable governance means the controls are checked by the runtime. The runtime is the part of the system that actually runs the agent, connects it to tools, receives its proposed actions, and decides whether those actions are allowed.
In our own build work, we use a simple dividing line:
That second version is what business owners need. Not because your team is careless. Because agents can make mistakes faster than people can notice them.
A governed agent system should enforce several practical controls. They are not theoretical. They map directly to the moments where risk enters the workflow.
Not every signed-in user should be able to run every agent. Some agents are low risk. Some can affect customer data, financial workflows, internal operations, or brand reputation.
A role control should happen at the point of execution. If the person requesting the run does not have the right role, the system should refuse the run before the agent starts.
That matters because the control happens before work begins. It does not rely on the user remembering the policy. It does not rely on the agent interpreting a sentence. The system checks the actor and blocks the run if the person should not be running it.
For a business owner, this is the difference between “we told people not to run that” and “they physically cannot run that”.
AI agents become risky when they can use tools. A generated answer is one thing. A tool call that updates records, sends emails, changes customer status, or queries sensitive systems is another.
So the question is not only “is the model safe?” The better question is: what tools can this agent reach, under what role, and under what conditions?
A research agent should not have operational tools just because they exist elsewhere in the business. A support agent should not have finance tools unless the role, context, and approval path justify it. A general assistant should not receive broad system access because it might be useful later.
Useful later is how control gets lost now.
The safest pattern is narrow access by default. Give the agent the tools it needs for the job it was designed to do. Keep everything else out of reach.
A serious agent system should not wait until an agent is already running to discover that something is unsafe. The checks should happen before execution begins.
Preflight checks are the point where the system inspects the run request, the actor, the declared constraints, the available tools, and any required approvals before the agent can act. The point is not internal complexity. The point is timing.
This prevents a common failure mode: the agent starts, receives a powerful tool list, and the business hopes the prompt keeps it inside the lines.
Prompts are not permission systems. They are instructions. Permissions are enforced by the runtime.
Some actions should not be autonomous, even if the agent can prepare them well.
An agent might draft a customer reply, summarise a complaint, prepare a refund recommendation, or assemble an outbound message. But sending the message, issuing the refund, or changing account status may need a human approval gate.
A real approval gate is not “ask the agent to check with a human”. A real approval gate is a blocked transition. The agent can prepare the action, but the runtime will not execute it until an authorised person approves it.
This is especially important for SMEs because many teams adopt agents to reduce manual load. That is sensible. But removing every human checkpoint at once is how small mistakes become expensive.
The mature pattern is tiered autonomy:
That gives you speed without pretending risk has disappeared.
When an agent does something odd, you need more than “the AI decided”. You need a trace.
A useful trace shows the chain of events. What did the user ask for? What did the agent attempt? Which tool did it call? What input did it pass? What result came back? What did it do next?
This gives the business two benefits.
First, the operator can see what the agent is doing during or after a run. That reduces the black-box feeling. If the agent searches public information, calls a lookup tool, and writes findings, the owner can see that activity rather than guessing.
Second, when something goes wrong, the team can inspect the failure path. That turns incidents into fixes. Without a trace, every confusing output becomes a debate. With a trace, you can find the weak control and improve it.
This matters more than most owners expect. The first time an agent produces a surprising result, you will want the record.
Agents often sit near sensitive material. Credentials, customer details, private notes, internal instructions, tokens, and operational context can all pass through the system if you are careless.
A governance policy can say “never expose secrets”. The system needs to help enforce that rule. Logs, traces, tool outputs, and user-visible activity streams should be designed so sensitive material is not casually copied into places it does not belong.
This is not only a security concern. It is an operational one. If your team is afraid to inspect agent logs because the logs might contain sensitive material, your audit trail becomes less useful. Good redaction keeps observability usable.
The rule is simple: you should be able to investigate an agent run without spreading the sensitive data you are trying to protect.
Governance is not only about data access. It is also about preventing uncontrolled work.
Agents can get stuck. They can keep trying another search, another lookup, another reasoning step, another tool call. That can waste time, create noise, and make the result harder to trust.
A governed agent should have a bounded working area. That can include limits on tool loops, timeouts, cost, retries, and the types of sources it can use. The exact settings depend on the job. The principle is stable: an agent should not be allowed to wander indefinitely just because it has not found a confident answer yet.
For owners, this is a practical control. It keeps cost and waiting time predictable. It also makes failure clearer. A bounded agent can say it could not complete the job within the allowed limits. An unbounded agent can quietly burn time while producing a weak answer anyway.
If you are adopting agents, do not start with a forty-page AI policy. Start with a control map.
For each agent, write down seven things:
Then ask the hard question: which of those controls are enforced by the system?
If the answer is “it is in the prompt”, treat that as weak control. Prompts help shape behaviour. They do not replace permissions.
If the answer is “it is in the policy”, treat that as weaker still. Policies are useful for people. Agents need enforced boundaries.
If the answer is “the runtime refuses the action”, you are in the right territory.
Picture a small B2B company using an AI agent to enrich prospect records. The owner wants help finding public company information, checking websites, and writing useful notes for the sales team.
That sounds low risk. It can become risky fast if the agent has the wrong access.
If the research agent can also update billing data, email prospects, change account ownership, or write into customer records without review, you have created an operator disguised as a researcher.
Our approach is to constrain the agent to its job. A research agent can gather public information and write findings. It should not be able to take unrelated business actions just because those actions exist elsewhere in the system. It should also have a fixed work budget so it cannot spiral through endless attempts to find a perfect answer.
That design does two things.
It keeps cost and time bounded. The agent cannot keep trying one more search, one more source, one more inference without limit. It also keeps authority bounded. The agent can produce findings, but it cannot start operating the business.
This is what good AI agent governance feels like in practice. Not dramatic. Not heavy. Just clear limits that match the job.
Written policy still has a place. Your team should know what agents are allowed to do. Owners should define acceptable use. Staff should understand escalation paths. Customers and suppliers may need plain-English assurances.
But written policy is not enough because it sits outside the action.
Runtime enforcement sits inside the action. It is present when a user starts an agent, when the agent receives tools, when it attempts a tool call, when a sensitive result is logged, and when a high-risk action waits for approval.
That is why it beats theatre.
A policy can be ignored. A prompt can be bypassed. A checklist can be forgotten. A runtime block has to be dealt with.
This also changes the owner’s relationship with autonomy. You do not need to choose between “no agents” and “agents can do anything”. You can create lanes.
Each lane has different roles, tools, logs, budgets, and approvals. That is more useful than one vague company-wide rule that says “use AI responsibly”.
A policy is still useful when it tells people how the business thinks about agents. It should not pretend to be the control layer. Its job is to define the rules that the system then enforces.
A practical AI agent governance policy should answer:
Keep the policy short enough that people can follow it. Then make the critical parts executable. A long document with no enforcement is not safer than a short document with hard controls.
Broad access is convenient during a demo. It is dangerous in production. If an agent does not need a tool for its job, do not expose it.
A prompt can tell the agent not to do something. It cannot reliably prevent a tool call if the tool is available and the runtime allows it. Use prompts for guidance. Use permissions for control.
No trace means no diagnosis. If the agent causes confusion, you will be left reconstructing events from outputs and guesses.
This creates a different problem. You may have a rich audit trail that nobody wants to open because it contains sensitive material. Useful logs are structured, reviewable, and safe enough to inspect.
Autonomy should be earned. Start with preparation and recommendation. Then allow low-risk execution. Keep high-risk decisions behind approval until the system has proved itself in your context.
Agent risk often grows by accident. A research helper gains a writing tool. Then a sending tool. Then a database update. Each step feels small. Together, they change the agent’s authority.
Review agents when their tools change. Tool access is scope.
You do not need a large programme to begin. You need a clear inventory and a bias toward enforced controls.
Start with one agent. Answer these questions:
Then make one improvement. Restrict a tool. Add a role check. Put an approval gate before an outbound action. Add a useful activity log. Redact sensitive output. Set a work budget or timeout so the agent cannot run without bounds.
Good governance is built from these concrete controls. It is not built from slogans.
Here is the simplest test I use when thinking about AI agent governance:
If the agent tries to do the wrong thing, where does the system stop it?
If the answer is “the policy says it should not”, you have a document.
If the answer is “the prompt tells it not to”, you have guidance.
If the answer is “the role check refuses the run”, “the tool is not available”, “the approval gate blocks execution”, or “the runtime rejects the action before it can happen”, you have governance.
That is the shift SMEs need as agents move from experiments into real operations. The question is no longer whether AI can help. In many workflows, it can. The question is whether you can keep control when the agent is connected to the systems that matter.
Our view is direct: AI agent governance has to be executable. Policies explain the rules. Runtime controls enforce them. If those two things do not meet inside the system, the business is relying on hope.
And hope is not a control.