When Agents Go Rogue: Containment Controls Boards Should Ask About

An AI agent does not just answer — it acts. It sends the email, moves the money, updates the record, places the order. That single difference is what turns the governance conversation about AI from an abstract one into an urgent one, because the failure mode of a system that acts is not a wrong answer on a screen. It is a wrong action in the real world, taken at machine speed, often before anyone is watching.

A board does not need to understand how a language model works to govern this well. It needs to ask a small number of containment questions — and to tell the difference between a confident answer and a good one. Containment is the discipline of bounding what an agent can do when, not if, it behaves in a way nobody intended. This piece sets out the questions worth asking, what a strong answer sounds like, and how each maps to the frameworks your risk committee already recognises: the EU AI Act, ISO/IEC 42001, and the NIST AI Risk Management Framework.

What "Going Rogue" Actually Means

"Going rogue" is an unhelpfully dramatic phrase for a set of failures that are, by now, well documented and rather mundane. An agent does not develop intent. It does something harmful because it was steered, mis-specified, or over-empowered. The security community catalogues these failures — which is the first thing worth telling a nervous board: these are known, named risks, not science fiction.

The most documented is prompt injection — instructions hidden in content the agent reads (a document, an email, a web page, a tool's response) that override what you told it to do. The OWASP Top 10 for LLM Applications, the most widely used risk catalogue in the field, ranks prompt injection as the single highest risk, and OWASP itself says it is unclear whether fool-proof methods of prevention exist — its guidance is about mitigating the impact, not guaranteeing prevention. You manage it; you do not eliminate it. We cover the mechanism in detail in our guide to prompt injection as an enterprise security risk.

The second failure mode, and the one that makes agents genuinely different from chatbots, is what OWASP's 2025 edition names excessive agency: harm an agent causes through excessive functionality, excessive permissions, or excessive autonomy — the ability to take an action it should never have been able to take in the first place. NIST's Generative AI Profile addresses generative-AI risk management more broadly.

Put the two together and the containment case states itself. You cannot fully prevent an agent from being steered, and you will often give it more power than any single step actually requires. So the governing question is not "how do we stop it going wrong" — it is "when a step goes wrong, how little can it reach?" Every question below is a version of that one.

The Containment Questions a Board Should Ask

A board does not design these controls. It asks whether they exist and listens to the quality of the answer. Six questions cover most of the ground, and for each, the strong answer is specific where the weak answer is reassuring.

1. "What can this agent actually reach — and what would it reach if it were compromised?" A strong answer names the specific systems, data, and actions the agent can touch, scoped to the minimum its job requires, read-only wherever it only needs to read. The blast radius is written down. A weak answer describes how capable the agent is rather than how bounded it is; "it has access to everything it might need" is the answer to worry about. Least privilege is not a technical nicety — it is the single biggest lever on how much damage one compromised step can do.

2. "What can it do without a human, and what must always wait for one?" A strong answer draws a clear line: reversible, low-stakes actions run autonomously, while irreversible or high-value ones — moving money, deleting records, committing the organisation to an outside party, anything expensive to undo — pause for a named human to approve, with that approval designed into the system rather than bolted on afterwards. The EU AI Act makes human oversight of high-risk systems a hard requirement (Article 14), not an optional safety net. A weak answer treats the human gate as a feature to add later, or cannot say which actions are gated at all.

3. "Can we stop it, and does it have a ceiling?" A strong answer describes a stop that actually works — a way to halt the agent, or the whole fleet, quickly — and hard limits it cannot exceed: a spend cap, a rate limit, a bounded set of permitted actions, all enforced outside the model so that no cleverly-worded input can argue past them. A weak answer assumes the agent will behave because it was instructed to. Telling an agent its budget is not a control; enforcing that budget in code the agent cannot reach is.

4. "If it did something wrong, could we reconstruct what it did and why?" A strong answer points to logging at the level of the decision, not just the output — what the agent saw, what it decided, which tools it called and with what inputs — retained long enough to investigate. The EU AI Act requires high-risk systems to support exactly this kind of automatic record-keeping (Article 12) and to retain the logs. A weak answer records the final result and nothing of the path to it. If you cannot answer "why did it do that?" after the fact, you can neither govern the system nor report on it.

5. "How do we know it is safe before launch — and how would we know if it stopped being safe?" A strong answer covers both sides: adversarial testing before deployment — red-teaming the agent against injection and misuse — and continuous monitoring after it, because an agent's behaviour drifts as the world and its inputs change. The EU AI Act frames the second half as post-market monitoring for high-risk systems (Article 72). A weak answer tests once, in demo conditions, and assumes the result holds forever. Most agentic systems pass the demo and fail in production precisely because the two environments are not the same.

6. "Who owns this agent's decisions, and what happens the day it causes harm?" A strong answer names an accountable owner — a person, not a committee — and points to an incident-response process built for AI: how a failure is detected, contained, communicated, and remediated, and who decides. Where a failure meets the Act's threshold for a serious incident, providers of high-risk systems are required to report it to regulators (Article 73), so the reporting path belongs in the plan rather than being improvised under pressure. A weak answer locates accountability in "the AI" or "the vendor." An agent's actions are the organisation's actions; accountability cannot be outsourced to the thing that acted.

Mapping to the Frameworks Your Board Already Recognises

None of this is new governance. It is existing governance applied to a system that acts — which means the containment questions above are also, in large part, the evidence these three frameworks ask for.

The NIST AI Risk Management Framework organises the work into four functions — govern, map, measure, and manage — and its Generative AI Profile (NIST AI 600-1) extends them to generative AI systems. The containment questions sit naturally across them: mapping what can go wrong and what the agent can reach, measuring through testing and monitoring, managing through gates and limits and a stop — all under the accountability that govern demands. Our plain-English NIST AI RMF guide walks through the functions.

The EU AI Act (Regulation 2024/1689) makes several of these obligations legally binding for high-risk systems: a risk-management system (Article 9), automatic record-keeping (Article 12), human oversight (Article 14), post-market monitoring (Article 72), and serious-incident reporting (Article 73) — backed by a penalty regime (Article 99) that reaches, for the most serious violations, up to €35 million or 7% of global annual turnover. Whether your systems fall into the high-risk tier is a classification exercise worth doing early; our high-risk classification guide covers how and the timeline that applies.

ISO/IEC 42001:2023, a certifiable AI management system standard, frames containment not as a one-time project but as an organisational discipline — governance roles, risk treatment, operational controls, and continual improvement — that an external auditor can certify. For a board, certification is a credible, independent signal that the discipline genuinely exists rather than living in a slide. We cover it in our ISO/IEC 42001 guide.

The point of naming the frameworks is not to turn a board meeting into a compliance review. It is that a board asking the containment questions and a board asking "are we ready for these frameworks" are asking the same thing in two languages.

What Good Looks Like

The organisations that govern agents well are not the ones with the most sophisticated models. They are the ones that can answer the six questions crisply, in specifics, without reaching for reassurance. They have written down each agent's blast radius, drawn the line between what runs autonomously and what waits for a human, built limits and a stop that actually work, logged the decision path, tested before launch and monitored after it, and named an accountable owner with an incident plan behind them.

If there is a single question for a board to put on every agent deployment, it is the containment question in its plainest form: when this agent does the wrong thing — and over enough time, one will — what is the worst it can reach, and who is accountable for that answer? A team that can answer that in one clear sentence has done the governance. A team that cannot has more work to do before the agent should be allowed to act.