APRA and frontier AI models for banks, insurers and super funds

APRA expects banks, insurers and superannuation trustees to manage frontier AI models on two fronts. The first is the cyber threat those models pose to every entity, whether or not it uses them. The second is the dependency an entity takes on when its own systems, or its vendors’ systems, run on one. Both sit inside CPS 230 and CPS 234 rather than a new standard. This guide covers what APRA has said about frontier models since April 2026 and the work it implies. The wider expectations of the letter are covered in the APRA AI expectations guide and on the framework page.

What APRA has said about frontier models

APRA’s letter to industry on AI of 30 April 2026 said APRA was engaging across the sector on the risk that high capability frontier models such as Anthropic Mythos could increase cyber threats, and asked entities to review current advice from the Australian Signals Directorate (ASD) on frontier AI models. In its supplier findings the letter said some entities were heavily dependent on a single provider for multiple AI use cases. Few had tested contingency plans or exit and substitution strategies, and contracts often lacked audit rights, notice of model updates, incident notification and terms on changes to data handling. It also named foundation models, training data sources and fourth-party providers as upstream dependencies that are often opaque.

On 24 June 2026 APRA’s Therese McCarthy Hockey told the AFIA Risk Summit that frontier AI is not just a cyber risk. It is third-party risk, concentration risk and sovereign access risk. She said a critical process or cyber defence capability relying on a single offshore frontier model could be disrupted by a regulatory decision made overseas. She asked boards to treat AI adoption like any critical dependency and to ask what their fallback is.

APRA and ASIC then ran nine roundtables in June and July 2026, supported by ASD. Their information paper lists AI model providers among the common dependencies, alongside cloud, SaaS and managed service providers, that can turn an isolated incident into sector-wide disruption.

Map which systems depend on which models

The single-provider finding cannot be answered without a list. For every AI system and agent in your inventory, record the model it runs on, the provider that serves it and the vendor whose product wraps it. Then read the list the other way round. For each model, which systems use it, and do any of them support a critical operation under CPS 230?

Most of that map comes from vendors rather than your own builds. A claims triage tool, a contact centre assistant and a code assistant may all run on the same frontier model under different brand names. That is the fourth-party dependency APRA is asking about, and it only shows up when the register records the model behind each product. The AI system register guide covers what each entry should hold.

Make substitution and fallback credible

APRA asks for tested exit and substitution strategies for critical AI providers, and credible fallback where AI supports critical operations. For a frontier model dependency, that turns into three questions for each critical system.

• Could the system run on a different model, and how long would the change take? A product built on a model-neutral interface can often switch by configuration. One tuned closely to a single model may need weeks of rework and testing.
• If no model were available, what does the operation fall back to? A manual process, a rules engine or a reduced service each need to be written down and tested.
• Does the contract give you notice of model changes, incidents and changes to data handling, so you learn about a problem from the vendor rather than the news? The vendor AI risk guide covers the terms worth asking for.

Record the answers against the system, and treat a provider advisory about a model as an event that each dependent system has to respond to.

Lift cyber controls to machine speed

The cyber side applies whether or not you use frontier models yourself. ASD and the AICD’s board considerations on frontier AI threats warn that these models can find vulnerabilities, chain low-severity weaknesses into serious compromises and act with little human oversight. APRA’s speech asked for patching and configuration management that work at machine speed. The roundtables put cyber fundamentals first, meaning asset visibility, patching, identity controls, backup integrity and tested recovery.

For the AI estate itself, that means red teaming of the deployments you run, identities for agents that can be reviewed and revoked, and monitoring that raises an alert when a system’s behaviour moves outside the limits you set.

Questions for the board

The roundtable paper ends with a preparedness checklist for boards. Its questions on dependencies ask which providers support critical operations and what happens if a common provider fails. Its governance questions ask whether escalation, shutdown, recovery and communication decisions have been made and tested before an incident. A board that can answer those for its frontier model dependencies has most of what APRA is looking for.

Where Aicura fits

Aicura’s AI Register has a Models tab that lists the models your systems and agents run on, with a Used by view showing every system that depends on each one. When a provider publishes an advisory against a model, each dependent system records its response. Vendor records class each supplier as a model provider, SaaS product, integrator or other, and sit beside the systems that rely on them. At Pro, security testing, monitoring and the OAIC, APRA and ASD notification pathways sit on the same records. Aicura gives guidance for your judgement. It does not certify or give a verdict on your prudential obligations.

Aicura has its own frontier model dependency, and it is disclosed on the responsible AI page. Aicura runs on Anthropic’s Claude models through Amazon Bedrock in Australia, with each call running in Sydney or Melbourne. Model providers cannot access prompts or completions, and customer data is not used to train models. Aicura calls Bedrock through the Converse API, which AWS describes as working with all Bedrock models that support messages, so moving to another Bedrock-hosted model is a configuration change and a smoke test. On your register, the right entry is the Aicura platform running on Amazon Bedrock in Australia, not the underlying model.

A note on this page

This is Aicura’s reading of APRA’s published statements on frontier AI. It is not legal or prudential advice. Read APRA’s letter, speech and information paper, and discuss how they apply to your entity with your advisers and your supervisor.