EAAPL-CMP002 — APRA CPS234 AI Security Architecture
Status: Mature
Tags: apra-cps234 zero-trust audit-logging banking insurance high-complexity
Version: 2.1
Last Updated: 2026-06-12
Author: Enterprise AI Architecture Pattern Library
1. Executive Summary
Australian Prudential Regulation Authority (APRA) Prudential Standard CPS234 Information Security applies in full to AI systems operated by APRA-regulated entities. AI models, training pipelines, inference endpoints, and AI-generated outputs each constitute information assets and must be classified, protected, and tested under the same obligations as any other critical information asset. This pattern defines an end-to-end security architecture that operationalises CPS234 obligations—Paragraphs 15 (roles and responsibilities), 16 (information asset identification and classification), 17 (implementation of controls), 20 (third-party management), 23 (testing), and 24 (incident response)—within modern AI system deployments.
The architecture is designed for banks, insurers, superannuation funds, and other APRA-regulated entities deploying machine learning inference systems, large language models, or AI-assisted decision engines in business-critical or customer-facing workloads. Adoption of this pattern demonstrably reduces the risk of regulatory enforcement action, data breach, and AI system compromise while providing an audit-ready evidence trail for APRA reviews.
2. Problem Statement
Business Problem
APRA-regulated entities are deploying AI systems faster than their information security frameworks can absorb them. Board and executive accountability for AI security—as required by CPS234 Paragraph 15—is unclear, and AI-specific security controls are inconsistently applied across business units, creating material prudential risk and exposing institutions to formal supervisory action.
Technical Problem
AI systems introduce novel attack surfaces—model inversion, prompt injection, training data poisoning, adversarial inputs—that are not addressed by traditional application security controls. Existing security control libraries were not designed with AI model artefacts, inference APIs, or LLM chat surfaces in mind. Third-party AI service providers (cloud LLM APIs, MLOps platforms) introduce supply chain risks that standard vendor due diligence questionnaires do not adequately assess.
Symptoms
- No AI asset register exists; AI models are not classified under the entity's information asset taxonomy
- Penetration testing programmes exclude AI inference endpoints and model APIs
- Third-party AI vendors have not been assessed against CPS234 Paragraph 20 requirements
- AI security incidents are triaged under generic IT incident processes with no AI-specific escalation criteria
- Board and CISO cannot demonstrate active control oversight of AI information assets as required by CPS234 Paragraph 15
Cost of Inaction
| Dimension |
Consequence |
| Regulatory |
APRA enforcement action, enforceable undertakings, potential licence conditions |
| Financial |
Direct breach costs AUD 10M–50M+; reputational damage reducing customer acquisition |
| Operational |
AI system compromise causes incorrect decisions (credit, insurance, fraud) at scale |
| Legal |
Privacy Act breaches triggered by AI model data exfiltration; class action risk |
3. Context
When to Apply
- Any APRA-regulated entity (ADI, insurer, RSE licensee, NOHC) deploying AI in production
- Where AI systems process regulated data (credit decisions, insurance underwriting, claims processing, superannuation account management)
- When onboarding third-party AI services or cloud LLM APIs into the entity's technical environment
- Where AI systems are classified as material business services under CPS230
When NOT to Apply
- Pure research or sandbox environments with no connection to production data or systems
- AI tools used exclusively on fully anonymised, non-personal datasets with no regulated data lineage
- Non-APRA entities (apply EU AI Act or ISO 42001 patterns instead)
Prerequisites
| Prerequisite |
Description |
| Information Asset Register |
Existing IAR with classification taxonomy that can be extended to AI artefacts |
| Security Operations Centre |
Operational SOC capable of receiving AI security events and alerts |
| Third-Party Risk Management |
Existing TPRM programme into which AI vendors can be assessed |
| Change Management |
Change process through which AI security controls can be deployed |
| Board Risk Committee |
Governance body that can receive AI security risk reporting |
Industry Applicability
| Industry |
Applicability |
Notes |
| Banking (ADI) |
Mandatory |
CPS234 full application; AI in credit decisioning is material |
| General Insurance |
Mandatory |
AI in underwriting and claims; APRA supervised |
| Life Insurance |
Mandatory |
AI in underwriting; sensitive health data classification applies |
| Superannuation (RSE) |
Mandatory |
AI in member communications and investment decisions |
| Non-APRA Financial Services |
Recommended |
ASIC regulatory expectations align; AFS licence conditions |
| Government (non-APRA) |
Partial |
ISM and PSPF apply; CPS234 obligations do not formally apply |
4. Architecture Overview
The CPS234 AI Security Architecture is organised around four control tiers that map directly to CPS234 obligations, implemented as a defence-in-depth stack across the AI system lifecycle.
Tier 1 — Asset Identification and Classification (CPS234 ¶16)
All AI artefacts—model weights, training datasets, validation datasets, inference endpoints, prompts, embeddings, fine-tuned adapters, and AI-generated outputs stored for decisioning purposes—must be identified, registered in the entity's Information Asset Register (IAR), and classified according to the entity's data classification taxonomy. The classification level determines the mandatory control set that applies. Typically, model weights for a credit decisioning model would be classified as Confidential (equivalent to source code for a core banking system), and the inference endpoint as Critical (same tier as internet-facing transaction systems). The IAR entry for each AI asset must record: asset owner (accountability under ¶15), classification, data lineage, third-party dependencies, and control maturity rating.
Tier 2 — Security Controls Implementation (CPS234 ¶17)
Security controls are applied across three categories: preventive, detective, and corrective. Preventive controls include: network segmentation isolating AI inference infrastructure; identity and access management with least-privilege service accounts for model APIs; input validation and sanitisation to prevent prompt injection and adversarial inputs; model signing and integrity verification to detect tampered weights; secrets management for API keys to LLM providers. Detective controls include: real-time logging of all inference requests and responses; anomaly detection on model output distributions (detecting model poisoning or drift); privilege access monitoring on model storage systems; network traffic analysis on AI API egress. Corrective controls include: automated model rollback on integrity failure; circuit breakers on AI APIs when anomalous output rates are detected; incident escalation playbooks with AI-specific triage criteria.
Tier 3 — Third-Party AI Security (CPS234 ¶20)
Any third-party AI service provider—cloud LLM APIs (OpenAI, Anthropic, Google, Azure OpenAI), MLOps platforms (Databricks, AWS SageMaker), or AI-embedded SaaS—must be assessed under the entity's TPRM programme with AI-specific due diligence criteria. The assessment must cover: data handling obligations (does the provider train on customer data?), security certifications (SOC 2 Type II, ISO 27001), sub-processor disclosures, incident notification SLAs, geographic data processing boundaries, and contractual data deletion obligations. Where the provider is classified as material under CPS234 ¶20, the regulated entity must have a right to audit and must obtain and review independent attestation (e.g., SOC 2 Type II report) annually.
Tier 4 — Testing and Incident Response (CPS234 ¶23, ¶24)
AI systems must be included in the entity's annual penetration testing programme, with AI-specific test scenarios: prompt injection attacks, model extraction attempts, adversarial input testing, and API authentication bypass. Penetration test scope documentation must explicitly name AI inference endpoints and model APIs. The incident response plan must include an AI Security Incident Playbook covering: AI model compromise (weights tampered/stolen), AI data poisoning, adversarial input attacks causing incorrect outputs, and unauthorised access to AI inference logs. APRA notification obligations under CPS234 ¶24 apply where an AI security incident meets the materiality threshold.
5. Architecture Diagram
flowchart TD
subgraph Input["Request Layer"]
A[End User Request]
B[API Gateway + WAF]
end
subgraph Core["AI System Core"]
C[Input Validation]
D[Inference Engine]
E[Output Validation]
end
subgraph Security["Security Controls"]
F[IAM and Secrets Manager]
G[SIEM and Anomaly Detector]
H[(Immutable Audit Log)]
end
A --> B
B --> F
F --> C
C --> D
D --> E
E --> A
D --> H
H --> G
G -->|incident trigger| G
style A fill:#dbeafe,stroke:#3b82f6
style B fill:#f0fdf4,stroke:#22c55e
style C fill:#f0fdf4,stroke:#22c55e
style D fill:#f0fdf4,stroke:#22c55e
style E fill:#f0fdf4,stroke:#22c55e
style F fill:#f3e8ff,stroke:#a855f7
style G fill:#fee2e2,stroke:#ef4444
style H fill:#fef9c3,stroke:#eab308
6. Components
| Component |
Type |
Responsibility |
Technology Options |
Criticality |
| Web Application Firewall |
Preventive Control |
Block prompt injection, OWASP attacks, rate limiting |
AWS WAF, Azure Front Door WAF, Cloudflare WAF |
Critical |
| API Gateway |
Entry Point |
Authentication, authorisation, request routing, rate limits |
AWS API Gateway, Azure APIM, Kong, Apigee |
Critical |
| Input Validation & PII Redaction |
Processing |
Strip/mask sensitive data before LLM; validate schema |
AWS Comprehend, Azure Purview, spaCy NER, custom |
High |
| Inference Engine |
Core |
Execute model inference; manage model lifecycle |
AWS SageMaker, Azure ML, Vertex AI, vLLM, Triton |
Critical |
| Model Weights Store |
Storage |
Versioned, signed model artefacts; integrity-verified |
S3 + KMS, Azure Blob + Key Vault, GCS + CMEK |
Critical |
| Output Validation |
Processing |
Filter hallucinations, enforce output schema, detect anomalies |
LangChain guardrails, NeMo Guardrails, custom |
High |
| IAM / Zero-Trust |
Security |
Service identity, least privilege, short-lived tokens |
AWS IAM, Azure Entra ID, HashiCorp Vault, SPIFFE |
Critical |
| Secrets Manager |
Security |
Rotate and inject API keys, database credentials, model tokens |
AWS Secrets Manager, Azure Key Vault, HashiCorp Vault |
Critical |
| SIEM / Log Aggregator |
Detective |
Aggregate and correlate security events from all AI components |
Splunk, Microsoft Sentinel, Elastic SIEM, Sumo Logic |
High |
| Anomaly Detector |
Detective |
Monitor model output distributions; detect poisoning/drift |
Evidently AI, WhyLabs, Fiddler, custom statistical tests |
Medium |
| Information Asset Register |
Governance |
Record all AI assets with classification, owner, control maturity |
ServiceNow, Archer, Collibra, spreadsheet (small entities) |
High |
| Third-Party Risk Manager |
Governance |
Track AI vendor assessments, certifications, audit rights |
ProcessUnity, LogicGate, OneTrust, Prevalent |
High |
| Incident Response Playbook |
Process |
AI-specific triage, containment, APRA notification decision tree |
Atlassian Jira, PagerDuty, ServiceNow ITSM |
Critical |
7. Data Flow
Primary Flow
| Step |
Actor |
Action |
Output |
| 1 |
End User |
Submit request via HTTPS to API endpoint |
Encrypted HTTP request |
| 2 |
WAF |
Inspect request for prompt injection patterns and OWASP attacks |
Clean request or 403 block |
| 3 |
API Gateway |
Validate JWT/OAuth token; check rate limit; route to service |
Authenticated request context |
| 4 |
IAM |
Verify service identity; issue short-lived inference credential |
Ephemeral access token |
| 5 |
Input Validator |
Detect and redact PII; validate input schema; log input hash |
Sanitised inference payload |
| 6 |
Inference Engine |
Load signed model weights; execute inference; call third-party API if configured |
Raw model output |
| 7 |
Output Validator |
Apply guardrails; filter policy violations; check output schema |
Safe, validated response |
| 8 |
Log Aggregator |
Write immutable audit record: input hash, output hash, model version, latency, user identity |
Audit log entry |
| 9 |
Anomaly Detector |
Compare output distribution against baseline; flag deviations |
Alert if anomaly threshold exceeded |
| 10 |
SIEM |
Correlate events; generate security dashboard; trigger alerts |
Security visibility |
Error Flow
| Step |
Failure |
Detection |
Recovery |
| WAF Block |
Prompt injection attempt detected |
WAF rule match logged |
Request rejected; security alert raised; IP blocked if threshold exceeded |
| Auth Failure |
Invalid or expired token |
API Gateway 401 response |
User redirected to re-authenticate; repeated failures trigger MFA challenge |
| Model Integrity Failure |
Signed hash mismatch on model weights |
Integrity check at load time |
Inference halted; rollback to last known-good model version; P1 incident raised |
| Third-Party API Unavailable |
LLM vendor API returns 5xx |
Circuit breaker trips |
Fallback to local model or graceful degradation; TPRM SLA breach recorded |
| Output Policy Violation |
Guardrail detects policy breach in model output |
Output validator blocks response |
Suppressed response returned; incident logged; human review queue |
| APRA Notification Threshold |
AI incident meets materiality threshold |
IR Playbook decision tree |
APRA notified within 72 hours per CPS234 ¶24; Board Risk Committee briefed |
8. Security Considerations
Security Control Framework
| Domain |
Control |
Implementation |
CPS234 Reference |
| Authentication |
All AI service-to-service calls use mutual TLS + short-lived JWT |
SPIFFE/SPIRE or cloud IAM service accounts |
¶17 |
| Authorisation |
RBAC on model access: data scientists (read-only), MLOps (deploy), security (audit) |
OPA, AWS IAM policies, Azure RBAC |
¶17 |
| Secrets Management |
LLM API keys rotated every 90 days; never in code or environment variables |
AWS Secrets Manager, HashiCorp Vault |
¶17 |
| Data Classification |
All AI artefacts classified; Confidential+ requires CMEK |
Entity classification taxonomy + IAR |
¶16 |
| Encryption in Transit |
TLS 1.3 minimum on all AI API calls, including vendor API calls |
Cloud-native TLS termination |
¶17 |
| Encryption at Rest |
Model weights and training data encrypted with CMEK |
AWS KMS, Azure Key Vault, GCP CMEK |
¶17 |
| Model Integrity |
Model weights cryptographically signed; verified at load |
Sigstore, in-house PKI |
¶17 |
| Audit Logging |
All inference requests logged immutably with user identity, input hash, output hash, model version |
Immutable S3 + CloudTrail, Azure Immutable Blob |
¶17, ¶23 |
| Penetration Testing |
AI inference endpoints and model APIs included in annual pen test scope |
Qualified security assessors with AI test cases |
¶23 |
| Incident Response |
AI Security Incident Playbook with APRA notification decision tree |
PagerDuty, ServiceNow, Jira |
¶24 |
OWASP LLM Top 10 Controls
| OWASP LLM Risk |
Description |
Control Applied |
CPS234 Relevance |
| LLM01 Prompt Injection |
Malicious instructions embedded in user input override model behaviour |
WAF rules for prompt injection patterns; input sanitisation; system prompt hardening |
¶17 preventive control |
| LLM02 Insecure Output Handling |
Model output contains executable content or unsafe data passed to downstream systems |
Output validation layer; schema enforcement; content security policy |
¶17 corrective control |
| LLM03 Training Data Poisoning |
Malicious data injected into training corpus corrupts model behaviour |
Training data provenance tracking; integrity hashing; access control on training pipelines |
¶16 asset classification; ¶17 control |
| LLM04 Model Denial of Service |
Adversarial inputs consume excessive compute, degrading availability |
Rate limiting at API gateway; token budget enforcement; anomaly detection on token usage |
¶17 preventive; availability obligation |
| LLM05 Supply Chain Vulnerabilities |
Third-party model weights, datasets, or plugins contain malicious components |
Third-party AI vendor due diligence; model signing; SBOM for AI artefacts |
¶20 third-party management |
| LLM06 Sensitive Information Disclosure |
Model outputs contain training data, PII, or confidential information |
Output filtering for PII; model red-teaming; differential privacy in training |
¶17; Privacy Act integration |
| LLM07 Insecure Plugin Design |
Tool/plugin integrations executed by the model have excessive permissions |
Least-privilege tool design; tool call whitelisting; human approval for high-risk tool calls |
¶17 least privilege |
| LLM08 Excessive Agency |
Model takes autonomous actions with real-world consequences beyond intended scope |
Hard limits on autonomous action scope; human-in-the-loop gates for irreversible actions |
¶17; ¶15 accountability |
| LLM09 Overreliance |
Users or systems rely on model output without appropriate validation, leading to errors |
User-facing disclaimers; output confidence scoring; mandatory human review for regulated decisions |
¶15 accountability; ¶17 |
| LLM10 Model Theft |
Model weights or parameters are exfiltrated by adversaries |
Access control on model storage; DLP policies on model artefacts; egress monitoring |
¶16 classification; ¶17; ¶24 incident |
9. Governance Considerations
Responsible AI and Model Risk
| Governance Domain |
Requirement |
Owner |
Frequency |
| AI Asset Ownership |
Each AI system has a named accountable owner at exec level (CPS234 ¶15) |
CISO / CRO |
Ongoing; reviewed annually |
| Model Risk Assessment |
Quantitative assessment of model failure consequences for each production model |
Model Risk function |
At deployment; re-assessed annually |
| Human Approval Gates |
AI-generated decisions with material consequences require human review before execution |
Business unit heads |
Per decision type |
| AI Security Policy |
Board-approved AI security policy referencing CPS234 obligations |
CISO |
Reviewed annually |
| Traceability |
Complete lineage from training data → model version → inference request → business decision |
MLOps / data engineering |
Continuous |
| APRA Notification |
Board attestation that CPS234 ¶23 testing has occurred; material incidents notified ¶24 |
CRO / Company Secretary |
Annual attestation; event-driven notification |
Governance Artefacts
| Artefact |
Description |
Owner |
Retention |
| AI Information Asset Register |
All AI models, datasets, endpoints classified per CPS234 ¶16 |
CISO |
7 years (APRA expectation) |
| Third-Party AI Vendor Assessments |
CPS234 ¶20 due diligence records for each AI vendor |
TPRM team |
7 years |
| Penetration Test Reports |
Scope, findings, and remediation for AI system pen tests (¶23) |
Security team |
7 years |
| Incident Logs |
Full audit trail of AI security incidents and APRA notifications (¶24) |
CISO / Legal |
7 years |
| Board Risk Committee Papers |
AI security risk reporting to Board per CPS234 ¶15 |
Company Secretary |
7 years |
| Control Attestation Reports |
Annual self-assessment of CPS234 control effectiveness for AI systems |
Internal Audit |
7 years |
10. Operational Considerations
Monitoring and SLOs
| SLO |
Target |
Measurement |
Breach Action |
| Inference API Availability |
99.9% per month |
Synthetic endpoint probes every 60 seconds |
P2 incident; DR failover if >5 min |
| Security Event Ingestion Latency |
<60 seconds from event to SIEM |
Log pipeline latency metric |
Alert SOC; investigate pipeline |
| Model Integrity Check |
100% of model loads verify signature |
Integrity check success rate metric |
P1 incident; halt inference; rollback |
| Pen Test Coverage |
100% of production AI endpoints in annual scope |
Pen test scope coverage report |
CISO exception sign-off required |
| Third-Party Assessment Currency |
100% of material AI vendors assessed within 12 months |
TPRM vendor assessment age |
Escalate to TPRM; vendor risk elevated |
| APRA Notification Timeliness |
100% of material incidents notified within 72 hours |
IR timeline from detection to notification |
Board Risk Committee immediate brief |
Incident Response
| Incident Type |
Severity |
Escalation |
APRA Notification |
| Prompt Injection Attack |
High |
SOC → CISO within 1 hour |
If data exfiltrated or decisions corrupted: Yes |
| Model Weights Exfiltration |
Critical |
SOC → CISO → CEO within 30 min |
Yes — material information security incident |
| Training Data Poisoning |
Critical |
SOC → CISO → CRO within 1 hour |
Yes — if production model affected |
| Third-Party AI Vendor Breach |
High |
TPRM → CISO → CRO within 2 hours |
If data shared with vendor: Yes |
| Adversarial Input Causing Incorrect Decisions |
High |
Product team → CRO → Legal within 2 hours |
Yes — if customer harm resulted |
Capacity Planning
Annual AI security testing budget must be line-itemed separately from general IT security. Pen test cost for AI systems typically runs AUD 80,000–200,000 per annual cycle for a medium-complexity AI estate. SIEM ingestion capacity must account for verbose AI inference logs (typically 5–20x higher event volume than equivalent transactional systems).
11. Cost Considerations
Cost Drivers
| Cost Driver |
Indicative Cost |
Scaling Factor |
| WAF + API Gateway |
AUD 2,000–8,000/month |
Scales with request volume |
| SIEM ingestion and storage for AI logs |
AUD 5,000–25,000/month |
Scales with log volume (verbose AI logs) |
| Penetration testing (annual, AI scope) |
AUD 80,000–200,000/year |
Scales with number of AI endpoints |
| Third-party AI vendor TPRM assessments |
AUD 10,000–30,000/year per material vendor |
Scales with vendor count |
| Anomaly detection platform |
AUD 3,000–15,000/month |
Scales with model count and prediction volume |
| Secrets management platform |
AUD 1,000–5,000/month |
Near-flat; minor scaling |
| Internal security headcount (AI-specific) |
AUD 200,000–400,000/year (1–2 FTE) |
Scales with AI system complexity |
Indicative Total Cost Range
| Entity Size |
Annual CPS234 AI Security Cost |
Notes |
| Small APRA entity (<AUD 1B assets) |
AUD 150,000–350,000 |
Likely outsourced SOC; shared pen test budget |
| Mid-size entity (AUD 1B–50B assets) |
AUD 500,000–1,500,000 |
Internal SOC; dedicated AI security resources |
| Major bank / insurer (>AUD 50B assets) |
AUD 2,000,000–10,000,000 |
Full dedicated AI security programme |
Optimisations
- Consolidate SIEM ingestion by sampling low-risk AI logs (80% cost reduction for non-critical models)
- Use cloud-native security tooling over third-party where capability parity exists
- Combine AI pen testing with existing annual pen test programme to share mobilisation costs
12. Trade-Off Analysis
Architecture Options Comparison
| Option |
Description |
Pros |
Cons |
Recommended For |
| Option A: Cloud-Native Security Tooling |
Use exclusively cloud provider security services (AWS GuardDuty, Azure Defender for AI) |
Lower operational overhead; native integration; lower cost |
Vendor lock-in; may not meet APRA data sovereignty requirements |
Entities with single-cloud strategy and no sovereignty constraints |
| Option B: Best-of-Breed Security Stack |
Dedicated AI security tooling (Protect AI, HiddenLayer) + enterprise SIEM |
Deepest AI-specific detection capability; vendor-neutral |
Higher cost; integration complexity; skills requirement |
Major banks and insurers with dedicated security teams |
| Option C: MSSP-Delivered AI Security |
Outsourced managed security service provider handles AI security monitoring |
Lower internal headcount; leverages specialist expertise |
CPS234 ¶15 accountability remains with regulated entity; dependency risk |
Small-to-mid entities without internal AI security capability |
Architectural Tensions
| Tension |
Trade-Off |
Resolution |
| Security vs Latency |
Input/output validation and logging add 50–200ms latency per inference |
Apply async logging for non-critical paths; synchronous only for regulated decision paths |
| Completeness vs Cost |
Full immutable logging of all inferences is expensive at scale |
Tiered logging: regulated decisions = full immutable; exploratory = sampled |
| Vendor Risk vs Capability |
Best LLM capability is from third-party cloud providers with offshore processing |
Contractual DPA + APRA ¶20 assessment + synthetic data masking before external call |
| Automation vs Accountability |
Automated AI decisions are efficient but CPS234 ¶15 requires named accountability |
Every automated AI decision maps to an accountable executive; audit trail proves the link |
13. Failure Modes
| Failure |
Likelihood |
Impact |
Detection |
Recovery |
| Prompt Injection Attack Succeeds |
Medium |
High — AI produces unintended outputs or leaks data |
WAF miss; downstream output anomaly |
Roll back affected decisions; notify APRA if material; tighten WAF rules |
| Model Weights Exfiltration |
Low |
Critical — IP loss; model can be used by competitors or adversaries |
DLP alert on large model file egress |
Invalidate model; retrain if poisoned; APRA notification |
| Third-Party AI Vendor Breach |
Medium |
High — customer data processed by vendor may be exposed |
Vendor notification; threat intel |
Invoke contractual notification SLA; assess data exposure; APRA if material |
| SIEM Pipeline Failure |
Medium |
High — security events not visible; detection gap |
SIEM health monitoring; dead man's switch alert |
Restore pipeline; review events in buffer; assess whether blind period created exploitable window |
| Annual Pen Test Omits AI Endpoints |
Medium |
High — CPS234 ¶23 breach; undetected vulnerabilities |
CISO scope review |
Remediate by commissioning targeted AI pen test; document as ¶23 exception |
| Model Drift Causes Systematic Errors |
Medium |
High — systematic incorrect decisions (credit, claims) at scale |
Output distribution anomaly detection |
Rollback model; review affected decisions; notify customers if harm resulted |
Cascading Failure Scenario
A compromised third-party AI vendor (LLM API provider) causes poisoned model responses. Because AI output logging is insufficient (no output hash baseline), the poisoned outputs persist in the inference stream for weeks before anomaly detection fires. During this period, credit decisions are systematically biased. APRA investigators discover the entity had not assessed the third-party vendor under CPS234 ¶20, and the annual penetration test had not included the AI inference endpoint as required by ¶23. Regulatory enforcement action ensues alongside customer remediation costs.
14. Regulatory Considerations
| Regulation |
Specific Obligation |
Architectural Control |
Reference |
| APRA CPS234 ¶15 |
Board and executive accountability for information security, including AI assets |
Named AI asset owners in IAR; Board Risk Committee AI security reporting |
CPS234 Paragraph 15 |
| APRA CPS234 ¶16 |
Identification and classification of all information assets, including AI systems |
AI artefacts in IAR with classification; control mapping per classification level |
CPS234 Paragraph 16 |
| APRA CPS234 ¶17 |
Implementation of controls commensurate with classification; preventive, detective, corrective |
Security control framework (see Section 8); tiered controls per classification |
CPS234 Paragraph 17 |
| APRA CPS234 ¶20 |
Third-party provider security; regulated entity retains accountability |
AI vendor TPRM assessments; contractual DPA; right-to-audit; annual attestation review |
CPS234 Paragraph 20 |
| APRA CPS234 ¶23 |
Testing of controls, including penetration testing, at appropriate frequency |
AI endpoints in annual pen test scope; test report retention 7 years |
CPS234 Paragraph 23 |
| APRA CPS234 ¶24 |
Notification of material information security incidents to APRA within 72 hours |
AI Security Incident Playbook with APRA notification decision tree |
CPS234 Paragraph 24 |
| Privacy Act 1988 (Cth) |
APP 11 — security of personal information held in AI systems |
PII classification; encryption; access control; breach notification integration |
APPs 11, 12 |
| APRA CPS230 |
Material business services resilience; AI in critical processes must have recovery plans |
DR plan for AI inference infrastructure; RTO/RPO defined per service criticality |
CPS230 Paragraph 19 |
| APRA CPG 234 |
Guidance on penetration testing scope, methodology, and governance |
AI-specific pen test methodology; qualified assessor requirements; scope documentation |
CPG 234 Sections 4, 5 |
15. Reference Implementations
AWS
| Component |
AWS Service |
| WAF + Prompt Injection Rules |
AWS WAF with managed rule groups + custom prompt injection rules |
| API Gateway + AuthN |
Amazon API Gateway + AWS Cognito / IAM authoriser |
| Input Validation |
AWS Lambda + Amazon Comprehend for PII detection |
| Inference Engine |
Amazon SageMaker Endpoints (managed) or EC2/EKS (self-managed) |
| Model Storage + Integrity |
S3 + KMS (CMEK) + AWS Signer for model artefact signing |
| Secrets Management |
AWS Secrets Manager with automatic rotation |
| Audit Logging |
CloudTrail + S3 Immutable (Object Lock WORM) |
| SIEM |
Amazon Security Hub + third-party (Splunk, Elastic) |
| Anomaly Detection |
Amazon SageMaker Model Monitor |
Azure
| Component |
Azure Service |
| WAF |
Azure Front Door WAF + custom rule sets |
| API Gateway |
Azure API Management |
| Input Validation |
Azure AI Language (PII detection) + custom Logic Apps |
| Inference Engine |
Azure Machine Learning Managed Online Endpoints |
| Model Storage + Integrity |
Azure Blob Storage + Azure Key Vault (CMEK) + Azure Code Signing |
| Secrets Management |
Azure Key Vault + Managed Identities |
| Audit Logging |
Azure Monitor + Immutable Blob Storage |
| SIEM |
Microsoft Sentinel with AI-specific workbook |
| Anomaly Detection |
Azure ML Data Drift Monitor |
GCP
| Component |
GCP Service |
| WAF |
Cloud Armor with custom security policies |
| API Gateway |
Apigee API Management |
| Input Validation |
Cloud DLP + Cloud Functions |
| Inference Engine |
Vertex AI Online Prediction |
| Model Storage + Integrity |
Cloud Storage + Cloud KMS (CMEK) + Binary Authorization |
| Secrets Management |
Secret Manager + Workload Identity |
| Audit Logging |
Cloud Audit Logs + Cloud Storage Bucket Lock |
| SIEM |
Chronicle SIEM |
| Anomaly Detection |
Vertex AI Model Monitoring |
On-Premises
| Component |
Technology |
| WAF |
F5 BIG-IP ASM, Nginx ModSecurity |
| API Gateway |
Kong, Apigee hybrid |
| Input Validation |
spaCy NER pipeline, custom rule engine |
| Inference Engine |
vLLM on GPU servers, Triton Inference Server |
| Model Storage + Integrity |
NetApp + in-house PKI + Sigstore |
| Secrets Management |
HashiCorp Vault Enterprise |
| Audit Logging |
Splunk Enterprise + WORM storage appliance |
| SIEM |
Splunk Enterprise Security |
| Anomaly Detection |
Evidently AI, WhyLabs on-prem |
| Pattern ID |
Pattern Name |
Relationship |
Notes |
| EAAPL-CMP003 |
EU AI Act Compliance |
COMPLEMENTARY |
Entities with EU nexus apply both; CPS234 covers security, EU AI Act covers risk classification |
| EAAPL-CMP004 |
Privacy-Preserving AI |
COMPLEMENTARY |
CPS234 security controls + Privacy Act data minimisation are both required; deploy together |
| EAAPL-CMP007 |
Data Residency for AI |
PREREQUISITE |
Must establish data residency controls before CPS234 third-party AI assessment is complete |
| EAAPL-CMP005 |
ISO 42001 Implementation |
COMPLEMENTARY |
ISO 42001 AIMS provides the management system framework; CPS234 provides security-specific controls |
| EAAPL-AGT003 |
Human-in-the-Loop Oversight |
COMPLEMENTARY |
CPS234 ¶15 accountability for AI decisions is best implemented via HITL gates for material decisions |
| EAAPL-SEC001 |
Zero-Trust Architecture |
PREREQUISITE |
Zero-trust network access is a foundational control for CPS234 ¶17 implementation |
17. Maturity Assessment
Overall Maturity Label: Mature
| Dimension |
Level 1 (Initial) |
Level 2 (Repeatable) |
Level 3 (Defined) |
Level 4 (Managed) |
Level 5 (Optimising) |
Current Pattern Level |
| AI Asset Register |
No AI assets in IAR |
Ad-hoc AI asset tracking |
Formal IAR with AI classification taxonomy |
IAR integrated with CMDB; automated discovery |
Continuous AI asset inventory with risk scoring |
Level 3–4 |
| Security Controls |
No AI-specific controls |
Manual controls applied inconsistently |
Documented control framework; consistent application |
Automated control validation; KPI dashboards |
AI security controls continuously tuned via threat intel |
Level 3–4 |
| Third-Party Management |
No AI vendor assessment |
Questionnaires sent ad hoc |
Formal TPRM process; annual assessments |
Continuous vendor risk monitoring; contractual KPIs |
Real-time vendor risk signals integrated into TPRM |
Level 3 |
| Penetration Testing |
AI endpoints not tested |
AI endpoints in general pen test scope |
Dedicated AI security test scenarios |
AI-specific red team exercises |
Continuous adversarial testing (purple team) |
Level 2–3 |
| Incident Response |
Generic IT process applied |
AI incidents identified as sub-category |
Dedicated AI Security Incident Playbook |
Tabletop exercises for AI incidents; APRA notification drilled |
AI threat intel feeds automated IR |
Level 3 |
18. Revision History
| Version |
Date |
Author |
Changes |
| 1.0 |
2025-03-01 |
EAAPL Working Group |
Initial draft |
| 1.1 |
2025-07-15 |
EAAPL Working Group |
Added OWASP LLM Top 10 mapping; expanded third-party section |
| 2.0 |
2026-01-10 |
EAAPL Working Group |
Major revision: added CPS230 alignment; updated reference implementations; expanded incident response |
| 2.1 |
2026-06-12 |
EAAPL Working Group |
Added cascading failure scenario; updated cost ranges; aligned with APRA CPG 234 June 2026 guidance |