UK operational resilience rules treat an AI agent as a dependency of every important business service it supports. Firms must map it, along with its model provider and platform, and show through severe but plausible scenarios that the service stays within its impact tolerance when the agent fails. For agents, "fails" includes being wrong at scale, not only being unavailable.
What do the UK rules require, in plain words?
The PRA and FCA require firms they supervise to be operationally resilient. In substance, firms must:
- identify their important business services: those whose disruption could cause intolerable harm to customers or market integrity, or threaten the firm's safety and soundness or financial stability;
- set an impact tolerance for each: the maximum tolerable level of disruption, usually expressed as a time limit and sometimes with other measures;
- map the people, processes, technology, facilities and information that support each service;
- test their ability to stay within tolerance under severe but plausible scenarios, and fix the vulnerabilities found;
- keep a self-assessment, approved by the board, and plan how to communicate during disruption.
These sit alongside expectations on outsourcing and third-party risk, and a regime giving regulators direct oversight of certain third parties critical to the financial sector. The Basel Committee's principles on operational resilience take a similar approach internationally; see the Basel principles and AI agents.
Who does it apply to?
Banks, building societies, PRA-designated investment firms and insurers, and a wide range of FCA-authorised firms including payment and e-money firms, depending on their type. Important business services are chosen by the firm, so agents fall in scope whenever they support one.
What does resilience mean when a service depends on an agent?
Most resilience planning imagines a system going down. Agents introduce failure modes where the service stays up and does the wrong thing.
Unavailable. The model provider or agent platform has an outage. Work stops or queues. This is the familiar case.
Wrong at scale. The model provider updates its model and the agent begins misreading a common request type. Thousands of customers receive incorrect answers or actions before anyone notices. The service looks healthy by every uptime measure, but customers are being harmed. Impact tolerances defined only in hours of downtime miss this.
Manipulated. A campaign of injected instructions in emails or documents targets the agent. If its limits hold, the result is a surge of refused and held actions that swamps the people who review them.
Runaway. An agent loops, calling tools repeatedly, consuming capacity or creating duplicate actions.
Fallback shrinks. This one is easy to miss. The usual fallback for an agent failure is to return work to people. But if the agent replaced most of the people who did the work, fallback capacity has shrunk. A scenario test that assumes staff can absorb the load needs to check that the staff exist.
How do you test that you stay within tolerance?
Take an illustrative case. A UK payments firm's important business service "resolve failed payment queries for retail customers" relies on an agent that handles most queries. Its impact tolerance is a maximum delay before harm becomes intolerable. The firm runs four scenarios: model provider outage for a full day; model update that halves the agent's accuracy on one query type; injection campaign through customer emails; and agent loop creating duplicate refunds. The first test shows the remaining operations team cannot clear the backlog within tolerance, so the firm cross-trains another team and keeps a second model provider qualified. The second shows the firm needs daily fixed-case replays to catch silent accuracy loss. The fourth confirms action caps stop duplicates.
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Identify important business services | Services reviewed for agent dependency | Service list with agent dependencies |
| Impact tolerance | Tolerances that cover wrong outcomes as well as downtime | Tolerance statements |
| Mapping | Agent, model provider, platform, connectors and reviewers mapped per service | Resilience maps |
| Scenario testing | Outage, silent degradation, manipulation and runaway scenarios | Scenario test reports |
| Fallback capacity | Staff capacity tested against the load the agent carries | Capacity test results |
| Detection | Fixed-case replay and outcome monitoring to catch silent failure | Monitoring reports |
| Containment | Ability to cut agents to drafting or stop them quickly; action caps | Configuration; test of stop procedure |
| Third parties | Model provider and platform managed with exit and substitution plans | Third-party file; exit plan |
| Self-assessment | Agent dependencies covered in board-approved self-assessment | Self-assessment document |
What will the PRA or FCA ask?
- Which important business services depend on agents?
- Do your impact tolerances capture harm from wrong outcomes, not only outages?
- What happens if your model provider fails or changes its model?
- Can your staff absorb the agent's workload within tolerance?
- How quickly can you stop or restrict an agent, and who decides?
What do the UK rules not cover?
They do not tell you how accurate an agent must be or how to validate it; model risk expectations do that, and much of the work overlaps, as we argue in model risk rules already cover AI agents. They do not apply to EU entities, which face DORA's testing requirements; see DORA digital operational resilience testing for agents, and for the broader divergence, how AI rules differ between the UK and EU. For the full map, see our guide to AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Pryme gives containment that works in a scenario test. An agent's depth can be cut on the same day, an Attest run that clears no depth drops an agent to depth 1, and actions above the customer's limits are held or refused rather than executed. Every verdict is filed, so a firm can show what the agent did during disruption.
Questions people ask
Is a model provider a critical third party?
The UK regime for critical third parties depends on designation by the government. Whether or not a provider is designated, a firm must manage its own dependency on it as part of resilience and third-party risk management.
Should impact tolerances be written for wrong outcomes?
For services that depend on agents, it is wise. A tolerance expressed only as time offline will not trigger when an agent keeps running but harms customers. Adding a measure of incorrect outcomes closes the gap.
How often should agent scenarios be tested?
As part of the regular resilience testing cycle, and again after material changes such as a new model provider or a large increase in the agent's share of a service.