Any critical operation under CPS 230 that an AI agent helps deliver must be mapped through the agent, its model provider, its sources and its approvers, and its tolerance levels must hold when the agent stops or behaves wrongly. Set tolerances for time, data loss and minimum service, then prove a fallback without the agent meets them.
What does CPS 230 say about critical operations?
In substance, APRA's operational risk standard asks each regulated entity to identify its critical operations: the processes whose disruption would have a material adverse effect on depositors, policyholders, members, or the entity's role in the financial system. APRA expects some common operations, such as payments for a bank or claims handling for an insurer, to be treated as critical unless the entity can justify otherwise.
For each critical operation the entity sets tolerance levels: the longest disruption it will accept, the most data it will accept losing, and the minimum level of service it must keep during disruption. It then keeps a business continuity plan that shows how it stays within those levels, and tests that plan against severe but plausible scenarios.
The wider operational risk duties are covered in CPS 230 and AI agents: operational risk management.
Who has to identify and protect critical operations?
All APRA-regulated entities: authorised deposit-taking institutions, insurers and superannuation trustees, with expectations scaled to size and complexity. The board approves the critical operations and tolerance levels; senior management makes them work.
Agents raise the stakes for smaller entities in particular. A small insurer that moves first notice of loss to an agent may find its whole claims intake now depends on one system and one provider, a concentration that did not exist with a team of people.
How do agents change the mapping of a critical operation?
The standard expects entities to understand the people, processes, technology, information and service providers each critical operation depends on. An agent adds several layers that are easy to miss.
Map at least these for every agent in a critical operation:
- The agent itself and each capability it uses in the operation.
- The model provider behind it, and any fallback model.
- The sources it reads, and where each comes from.
- The systems it writes to and the credentials it holds.
- The people who approve its held actions, and how many of them there are.
- The certification that permits its current depth.
The last two are specific to agents. If the agent drafts and people approve, approver capacity is part of the operation. And if a certificate lapses or a run fails, the agent may lose authority the same day, which is a disruption you created on purpose and must plan for.
How do you set tolerances when an agent is in the path?
Set tolerances from the customer's side, then test them with the agent removed. Two failure modes matter.
The first is the agent stopping: the model provider is unavailable, the agent is paused after an incident, or its authority drops. The tolerance question is whether people can pick up the work within the maximum disruption period. Often they can at reduced speed, so the minimum service level is where the test bites.
The second is the agent running but wrong. A claims agent that misreads policy wording keeps processing, and the disruption is to the integrity of outcomes rather than availability. Tolerance for data loss and integrity should cover how many wrong outcomes can occur before detection and how far back you can reconstruct them.
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Identify critical operations | Agent dependencies recorded in the critical operations register | Register entry listing agent, provider, sources and approvers |
| Set tolerance levels | Tolerances defined for agent-down and agent-wrong scenarios | Board-approved tolerance statements |
| Maintain minimum service | Documented fallback: agent drops to drafting or read-only, people complete the work | Runbook and staffing model for fallback mode |
| Limit data and integrity loss | Every agent action filed with its verdict in an append-only record | Record extracts used to reconstruct affected cases |
| Test continuity | Scenario tests: provider outage, mass depth drop, injected instructions in sources | Test reports with time to recover against tolerance |
| Detect disruption early | Monitoring of refusals, held volumes and error rates against thresholds | Alerts and incident tickets |
What will APRA or an auditor ask?
- Which critical operations depend on an agent, and what proportion of the work does it do?
- If the agent stopped now, how long until you breach tolerance, and how do you know?
- How many approvers do you need in fallback, and do you have them?
- Have you tested a scenario where the agent keeps running but produces wrong outcomes?
- How quickly could you identify every case the agent handled in a given window?
- Who in the business owns each tolerance level?
Service provider questions follow naturally, covered in CPS 230 service providers and AI agent platforms.
What does this part of CPS 230 not cover?
It does not require you to avoid agents in critical operations. It requires you to stay within tolerance when they fail. It does not set the tolerance numbers; the board does. It does not address whether the agent's outcomes are fair or lawful, which falls to conduct and privacy law. And it does not replace your obligations under the rest of the standard. For a short answer on scope, see how CPS 230 applies to AI agents, and for the cross-regime view, AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Should an agent be the only way to deliver a critical operation?
It should not be the only tested way. Keep a documented, staffed fallback, even if slower, and prove in testing that it keeps you within the minimum service level.
Does a planned depth reduction count as a disruption?
If it slows a critical operation, yes. Treat certificate lapses and failed runs as foreseeable events and plan staffing for the period the agent is drafting rather than executing.
How often should agent scenarios be tested?
At least as often as the rest of the business continuity plan, and again after material changes such as a new model provider or a big increase in the share of work the agent does.