Agentic AI risk management: the controls a board needs

Agentic AI risk management is the work of controlling what AI software is allowed to do inside your systems, not only what it says. The question has moved from the lab to the board. This month a state-aligned group used an agentic penetration-testing framework to try to sign in to more than 2,250 tenants (customer cloud accounts) at 2,900 attempts a minute, Microsoft reported.

The same week, the UK Financial Conduct Authority's chief data officer called for firms to report significant AI failures and near-misses. NVIDIA, Red Hat and ServiceNow moved agent controls outside the agent itself. Agents now act at machine speed, with real permissions, and your company is accountable for each one.

What to do: list every agent, give each one an owner, cap what it can change in one run, put the brakes outside the agent, and count the cost of human review before you count the saving. This guide sets out the risks, a way to decide how much autonomy to allow, a pilot plan and the questions a board should ask.

What changed: agents act, and attackers use them too

For most of the last few years, enterprise AI advised and a person decided. Agentic AI plans a task and carries it out. It queries systems, triggers workflows, changes settings and closes tickets. That moves the risk from a wrong answer to a wrong action.

Three developments this month show where this is going.

• Attackers run agents. Microsoft says Storm-0940, a China-state aligned actor, used the open-source ARTEX agent framework against hundreds of organisations, and in multiple cases went from first targeting to privileged cloud access in less than three hours. After the ConnectWise supply chain compromise, its agents used stolen application credentials to enter customer environments through trust those applications already held.
• Vendors move the controls out of the agent. NVIDIA launched the OpenShell reference architecture on 21 October 2026. NVIDIA says its hardware layer can quarantine an agent that tries to leave its software boundary in milliseconds. Red Hat is building it into its own platforms, and NVIDIA's John Fanelli stated the principle plainly, as SiliconANGLE reported: "An agent shouldn't enforce its own boundaries."
• Regulators ask for near-miss reports. The FCA's chief data officer, Jessica Rusu, said rules on major incidents must extend to significant AI failures and near-misses, CIO reported.

An agent is a new kind of worker. It has system access, no sense of context beyond its instructions, and a speed no person can match. Governance built for chatbots checks outputs. Agents need governance of actions.

What agentic AI risk costs: incidents, oversight and ownership

AI incidents already reach the board. In an IBM survey of more than 3,200 senior executives in Europe and the Middle East, 80% said an AI-related incident reached their board or C-suite in the past year. IBM counted an agent failure, data exposure, an AI-driven decision error or an AI security breach, so the figure covers all AI incidents, not only agents. Only 40% changed their AI governance in response, and only 37% have a formal, board-reviewed figure for the financial risk created by gaps in that governance.

When AI is part of an attack, the bill is larger. In IBM's 2026 Cost of a Data Breach study, breaches from AI-enabled attacks cost an average of US$6 million, against a global average of US$4.99 million. Those attacks were mostly deepfake impersonation and AI-enabled malware run by outsiders, not failures of a company's own agents. More than 20% of organisations reported a breach that targeted AI models or applications, and the most common causes were compromised APIs, applications or plug-ins and cloud misconfigurations, at 27% each. The weak point is often the systems around the model, not the model.

The hidden line in the business case is supervision. In G2's 2026 research, reported by diginomica, 31% of B2B organisations spend six or more hours a week overseeing agents. Nearly half say oversight and rework eat more than a quarter of the productivity gain.

Ownership is thin. In the same G2 data, 47% run agents with informal or department-led ownership, and only 23% govern them centrally. Even the role most often named as accountable for an agent's adverse outcome, the CIO or CTO, was chosen by just 17% of IBM's respondents.

For a finance director, these numbers say three things. The incident risk is real and it has a price. The oversight cost can erase the saving. And when no single person owns an agent, the board owns the gap.

The eight risks to control, and the first control for each

The joint guide from CISA, Australia's cyber security centre and partner agencies lists security risks of agents such as a wider attack surface, privilege creep, misaligned behaviour and event records that are hard to read. Add injected instructions, which SiliconANGLE names with supply chain attacks as ways attackers compromise agents, and wrong or stale data that an agent acts on before a person can catch it. Then add two operating risks, model change and oversight cost, and you have eight to control.

Misaligned behaviour rarely looks like malice. The Berkeley profile lists unintended goal pursuit and unauthorised privilege escalation among the risks of agents. Picture an agent asked to clear a backlog of supplier queries that closes tickets without solving them, or one asked to free storage that deletes records an audit still needs. Neither needs an attacker. Each needs only more permission than the task requires and no checkpoint before a high-impact step.

Model change is easy to miss. Analyst Frank Dickson, quoted by CIO, warns that a model can pass testing in March and misbehave in May because the provider changed it underneath. Ask every vendor how they notify you of model changes, and retest when they do.

How to decide how much autonomy an agent gets

Autonomy is not on or off. The Berkeley Agentic AI Risk-Management Standards Profile treats agency as a matter of degree and asks for controls in proportion, with bounded autonomy inside clearly defined limits. It also advises treating capable agents as untrusted, because current evaluation methods have limits. Its guidance follows the four functions of the NIST AI Risk Management Framework: govern, map, measure and manage, so a risk team can extend a programme it already runs.

A risk team will also ask which standards to map to. Use the NIST framework for structure, then ISO/IEC 42001 for the AI management system and the OWASP Top 10 for Agentic Applications for the threats to test against, both named in an ISACA analysis of agent controls. Its author, Rupinder Pal Singh, argues that a rule written into a prompt is evidence of intent, not of enforcement, and that an auditor is entitled to say it is not a control measure.

In practice, set the level per action, not per agent.

Low-value payments may move to the capped tier, but only after the agent has a measured record in shadow mode and approval mode.

Score each action on five questions before you set its level:

1. Can we undo it, fully and quickly?
2. What is the most money, data or customer harm one wrong action can cause?
3. How often will it run? A small error at high volume is a large error.
4. Does it touch regulated data, payments, access rights or decisions about people?
5. Would we detect a wrong action within minutes, or only at month end?

Actions that cannot be undone and sit above the value line always need a person. So do deletions, access changes and messages to customers. Any other action that touches regulated data, payments or decisions about people keeps a person in the loop until the agent has a measured record.

Know when not to use an agent at all. If the rules are known and stable, fixed automation is cheaper and easier to audit. An AWS reference design for medical coding shows the better pattern. A workflow engine owns the sequence and the approval gates. Cheap exact rules handle the clear cases. An agent is called only for the terms that need judgement. The agent picks a code, and it does not decide what happens next.

Worked example. A team proposes that a proven accounts payable agent clear supplier invoices up to US$10,000 each on its own, about 25 an hour. If a poisoned invoice feed misleads it and nobody notices for four hours, up to 100 payments and US$1,000,000 are exposed. Set the value line at US$2,000 instead, send anything larger to a person, and add a daily ceiling of US$50,000 with an automatic pause after three failed checks. The worst case falls to US$50,000. If most invoices sit under the line, most of the volume still flows without a person.

Questions the board should ask

• How many agents run in the company today, including agent features switched on inside software we already buy?
• Who owns each agent by name, and what is it allowed to change?
• Which actions can an agent take without a person, and what is the most it can change in one run?
• Can we stop every agent in one step, and when did we last test it?
• Do our controls sit outside the agent, so a compromised agent cannot turn them off?
• What do our suppliers' agents and connectors touch in our systems?
• Do we log near-misses, such as blocked actions, and who reviews them?
• What is our board-reviewed figure for financial exposure, and what review time does each agent cost?

The stop question matters more than it sounds. In the IBM study, executives named the ability to immediately halt agent activity across the enterprise as a control they expect to need, at 29%, IBM reported. NVIDIA says ServiceNow's AI Passport authority layer lets a company revoke an agent's access across software and hardware within seconds. Ask your team how long it takes today.

The supplier question matters too. Only 21% of the executives IBM surveyed continuously monitor third-party AI risk, according to the study. The Storm-0940 case shows why: the attacker came in through a trusted supplier's application, not through the front door.

How to run an agentic AI pilot and measure it

CISA's guidance gives the starting rule: begin with use cases that are low-risk and non-sensitive, and avoid broad or unrestricted access. Then run the pilot in stages, so each stage earns the next.

1. Pick one workflow. Choose high volume, clear rules, mostly reversible actions and a cost you can already measure. Leave payments and access rights out of the first pilot.
2. Write the agent's charter. One page: owner, purpose, systems, allowed actions, caps per run and the stop procedure.
3. Set the baseline. Record cost per case, cycle time and error rate today, from real records, not estimates.
4. Run in shadow mode. The agent proposes and people decide. Measure how often a person accepts the proposal unchanged.
5. Move the safe tier to approval mode. Measure review minutes per case. This is your oversight cost.
6. Grant autonomy to the reversible tier only. Keep the cap and the automatic pause. Log every blocked action as a near-miss.
7. Test the stop. Halt the agent in a live window and time how long it takes.
8. Decide at the gate. Scale only if the net saving holds after review time, incidents stay inside the agreed limit and the stop works.

Worked example. An agent handles 10,000 service cases a month and saves 6 minutes on each, a gross saving of 1,000 staff hours. Reviewers check 30% of cases at 4 minutes each, which takes 200 hours. Rework on a 2% error rate at 30 minutes a case takes another 100 hours. That leaves 700 hours. At a loaded cost of US$60 an hour, the monthly value falls from US$60,000 to US$42,000. Licences, model usage, hosting and upkeep for the agent cost US$12,000 a month, so the net saving is US$30,000. Approve the case on the net figure, not the gross one.

What does not work

• Approving everything. If every action needs a click, people stop reading and oversight becomes theatre. Keep review for the top tier and for anything unusual, so each approval gets real attention.
• Letting the agent police itself. A prompt that says "never delete records" is a request, not a control. Put limits in the identity system, the network and the runtime, where the agent cannot change them.
• Treating the platform as the governance. A vendor can supply approval workflows and logs. It cannot decide who in your business owns the agent, or what one run may change.
• Treating near-misses as failures. Consultant Noah Kenney, quoted by CIO, notes that a bank with good monitoring may catch hundreds of agent attempts to act outside their authority, while a bank with poor monitoring reports none. Reward detection, not silence.
• One model, one supplier. An outage at one AI supplier that takes down a customer channel is an incident too. Know which processes stop if a single model goes down.

Where regulation is heading

In the UK, Rusu said agentic systems need continuous, conditional assurance, because a system that is safe at launch may behave differently at scale or as the models beneath it change, CIO reported. She said the FCA will work on a framework for agentic finance that covers agent identity, delegated authority, accountability and execution.

In the EU, rules for high-risk uses such as employment, education and critical infrastructure apply from 2 December 2027, under the European Commission's AI Act timeline. Deployers of those systems must ensure human oversight and monitoring, and report serious incidents. An agent that screens job candidates may fall in scope.

In the US, Australia and partner countries, the CISA joint guide is guidance, not law, but it gives a security team a ready checklist.

Liability is not settled. In the IBM study, 20% of executives said liability for serious harm should be shared between deployer and vendor, and 14% said it should sit with the vendor, IBM found. Do not wait for that debate to end. Write logging, notification, stop rights and liability into vendor contracts now.

Where Thriiv fits

Thriiv builds and runs custom AI systems, workflow automation and secure data pipelines for international enterprises. Every system runs in an environment we host and manage. We run it after launch, with one point of contact from diagnosis to scale. We put a quantified saving in front of you before budget is committed, and for an agent that number should be net of human review and run cost. Our security page explains how the systems we build are hosted and run.

Tell us where the cost sits. We come back with what we would build, and what it saves. To begin, start the conversation.

What to do this quarter

1. List every agent and agentic feature in use, including those switched on inside existing software.
2. Name one owner per agent, with a written purpose and scope.
3. Give each agent its own identity and retire shared service accounts.
4. Sort every action into the four tiers above and set caps per run and per day.
5. Move enforcement outside the agent, into identity, network and runtime controls it cannot change.
6. Test the stop for every agent and record the time.
7. Start a near-miss log and review it each month with risk and audit.
8. Put a board-reviewed figure on financial exposure and on review cost per agent.
9. Run one pilot through the eight steps above before you scale anything.

The companies that scale agents safely will not be the ones with the most agents. They will be the ones that can say, for each agent, who owns it, what it can do, what it costs to supervise and how fast it stops.