Your AI Agent Did Not Go Rogue. You Gave It the Keys.
Bottom line: an AI agent does what your systems allow it to do. If it did something you did not expect, the failure is in your controls, not in the software’s character. AI agent governance is now a board issue, and most boards cannot answer the basic question: what is our agent actually allowed to touch?
Think about a new starter on day one. You would not hand them a company card, the customer database, the email system and no manager. That is close to how many businesses deploy their first agent.
Stop calling every failure “rogue AI”
Headlines love the word “rogue”. It suggests software that woke up one morning and decided to misbehave. That is not what happens.
An agent is given a goal. It looks for a path to that goal. If a boundary is not enforced, it goes straight through it. That is not rebellion. That is ordinary optimisation doing its job.
As I set out in AI Agents: The Next Digital Workforce, digital workers do what they are permitted to do, not what you quietly hoped they would do.
Here is the honest version. Most “rogue agent” stories are an admission that nobody in the business could say, on paper, what the agent was allowed to do.
Tool access changes the risk, not the model
A chatbot writes text. The worst case is a wrong answer and a red face.
An agent with tools is a different kind of software. Give it API keys, live internet access, a code environment, internal company data and the right to change records or send messages, and you have privileged software with a login.
The risk moves from a made-up fact to a real action:
- Money moved or spent
- A customer record changed
- An email sent outside the company
- A system opened to something that should not have reached it
Same model. Different risk category. That gap between prompting and full system access is covered across my AI leadership writing.
Five controls to fit before you widen access
Treat this like onboarding staff, not installing a feature. Five parts:
- Its own identity. Every agent and automated workflow gets its own account and credentials. No shared human logins.
- A permission budget. Least privilege by default, with hard caps on data, API calls and spend.
- A full action log. Record every step, tool call and query, not just the final output.
- An independent check. Fixed rules or human sign-off for consequential actions, run by something other than the agent itself.
- A tested off switch. Kill the process, rotate the credentials, cut the network access. Test it before you need it.
Together these five make up your control plane. If you want an external reference to hand to your risk team, the NIST AI Risk Management Framework and the OWASP Agentic AI Threats and Mitigations guide both cover this ground in detail.
AI agent governance is not the same as output quality
A perfect final report can hide a bad path. The agent may have reached the right answer by touching data it should never have seen.
You cannot govern autonomy by reviewing outputs. You need to see four things:
- What data it accessed
- Which tools it called
- What was blocked
- Who can stop it, and how quickly
If you can only see the output, you are not governing the agent. You are grading its homework.
A 30-day plan for the board
I have reviewed over 1,000 real AI projects. The pattern is consistent. The businesses that stay out of trouble set the boundaries before they widen access, not after an incident.
- Days 1 to 5. Inventory. List every agent running in the business, including the ones nobody signed off.
- Days 6 to 12. Access map. For each agent, write down the data, tokens, tools and network access it holds today.
- Days 13 to 18. Thresholds. Decide which actions need a human. Money, customer contact and record changes are the usual three.
- Days 19 to 24. Isolation test. Revoke a credential. Cut the network. Time how long it takes to contain.
- Days 25 to 30. Owner and drill. Name one executive owner and run a simulated agent incident.
Three questions to ask on Monday
- How many agents are running, and who owns each one?
- What is the largest action an agent can take without a human?
- If one caused a problem at 9am on a Friday, who stops it, and how long does that take?
If your team cannot answer these in a single meeting, that is your starting point.
FAQ
What is a rogue AI agent?
There is no such thing in practice. It is an agent pursuing its goal through a gap you left open. The behaviour is unexpected to you, but predictable to the system.
What is an agent control plane?
The set of controls around your agents: identity, permissions, logging, checks and an off switch. It is the equivalent of HR, IT access and expense policy for a human employee.
Who should own AI agent governance?
One named executive, supported by IT security and risk. Shared ownership means nobody is accountable at 9am on a Friday.
Do smaller companies need all of this?
Yes, at a smaller scale. If an agent can spend money, change a record or email a customer, it needs an owner, limits and a log. Size does not change that.
How do we start if agents are already running?
Start with the inventory. You cannot control what you have not listed, and shadow agents are usually the ones with the loosest access.
Get your agents under control
AI agent governance is not a technology problem. It is a decision about what your business allows.
Book Mark Kelly for a board briefing or executive workshop to map where your agents can reach, build the five controls, and test the off switch before you need it.
