APRA’s 30 April 2026 letter to industry said third- and fourth-party AI is where visibility fails: supply chains are opaque, contracts lag practice, and concentration is common. Contracts and vendor registers remain necessary. Control at the integration layer is where those third- and fourth-party systems actually touch regulated data, and where evidence can be produced.
This article explains the published letter and the CPS 230 and CPS 234 standards. It is not legal or prudential advice. Readers should seek advice from their own advisers and engage their APRA supervisors.
The model the register could not see
A CISO at a regional insurer had a material-service-provider row for “enterprise AI assistant” and a signed schedule that promised audit rights. A claims manager then connected that assistant to the policy-admin API with a service account that also ran overnight batch. The register still named the assistant vendor. It did not name the fourth-party model behind the assistant, or the fact that claims records were now leaving through an unofficial integration. When internal audit asked what personal information the assistant had used in March, the answer was a vendor slide, not a call log.
APRA’s letter is about that class of gap. The standard that already required a register is CPS 230. The standard that already required information-security controls on assets managed by third parties is CPS 234. The new letter says AI has outrun how those standards are being operated.
What were APRA’s four themes in the 2026 AI letter?
Information security not keeping pace; governance lagging adoption; supplier concentration and opacity; and assurance that is too static for dynamic AI.
APRA wrote to all regulated entities on 30 April 2026 after a late-2025 engagement with selected large banks, insurers and superannuation trustees. The attachment is titled “AI Supervisory Engagement Debrief: Observations for Executive Management.” The four headings are:
- AI threats are increasing, but information security practices are struggling to keep pace. Attack paths include prompt injection, data leakage, insecure integrations and misuse of autonomous agents. Identity and access management “have not yet adjusted to nonhuman actors.” Staff use of enterprise AI tools often relies on policy rather than preventative technical controls.
- AI adoption is moving fast, but governance maturity is lagging. Entities treat AI as just another technology. APRA expects frameworks, lifecycle ownership, an inventory of tooling and use cases, human involvement for high-risk decisions, and staff training.
- Supplier risk management is in place, but supplier concentration and opacity present challenges. Heavy dependence on a single provider; weak exit and substitution; contracts that omit audit rights, model-update notice and data-handling change. Foundation models and fourth parties sit upstream and are hard to see. APRA expects entities to map and maintain visibility over the full AI supply chain, including material, third-party and fourth-party dependencies.
- Traditional change management and assurance is in place but is not sufficient for dynamic AI solutions. Point-in-time samples miss systems that change. Second line and internal audit often lack agentic skills.
Board expectations sit above those four: literacy, a strategy inside risk appetite, and monitoring that includes third-party dependencies.
What does CPS 230 require for material service providers and fourth parties?
A register, due diligence, formal agreements where practicable, monitoring, contingency and exit, and APRA notification for material arrangements.
CPS 230 Operational Risk Management is in force from 1 July 2026 (updated that day after 30 April 2026 targeted amendments). It requires the entity to manage operational risk and to remain able to run critical operations through disruption. Service-provider risk is a core part of that.
Material service providers must be identified and recorded. Fourth parties matter when the provider you hired depends on someone you did not hire – the foundation-model vendor inside an assistant, or the sub-processor inside a claims platform. The 30 April 2026 amendments created a narrow contractual exemption for certain non-traditional providers (central banks, some market infrastructures). They do not exempt AI vendors.
A register that names “Microsoft” or “the assistant vendor” and stops there does not match APRA’s letter. The letter asks for the chain.
How does CPS 234 apply to AI integrations?
It already requires information-security controls, capability assessments and assurance for information assets managed by related parties or third parties – not only formal outsourcing.
CPS 234 Information Security has been in force since 1 July 2019. Its objective includes assets managed by third parties. The entity must assess that party’s information-security capability, evaluate control design, and, where it relies on the party’s testing, assess whether that testing is adequate. Internal audit must review those controls.
An AI agent that reads policy, claims or customer records is processing those assets. Whether the model is hosted by a fourth party does not move the asset out of CPS 234. The insecure integration path APRA named in the letter is a CPS 234 path.
Why non-human identity sprawl shows up at the API
Because the new callers are apps and agents, and they share human or batch credentials.
APRA said IAM has not adjusted to non-human actors. That is the same gap non-human identity programmes hit: you can enrol the agent and still not decide what this call may do. Legacy integrations make it worse. The overnight batch account is still live. The agent inherits it. The material-service-provider register never listed that account.
A tactical, risk-reduced path for those integrations is not a rip-and-replace of the core system. It is to put the existing vendor credential behind a proxy, give the agent its own caller identity, deny everything not in the use-case grant, filter the response, and keep the record. The core system stays. The unofficial hop becomes governable. That is control at the integration layer.
The same hop is what outbound API governance names as the egress seam, and what APP 1.7 needs if the agent is making or helping significant decisions.
A risk-reduced path for a legacy integration, in order:
- Leave the core system and the existing vendor contract in place.
- Inventory unofficial agents and the service accounts they borrowed.
- Move the vendor credential to a single stored target. Stop distributing it to laptops and MCP configs.
- Give each agent its own caller identity and a deny-by-default grant that matches the approved use case.
- Filter responses so member or claims records do not arrive as full objects.
- Keep the allow/deny record for internal audit and for the CPS 230 file.
- Only then decide whether the assistant is a material service provider, a feature of an existing one, or a fourth-party dependency that belongs on the chain map.
That path does not satisfy CPS 230 by itself. It gives the accountable executive something other than a vendor slide when APRA asks what the agent did with critical-operation data.
Where RequestRocket fits
RequestRocket does not write the CPS 230 register and does not replace CPS 234 control testing. It sits on outbound calls to APIs the entity does not host: holds the vendor credential, scopes each caller, filters responses, meters use, and records allow and deny. That is evidence of what a third- or fourth-party AI integration actually did with regulated data. Identity, the inbound gateway and the secrets manager remain in place.
FAQ
Does the APRA AI letter create a new prudential standard?
No. It states observations and expectations under the existing principle-based framework. APRA said it will consider whether further policy is needed. CPS 230 and CPS 234 already apply.
Are AI vendors exempt under the April 2026 CPS 230 amendments?
The exemption is for listed non-traditional providers such as central banks and certain market infrastructures, where standardised or undocumented terms make CPS 230 contract clauses impracticable. It is not an AI-vendor exemption.
What is a fourth party in this context?
A provider your provider depends on – a foundation model, a sub-processor, an embedded developer tool – that can affect your information assets or critical operations even though you did not contract with it directly.
Is an inventory of AI use cases enough?
APRA expects that inventory. It also expects preventative controls, not only policy, for staff and agent use, and visibility over the supply chain. An inventory without a call-level record will not answer “what did the assistant do to the policy API”.
How should we treat legacy service accounts used by new agents?
Treat the agent as a new caller. Do not expand the batch account. Put a scoped identity and a deny-by-default grant on the hop the agent actually uses.
Should we notify APRA about our AI assistant?
Notification duties follow the standards and your supervisors, not this article. The letter encourages early engagement with APRA’s Non-Financial Risk Team via your supervisors where risk management is challenged.
Book a walkthrough of RequestRocket
Sources
- APRA, Letter to Industry on Artificial Intelligence (30 April 2026)
- APRA, CPS 230 Operational Risk Management (in force 1 July 2026)
- APRA, Final targeted amendments to CPS 230 (30 April 2026)
- APRA, CPS 234 Information Security (in force 1 July 2019)
- APRA, CPG 234 Information Security