Agent governance belongs with operational risk, not only IT

Agents act on business processes: they draft replies, prepare journals, hold payments and update records. When they fail, the result is a process failure, so their risks belong in the operational risk framework alongside the processes they touch. IT still runs the infrastructure, but treating agents purely as technology leaves the business risk without an owner.

Why do agent failures look like operational losses?

Consider what goes wrong when an agent fails. A support agent promises refunds outside policy, and the firm pays them. A finance agent posts an accrual to the wrong account, and the management accounts are misstated. A payments agent acts on a fraudulent bank detail change, and money is lost. A complaints agent misses that a message was a complaint, and a regulatory deadline passes.

None of these is an IT incident in the usual sense. The systems were up. Nothing was hacked. The failures are errors in the execution of business processes, which is the core of what operational risk frameworks exist to manage: losses from inadequate or failed processes, people and systems, or from external events.

An agent sits across all three of those. It is a system, it does work that people used to do, and it carries out processes. Its risks fit operational risk far better than they fit a technology risk register.

What does IT ownership miss?

IT and security teams are well placed to manage some agent risks: availability, access control, data security, integration failures, and the security risks set out in frameworks such as the OWASP Top 10 for LLM Applications. Those matter and should stay with IT.

What they are not placed to judge is whether the agent is doing the business process correctly. Is the refund policy being applied fairly? Are the journals right? Are complaints being recognised? Those questions need people who know the process, the customer and the regulatory expectations. When governance sits only in IT, they tend to go unasked, or are asked once at launch and then forgotten.

There is also a reporting problem. IT risk reporting usually goes to a technology committee. Operational risk reporting goes to the risk committee and the board. If agent risks are reported only through IT, the people responsible for overall risk appetite may never see them.

What does operational risk bring?

Mature operational risk frameworks already contain the tools agents need:

• Process ownership: every process has an owner who answers for its risks. Agents working in that process inherit that owner.
• Risk and control self-assessment: owners regularly assess the risks in their processes and the controls that address them. Agent bounds, certificates and holds are controls to assess.
• Loss and incident recording: failures are logged, root causes found and patterns tracked. Agent failures should go into the same log.
• Key risk indicators: measures that warn of rising risk. Agents produce excellent indicators, if anyone looks.
• Scenario analysis: severe but plausible events are explored in advance. "An agent's certificate lapses silently and it keeps acting" is a good scenario.

Much of this is reinforced by regulation. The Basel Committee's principles on operational resilience, DORA's requirements on ICT risk management in the EU, and APRA's CPS 230 on operational risk management in Australia all push firms towards managing technology-enabled processes as operational risks, with business ownership.

How do agent risks map into an operational risk framework?

AI governance as a discipline has many parts. For agents specifically, most map cleanly onto existing operational risk categories.

Each row can sit in the firm's existing risk register, owned by the relevant process owner, with controls assessed alongside everything else. The integration work is covered in how to connect an AI agent to your governance, risk and compliance platform.

Where does model risk sit?

Banks in many markets already supervise model risk separately. In the UK, the PRA's SS1/23 sets model risk management principles for banks, including clear ownership and validation. Agents that rely on models fall partly within that frame, and the question of who owns them is explored in PRA SS1/23 governance and model risk owners for agents.

The two frames complement each other. Model risk management asks whether the model is sound for its purpose. Operational risk asks whether the process using it works. An agent can rely on a sound model and still fail operationally, because its bounds were wrong or its sources stale. Both views are needed.

Which indicators should be reported?

Indicators that show whether agents are staying within their bounds and whether their evidence is current. The most useful are often the least obvious: held and refused verdicts by bound, certificates lapsing or failing, drift alerts, and complaints about agents. The argument that firms should count what an agent refuses, not only what it completes applies directly. Completion counts tell you the agent is busy. Refusal counts tell you where it is pressing against its limits.

What should you do differently?

Ask where your agents appear in the risk register. If the answer is "under IT", move the process risks to the process owners and keep the technology risks with IT. Add agent controls to self-assessments, agent failures to the incident log, and agent indicators to risk reporting. The broader case for this is made in what AI agent governance is and in agent governance is a bound, not a model.

Where Pryme fits

In Pryme, each agent's verdicts name the bound that decided them, so held, refused and withheld actions can be reported as operational risk indicators by process. Certificate status and drift alerts are available for each agent. That gives process owners the evidence they need to assess agent controls inside their existing framework.