CPS 230 treats an AI agent that runs part of a process as a source of operational risk like any other. APRA-regulated entities must identify the risks the agent introduces, design and test controls around it, manage changes to it, handle its incidents and keep critical operations within tolerance if it fails. The board stays ultimately accountable.
What does CPS 230 require, in plain words?
APRA's Prudential Standard CPS 230 sets how regulated entities manage operational risk. It is technology-neutral: it does not mention AI, and it does not need to. Its duties, described in substance, fall into three groups.
The first is operational risk management. An entity must identify and assess its operational risks, maintain controls that keep them within appetite, regularly test that those controls work, and remediate weaknesses. Risk must be considered when processes, products or systems change.
The second is business continuity. The entity identifies its critical operations, sets tolerance levels for how much disruption it will accept, and keeps a credible plan to stay within them. The third is service provider management, covering arrangements the entity relies on. Our pieces on critical operations and service providers and agent platforms take those two in turn. This piece is about the first.
Who does CPS 230 apply to?
It applies to entities APRA regulates: authorised deposit-taking institutions, general, life and private health insurers, and registrable superannuation entity licensees. Requirements are scaled, with larger entities expected to meet more of them in more depth.
Within those entities, the board is ultimately accountable for operational risk, and senior management is responsible for running the framework. An entity's AI programme is therefore inside CPS 230 whether or not the programme team thinks of it that way. For the short answer, see how CPS 230 applies to AI agents.
What changes when an agent runs part of a process?
A process run by people has controls that rely on people: training, supervision, four-eyes checks. Replace one step with an agent and some of those controls disappear. The standard expects the entity to notice and replace them.
Three agent-specific risks need to be in the risk profile. The agent can act outside its intended scope, for example processing a hardship variation it was only meant to summarise. Its behaviour can drift without any code change, because the underlying model or its sources change. And it can fail at scale: one wrong instruction applied to every case in a queue.
Each risk needs a control that operates at the moment of action, not only a policy. That is why we argue agent governance belongs with operational risk, not only IT. Change management is the other gap. A provider updating the model behind an agent is a change to the process, even if no one in the entity touched it.
How do you meet CPS 230 operational risk duties for agents?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Identify and assess operational risks | Agents and their capabilities listed in the risk profile, with scope, drift and scale risks assessed | Risk register entries linked to each agent |
| Maintain controls within appetite | Each action checked against role scope, certificate, sources, entity limits and platform guardrails | Verdict filed per action, naming the deciding bound |
| Test control effectiveness | Agents certified on the entity's own cases, with certificates that lapse and are re-run | Certification results, pass floors and renewal dates |
| Remediate weaknesses | A certification run that clears no depth drops the agent to read-only the same day | Depth change records and remediation actions |
| Manage change | Model, source or permission changes trigger re-testing before use | Change records with test evidence attached |
| Manage incidents | Agent incidents logged, assessed and escalated like any operational incident | Incident records and root-cause analyses |
| Board oversight | Regular reporting on agents, incidents and control testing to the board or its risk committee | Board and committee papers |
Control testing is where agents differ most from human processes. A one-off test at launch tells you little about behaviour six months later. Re-running the same certification on fresh cases at a fixed interval gives the evidence the standard asks for.
What will APRA or internal audit ask?
- Where do agents appear in your operational risk profile, and who owns each risk?
- Which controls stop an agent acting outside its intended scope, and when were they last tested?
- How do you detect drift in an agent's behaviour?
- What counts as a change to an agent, and who approves it?
- Show us the last agent incident and how it was handled.
- What does the board receive about agents, and what has it asked?
A framework such as the NIST AI Risk Management Framework can help structure the answers, but APRA will judge the controls, not the framework you cite.
What does CPS 230 not cover?
It does not set rules on fairness, explainability or consumer outcomes; ASIC's conduct regime and the Privacy Act 1988 address those. It does not certify any particular AI method as safe. It does not move accountability to a vendor: an entity that uses a provider's agent still owns the operational risk. And it does not tell you how much autonomy to grant; that is a risk appetite decision. See AI agent regulation, mapped to controls for how the other regimes fit.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Pryme enforces bounds at the moment of action and files each verdict, so control operation is recorded continuously rather than sampled. Attest certificates lapse after 90 days and a run that clears no depth drops the agent to depth 1 the same day, which gives a regular, evidenced test of control effectiveness.
Questions people ask
Is an AI agent a separate operational risk category under CPS 230?
No. The standard does not create AI categories. Agents create operational risks such as process error, scope breach and system failure, which fit within your existing taxonomy with agent-specific causes added.
Does a model update by the provider count as a change?
For control purposes, yes. The agent's behaviour can change even if your configuration does not, so treat provider updates as changes that need testing before reliance.
Do superannuation trustees need to apply this to member service agents?
Yes. Registrable superannuation entity licensees are within CPS 230, and an agent handling member enquiries or transactions is part of their operations.