APRA CPS 234 & AI: Securing AI Models, Pipelines and Inference APIs

Yes. APRA Prudential Standard CPS 234 (Information Security) applies to AI even though the word "AI" never appears in the text - because AI models, training and fine-tuning data, vector and embedding stores, and inference/API endpoints are all "information assets" within scope. CPS 234 defines an information asset as "information and information technology, including software, hardware and data (both soft and hard copy)", which squarely captures the modern AI stack.

CPS 234 has been in force since 1 July 2019 and binds every APRA-regulated entity - authorised deposit-taking institutions (ADIs), general and life insurers, private health insurers, and registrable superannuation entity (RSE) licensees - along with their service providers. It requires a regulated entity to maintain an information security capability commensurate with the threats it faces, clearly define information-security roles and responsibilities up to and including the Board, classify and protect information assets in line with their criticality and sensitivity, systematically test control effectiveness, and notify APRA of material incidents and control weaknesses (APRA, Information Security).

The practical consequence for banks, insurers and super funds is that deploying a large language model, a retrieval-augmented generation (RAG) pipeline, or a customer-facing inference API does not create a regulatory gap - it extends an existing one. Each AI component must be inventoried, classified, controlled, tested and assured to the same standard as any other production system, and material AI security incidents are notifiable. APRA and ASIC have confirmed this reading: their joint messaging to industry is that regulated entities "will need to assess AI risk against existing CPS 230 and CPS 234 requirements" (ASIC and APRA letters on emerging AI risks).

This page sets out, obligation by obligation, how CPS 234 maps onto the AI lifecycle and how a secure AI control plane such as Areebi - deployed privately in your own Australian environment - operationalises each requirement.

CPS 234 requires an entity to classify its information assets "by criticality and sensitivity" (paragraph 20) and to implement controls commensurate with the threats, vulnerabilities and consequences associated with those assets (paragraphs 21-22). An AI system is not one asset but a chain of them, and several attract the highest sensitivity ratings in a financial-services context.

• Models and weights. A fine-tuned model embeds and can regurgitate the data it was trained on. Trained weights are intellectual property and an availability-critical production dependency - both criticality and sensitivity concerns under paragraph 20.
• Training and fine-tuning data. Customer records, transaction histories and claims data used to train or fine-tune a model are typically the entity's most sensitive information assets, and they remain in scope while at rest in pipelines, feature stores and labelling tools.
• Vector and embedding stores. RAG architectures copy sensitive documents into vector databases. Embeddings can be inverted to reconstruct source text, so a vector store is a sensitive information asset, not a benign cache.
• Inference and API endpoints. A customer-facing or internal inference API is an availability-critical asset and a primary attack surface - the point at which prompt injection, model extraction and sensitive-information disclosure are attempted.
• Prompts, system prompts and logs. System prompts often contain credentials, business logic and connection strings; prompt and completion logs frequently contain personal information. Both are information assets requiring classification and protection.

These AI-specific exposures map directly onto the OWASP Top 10 for LLM Applications 2025, where Prompt Injection (LLM01), Sensitive Information Disclosure (LLM02), Supply Chain (LLM03), Data and Model Poisoning (LLM04) and System Prompt Leakage (LLM07) are leading risk categories. CPS 234 does not name these threats, but its requirement to identify "vulnerabilities and threats" and protect assets accordingly makes addressing them mandatory in substance.

CPS 234 is a short, principles-and-outcomes standard. The table below restates each core obligation in its own terms and translates it into the concrete AI-lifecycle control it demands. Paragraph references are to the CPS 234 standard (July 2019); non-binding implementation guidance is in Prudential Practice Guide CPG 234.

Roles and responsibilities (paragraphs 12-14)

The Board is ultimately responsible for information security, and roles must be clearly defined across the Board, senior management, governing bodies and individuals. AI translation: name an accountable owner for each AI system and ensure AI security risk is escalated to the Board as a whole-of-business risk, not delegated to a data-science team. Under the Financial Accountability Regime, information-security accountability should sit with the relevant accountable person rather than being left unowned.

Information security capability (paragraphs 13-18)

Maintain a capability commensurate with the size and extent of threats, including where assets are managed by related parties or third parties. AI translation: your capability must extend to model risk, AI supply-chain risk and inference-time threats - not just network and endpoint security.

Identification and classification (paragraph 20)

Classify information assets by criticality and sensitivity. AI translation: maintain a live inventory of every AI model, dataset, vector store and endpoint, classified for criticality and sensitivity. You cannot protect or report on assets you have not discovered - which is why shadow-AI discovery is foundational.

Implementation of controls (paragraphs 21-22)

Implement controls to protect assets commensurate with vulnerabilities, threats, criticality, sensitivity, lifecycle stage and the potential consequences of an incident. AI translation: apply data-loss prevention, access control, input/output guardrails and prompt-injection defences at the inference boundary, sized to the asset.

Incident management and notification (paragraphs 23-26 and 35-36)

Maintain robust detection and response mechanisms and test response plans at least annually. Notify APRA as soon as possible and no later than 72 hours after becoming aware of an information security incident that materially affected, or could have materially affected, the entity or its customers (paragraph 35), and no later than 10 business days after becoming aware of a material control weakness the entity cannot remediate in a timely manner (paragraph 36). AI translation: a successful data-exfiltration via prompt injection, a poisoned model, or an exposed inference endpoint is a notifiable incident or weakness - and you need immutable logs to detect and evidence it.

Testing control effectiveness (paragraphs 27-31)

Systematically test the effectiveness of controls, with frequency commensurate with the rate of change of vulnerabilities, asset criticality and the materiality of change. AI translation: red-team your models and inference APIs for prompt injection, jailbreaks, extraction and data leakage; test guardrails and DLP, not just infrastructure.

Internal audit (paragraphs 32-34)

Internal audit must review the design and operating effectiveness of information security controls, using appropriately skilled personnel. AI translation: AI controls fall within the internal-audit mandate and the AI control evidence must be audit-ready.

Third-party and related-party assets (paragraphs 15-16, 21-22, 28)

Where information assets are managed by a third party, the entity must evaluate that party's information security capability and the design and operating effectiveness of its controls. AI translation: using a third-party LLM API or hosted model is a third-party information-asset arrangement - assess the provider, and pair this with the operational-resilience and service-provider obligations of CPS 230.

CPS 234 secures the AI information asset; CPS 230 keeps the AI-dependent business operating and governs the providers behind it. Australian regulated entities must satisfy both - they are complementary, not alternative.

Prudential Standard CPS 230 (Operational Risk Management) came into force on 1 July 2025, with contractual requirements for existing arrangements transitioning by the earlier of the next renewal or 1 July 2026 (APRA, Operational Risk Management). It requires entities to manage operational risk with effective controls, maintain the ability to deliver critical operations within tolerance through severe disruptions, and manage the risks of material service providers - a category that expressly includes providers the entity relies on for a critical operation, such as cloud and SaaS providers, and therefore hosted AI and inference services.

For an AI deployment the division of labour is clear:

• CPS 234 governs the security of the model, data, pipeline and inference API as information assets - classification, controls, testing, incident notification.
• CPS 230 governs whether an AI-dependent process is a critical operation, the tolerance levels for its disruption, the business continuity plan if a model or AI vendor fails, and the due diligence, contractual terms and ongoing monitoring of material AI service providers.

Where a third-party LLM provider both holds your data (CPS 234, third-party information asset) and underpins a critical operation (CPS 230, material service provider), both standards apply simultaneously. APRA and ASIC have made clear that AI risk must be assessed against these existing frameworks rather than waiting for AI-specific rules (Corrs, ASIC and APRA letters on emerging AI risks). A private, sovereign deployment of the AI control plane reduces both surfaces at once: keeping data and inference inside your own Australian environment shrinks the CPS 234 third-party attack surface and the CPS 230 material-service-provider dependency.

APRA is actively enforcing CPS 234 through an independent tripartite assurance program and has publicly flagged systemic control gaps - several of which map directly onto AI risk. This is not a dormant standard.

On 5 July 2023 APRA published initial findings from the first tranche of its tripartite cyber assessment, covering roughly 24% of regulated entities in a program designed to reach more than 300 banks, insurers and superannuation trustees. The common control gaps it identified included incomplete identification and classification of critical and sensitive information assets, limited assessment of third-party information-security capability, inadequate definition and execution of control-testing programs, incident-response plans that were not regularly tested, limited internal-audit coverage, and inconsistent, untimely reporting of material incidents and control weaknesses (APRA, Cyber security stocktake exposes gaps). Every one of these is amplified by AI: unclassified models and vector stores, self-attesting AI vendors, untested guardrails, and AI incidents that slip past detection.

The real-world cost became visible in March and April 2025, when coordinated credential-stuffing attacks hit Australian superannuation funds. AustralianSuper confirmed that around 600 member accounts were accessed and four members suffered financial losses totalling roughly A$500,000, while Rest reported limited personal information being accessed for about 8,000 member accounts, in a wave that compromised more than 20,000 accounts across the sector (BleepingComputer, Australian pension funds hit by credential stuffing). In response, on 10 June 2025 APRA wrote to all RSE licensees requiring them to self-assess their information-security and authentication controls by 31 August 2025, implement MFA or equivalent controls for all high-risk activities and privileged access, and lodge a material-control-weakness notification where controls were deficient (APRA, For action: Information Security Obligations and Critical Authentication Controls).

The AI-adoption gap is widening the exposure. ASIC's Report 798, Beware the gap, published 29 October 2024, reviewed 624 AI use cases across 23 licensees and found that only about half had specifically updated their risk-management policies or procedures to address AI, even as generative AI made up roughly 22% of in-development use cases (ASIC REP 798). The supervisory direction is unambiguous: AI is being deployed faster than it is being governed, and CPS 234 is the standard against which that gap will be measured.

Areebi is a secure AI control plane that sits between your users and any AI model, enforcing CPS 234-style controls - discovery, classification, DLP, access control, guardrails and immutable audit - at the inference boundary, deployable entirely within your own Australian environment. It does not replace your CPS 234 program; it operationalises it for the AI estate.

Because Areebi is privately deployable - via Docker, Kubernetes, on-premises or in your private cloud - data and inference stay inside your jurisdiction, directly addressing the third-party information-asset concern in CPS 234 paragraphs 15-16 and the material-service-provider concern in CPS 230. It is model-agnostic across a wide range of large language models, so the same control plane governs commercial APIs and self-hosted open models alike. The control mapping below is honest about what the product does today.

• Shadow-AI discovery and inventory builds and maintains the live AI asset register that classification (paragraph 20) presupposes.
• Real-time DLP inspects prompts and responses to stop sensitive information assets leaving via inference - the control demanded by paragraphs 21-22 and OWASP LLM02.
• The policy engine applies machine-readable, enforceable rules at the point of use, sized to asset criticality and sensitivity.
• Guardrails defend the inference boundary against prompt injection, jailbreaks and unsafe output (OWASP LLM01).
• Access control enforces who can reach which model and data, supporting the authentication expectations APRA reiterated in its June 2025 notice.
• Immutable audit logging provides the tamper-evident record needed to detect incidents, meet the 72-hour and 10-business-day notification obligations, and satisfy internal audit (paragraphs 32-36).

On Areebi's own assurance posture, accuracy matters: Areebi is currently progressing SOC 2 readiness and is not yet certified. We make no claims of named customers, audited metrics or certifications we do not hold. Explore the full control set on the platform overview or see the financial-services solution for BFSI-specific deployment patterns.