APRA CPS 234 and Autonomous AI

Why CPS 234 matters for autonomous AI

APRA CPS 234 matters for autonomous AI because AI systems increasingly interact with information assets rather than merely producing text. The standard focuses on information security: protecting confidentiality, integrity, and availability, including for information assets managed by related parties or third parties. Autonomous AI turns those concepts into daily governance questions. What information can the agent read? What information can it infer? What systems can it write to? Which provider processes the context? Which logs are retained? Which controls stop unauthorised action?

CPS 234 is not written as an AI standard. That does not reduce its relevance. In an APRA-regulated environment, AI that touches information assets should be considered through an information-security lens. An AI copilot may summarise customer records. A claims or banking agent may retrieve documents and update workflow status. A security agent may read alerts and trigger tickets. A developer agent may inspect code and propose changes. A vendor model may process confidential context. These workflows can affect confidentiality, integrity, availability, and third-party assurance.

The autonomous part matters because security risk changes when AI can act. A chatbot that answers a question may leak information or mislead a user. An agent that can call tools can change the state of systems. It can update records, create tasks, send messages, run queries, modify code, or escalate work. The control problem therefore moves from content safety to information asset protection and delegated authority. CPS 234 gives regulated entities a strong reason to govern AI agents as information-security control subjects.

Information assets in AI workflows

CPS 234 defines information assets broadly enough to make AI governance think beyond databases and documents. In AI workflows, information assets may include source records, prompts, retrieved documents, embeddings, vector databases, context windows, model outputs, agent memory, tool-call results, workflow state, logs, policy decisions, approvals, and evidence exports. Some assets are created by the AI system. Some are passed through it. Some are inferred by it. Some are stored by vendors. Governance should identify the full information pathway.

Prompts and outputs deserve particular attention. A prompt may contain confidential or personal information even when the user thinks of it as a chat message. An output may reveal sensitive source material, create misleading records, or become part of an operational decision. Retrieved context may include documents the user is not meant to combine in that workflow. Agent memory may retain details beyond the original purpose. Logs may become valuable evidence but also sensitive information. Treating these artefacts as governed information helps avoid blind spots.

Classification should consider criticality and sensitivity. Criticality concerns the impact of losing availability. Sensitivity concerns the impact of losing confidentiality or integrity. A vector index supporting a public FAQ bot may be low sensitivity. A retrieval index containing customer financial records, health information, claims data, security alerts, or regulated reporting data is not. An agent that can write to a core system adds integrity risk even if the data it reads appears ordinary. AI governance should classify both data and action pathways.

Board and senior management accountability

CPS 234 places ultimate information-security responsibility with the board of an APRA-regulated entity and requires clearly defined roles and responsibilities across senior management, governing bodies, and individuals. For autonomous AI, that means the board and senior management should receive reporting that makes AI information-security exposure understandable. They do not need to inspect every prompt. They do need to know which AI systems and agents touch material information assets, which providers process them, which control weaknesses exist, and which incidents or near misses occurred.

Accountability should be practical. A business owner should own the AI workflow and residual risk. A security owner should own control design and testing. A data owner should own classification and access expectations. A technical owner should own implementation and logging. A vendor owner should own third-party assurance. A risk or compliance owner should ensure appropriate challenge. Internal audit should be able to test design and operating effectiveness. If no one owns the information-security consequences of an AI agent, accountability is incomplete.

Senior management should also define authority limits for autonomous AI. An agent should not inherit broad access simply because a human user has broad access. Authority should be purpose-bound where possible. Higher-risk actions should require human approval. Sensitive information should be restricted or redacted where appropriate. Exceptions should be time-bound. Control gaps should be escalated. These are governance decisions, not only engineering settings.

Information-security capability for AI

CPS 234 requires information-security capability commensurate with threats and vulnerabilities. Autonomous AI changes both. Threats include prompt injection, data exfiltration through model responses, malicious tool instructions, compromised plugins, unauthorised retrieval, insecure agent orchestration, over-permissive service accounts, vendor model changes, embedded SaaS AI exposure, and adversarial use of generated content. Vulnerabilities include weak access boundaries, poor logging, unreviewed tool permissions, unsanitised retrieval, lack of review gates, and insufficient provider assurance.

A commensurate capability should include people, process, and technology. Security teams need enough AI literacy to understand context windows, retrieval, tool calls, prompt injection, embeddings, model gateways, and agent orchestration. AI teams need security literacy to understand access control, DLP, logging, incident response, least privilege, change control, and third-party assurance. Governance teams need enough evidence to connect AI activity to security controls. Capability is not just a tool purchase. It is the ability to maintain control as AI use changes.

Capability should also include monitoring and testing. AI activity may not appear in traditional security telemetry in a useful form. A model call may look like normal HTTPS. A tool call may be authorised but contextually unsafe. A prompt injection may not exploit a classic vulnerability. An agent may use valid credentials to perform an unintended action. Security capability must therefore include AI-specific event capture: who initiated activity, what data was involved, which tool was called, what policy applied, whether approval occurred, and what outcome followed.

Controls for confidentiality

Confidentiality controls for AI should start with approved use. Which AI providers may process which classes of information? Which users may submit sensitive data? Which SaaS AI features are enabled? Which retrieval sources are approved? Which prompts or outputs are logged? Which data is redacted before model submission? Which vendors are prohibited for regulated information? Without clear rules, employees may paste sensitive data into unapproved tools and vendors may process information in ways the entity has not assessed.

Confidentiality controls should also account for indirect disclosure. A model output can reveal source content. A prompt can include personal information. A retrieval system can expose documents outside the intended context. An agent can send a generated message to an external party. A log can retain sensitive data. A vendor may use data to improve services unless contractually limited. Governance should treat disclosure as an end-to-end flow, not only as a database permission issue.

Practical controls include data classification, approved provider lists, prompt filtering, redaction, retrieval access controls, purpose-bound context, output review for external communications, DLP monitoring, contractual data-use restrictions, retention limits, and incident escalation. For high-risk workflows, the entity should retain evidence of control operation: policy decision, redaction event, approval, blocked action, or exception. Confidentiality policy that cannot be observed or evidenced is hard to assure.

Controls for integrity

Integrity controls for autonomous AI are essential because agents can change records and workflows. Integrity is not only about preventing a database from being corrupted. It is about ensuring information is complete, accurate, and free from unauthorised change or usage. An agent can compromise integrity by writing incorrect notes, updating statuses, generating misleading summaries, changing configurations, creating incorrect tickets, or triggering workflow actions based on flawed reasoning.

Integrity controls should start with least privilege and purpose-bound permissions. An agent should receive only the tool access needed for its approved task. Read access should not become write access by default. Write access should be limited to specific actions and contexts. Irreversible or customer-impacting changes should require human approval. The agent should not be able to silently modify source evidence, audit records, policy settings, or approval logs. Integrity controls should also include rollback, reconciliation, and exception review.

Testing should include misuse scenarios. Can a prompt injection cause the agent to write unauthorised changes? Can the agent combine information from two systems in a way that produces an incorrect operational record? Can a user persuade it to bypass approval? Can it create contradictory evidence? Can it act outside business hours or outside a change window? These tests turn integrity from an abstract principle into a control program. The results should feed remediation and management reporting.

Controls for availability

Availability controls matter because AI can become an operational dependency. If an AI service, model provider, vector database, orchestration layer, or agent tool is unavailable, a business process may slow, fail, or shift to uncontrolled manual work. Availability risk can also arise from model rate limits, vendor outages, broken integrations, prompt attacks that consume resources, automation loops, excessive false positives, or control-plane failures. AI governance should map availability dependencies before the business relies on them.

Availability controls include redundancy where appropriate, graceful degradation, manual fallback, queue management, provider monitoring, rate-limit handling, timeout design, incident runbooks, and recovery objectives. For critical workflows, the entity should test whether the process can continue without AI. For lower-risk workflows, it may be enough to pause AI use until service returns. The control should match the criticality of the information asset and business process.

Availability also intersects with security. A security control that blocks an AI action may protect confidentiality or integrity but create operational delay. An approval queue may become a bottleneck. A provider outage may force a team to use an unapproved tool. A continuity plan may require temporary policy exceptions. Governance should define how these situations are approved, monitored, and evidenced. The goal is not maximum automation. The goal is continued sound operation inside risk appetite.

Third-party and related-party AI assurance

CPS 234 explicitly addresses information assets managed by related parties or third parties. That is highly relevant to AI. Many AI workflows depend on model providers, cloud providers, SaaS platforms, data processors, analytics vendors, identity providers, agent frameworks, and monitoring tools. Information may be processed by a third party even when the business user sees only an internal interface. The entity should understand where information assets go and whose controls protect them.

Third-party assurance should be specific to AI use. A general security certificate may not answer whether customer prompts are used for model training, whether logs contain sensitive data, whether model changes are notified, whether subcontractors process context, whether evidence can be exported, whether data is retained, or whether an agent tool can be constrained. The entity should assess whether the provider's controls are commensurate with the criticality and sensitivity of the information assets and the consequences of an incident.

Where the entity relies on third-party testing, it should assess whether the nature and frequency of that testing are appropriate. For AI, the assessment should consider the pace of model and feature change. A vendor assurance report may become stale if the provider changes architecture, model behaviour, data handling, or tool access. High-impact AI use may require additional contractual terms, monitoring, independent testing, or compensating controls. Provider opacity should be recorded as a risk, not hidden under trust language.

Incident response for autonomous AI

AI incidents should be integrated into information-security incident response. An AI-related incident may involve data leakage, unauthorised model access, prompt injection, malicious tool use, compromised agent credentials, vendor breach, generated misinformation that changes records, unapproved disclosure, evidence tampering, or unavailable AI systems affecting security operations. The incident process should identify whether confidentiality, integrity, or availability was affected, which information assets were involved, and which parties need escalation.

The incident record should include AI-specific context. Which model or provider was used? Which user or agent initiated the action? What prompt, retrieval source, tool call, or output was involved? Which policy decision applied? Was approval required or bypassed? Was data sent to a third party? Were logs retained? What containment occurred? What remediation was required? Did the event reveal a control weakness? Was any notification assessment required? These details are essential for post-incident review and audit.

CPS 234 includes notification requirements for material information-security incidents and material information-security control weaknesses. An APRA-regulated entity must notify APRA no later than 72 hours after becoming aware of a material information-security incident, and no later than 10 business days after becoming aware of a material information-security control weakness. This report does not determine whether any AI event is notifiable. It does recommend that regulated entities build the evidence needed for the right internal teams to assess notification obligations quickly. If AI activity is not logged clearly, notification analysis may be delayed or incomplete. Incident readiness starts with evidence readiness.

Testing control effectiveness

CPS 234 requires systematic testing of information-security control effectiveness, with nature and frequency commensurate with threats, vulnerabilities, criticality, sensitivity, incident consequences, untrusted environments, and material change. Autonomous AI should be inside that testing program where it touches information assets. Testing should include normal operation, misuse, adversarial prompts, prompt injection, over-permission, vendor outage, data leakage, approval bypass, logging failure, and rollback.

Testing should be conducted by appropriately skilled people. AI security testing requires knowledge of model behaviour, prompt attacks, retrieval systems, agent tool use, identity, access control, logging, DLP, secure engineering, vendor assurance, and incident response. It should not be left only to model evaluators or only to traditional penetration testers. The right testing team depends on the workflow, but independence and skill matter. A delivery team marking its own critical controls as effective without challenge is weak assurance.

Test results should feed remediation. If an agent can access more information than intended, permissions should be tightened. If prompt injection can cause unsafe tool use, tool boundaries and review gates should change. If logs do not capture enough context, evidence design should improve. If a third-party report does not cover AI functionality, supplier assurance should be strengthened. Testing is useful only when control weaknesses are tracked, escalated, and remediated.

Internal audit and evidence

Internal audit should be able to review the design and operating effectiveness of information-security controls for AI workflows, including controls maintained by related parties or third parties where relevant. Audit needs evidence that is understandable. A pile of model traces is not enough. Audit needs to connect information assets, control objectives, policy decisions, testing, incidents, providers, approvals, exceptions, and remediation. The governance system should create that connection intentionally.

Evidence should include AI asset classification, access approvals, provider assessments, control design, tool permissions, testing results, incident records, approval events, blocked actions, exception logs, change records, third-party assurance reviews, internal audit findings, and remediation status. For autonomous AI, evidence should show what the agent was authorised to do, which tools it used, what information was involved, which policy applied, and whether human approval occurred. That evidence supports both security assurance and accountability.

Audit evidence should also preserve integrity. If records can be casually edited after an incident, assurance is weaker. For high-risk AI workflows, evidence should be time-stamped, attributable, access-controlled, and tamper-evident where appropriate. This does not mean every AI event must be retained forever. It means evidence retention should reflect criticality, sensitivity, legal requirements, business need, and incident-review expectations. Evidence is part of the control environment.

Conclusion: Helixar perspective

Helixar supports CPS 234-aligned AI governance by providing visibility, operational policy governance, and evidence for AI activity. Autonomous AI creates information-security questions that cannot be answered from static policies alone. Which users and agents sent information to which providers? Which data classes were involved? Which tools were called? Which actions required approval? Which events were blocked? Which exceptions existed? This research emphasizes capturing policy-relevant moments of AI use and preserving evidence for qualified review.

For confidentiality, this governance pattern can help restrict sensitive data movement, apply provider and data policies, alert on risky AI activity, and retain evidence. For integrity, it can help enforce review gates, tool boundaries, and blocked actions for higher-risk workflows. For availability and incident response, it can help identify AI dependencies and policy events that explain what happened during disruption. For third-party assurance, it can help show where AI traffic and activity actually flowed, rather than relying only on procurement assumptions.

Helixar does not replace CPS 234 interpretation, legal advice, security testing, provider due diligence, or internal audit. It helps operate and evidence the controls the entity chooses. In CPS 234 terms, that evidence can support security capability, control testing, incident review, third-party assurance, and audit readiness. Autonomous AI needs governance that can see and constrain action. This research focuses on that operational layer.

Concretely, for a CPS 234-regulated bank, insurer, or superannuation fund the control point is every agent action against an information asset: reading a customer record, writing a workflow status, sending an external message, or calling a third-party model. Helixar is a control plane that sits in front of or in place of the AI gateway and enforces policy at the moment of each of those actions, across every model provider, so that no confidentiality, integrity, or availability outcome depends on the agent behaving well. At each action it verifies both the user and the agent identity and context, evaluates the action against policy, and applies a graduated response of observe, alert, require approval, block, or contain, so higher-risk or customer-impacting writes stop for human approval while routine reads proceed. Because it is fail-closed by default and enforces organisation-wide cost caps, an agent that loses provider assurance, exceeds its purpose, or runs away in an automation loop is contained rather than trusted. Every one of those decisions, including who initiated it, what data was involved, which policy applied, and whether approval occurred, is recorded in a tamper-evident, independently verifiable evidence trail, and APRA CPS 234 evidence packs are mapped and delivered at implementation to give internal audit and the 72-hour notification assessment the record they need.

Implementation roadmap

Start by identifying AI information assets and pathways. Inventory AI systems, agents, providers, SaaS features, retrieval sources, embeddings, logs, prompts, outputs, tool calls, and evidence stores. Classify them by criticality and sensitivity. Link them to business owners, system owners, data owners, providers, and workflows. Pay attention to third-party and related-party processing. Many AI information pathways are invisible until specifically mapped.

Next, design controls. Define approved providers, data restrictions, access rules, agent permissions, review gates, logging requirements, DLP controls, incident triggers, testing scenarios, vendor assurance requirements, and evidence retention. Connect these controls to existing security, privacy, procurement, operational risk, and audit processes. Avoid creating a separate AI security universe where no one knows who owns the control.

Then test and improve. Run prompt-injection scenarios, data-leakage scenarios, unauthorised tool-use scenarios, vendor outage scenarios, logging failure scenarios, and incident-response exercises. Review third-party assurance. Track weaknesses and remediation. Report material gaps to management. Update controls after model, vendor, workflow, permission, or threat changes. CPS 234-aligned AI governance is not done when the agent launches. It is maintained while the agent operates.

Common failure patterns

The first failure pattern is treating prompts and outputs as informal conversation rather than information assets. The second is letting agents inherit broad user permissions without purpose limits, the failure OWASP catalogues as LLM06:2025 Excessive Agency. The third is approving a model provider but ignoring retrieval stores, logs, memory, and tool-call outputs. The fourth is relying on vendor assurances that do not cover the actual AI functionality used by the entity. The fifth is keeping AI evidence in systems that audit cannot reconstruct.

The sixth failure pattern is weak testing. Teams test model quality but not prompt injection, data leakage, tool misuse, approval bypass, logging failure, or vendor outage. The seventh is incident ambiguity. A data leak through an AI tool is treated as a user mistake rather than an information-security incident candidate. The eighth is stale control design. An agent receives new tools, but the control test and audit plan are not updated.

The remedy is to make AI security concrete. Classify the assets, limit access, define review gates, monitor events, test controls, review vendors, retain evidence, and involve internal audit. Autonomous AI is manageable when information-security governance follows the data and the action. It is risky when governance stops at the model boundary.

The takeaway

APRA CPS 234 gives APRA-regulated entities a strong information-security lens for autonomous AI. It asks organisations to protect information assets, define responsibilities, maintain security capability, manage third-party assets, test controls, respond to incidents, and support internal audit. AI agents fit naturally into that lens because they can access information, infer from it, move it, transform it, and act on it.

The key move is to expand AI governance from output review to information-asset governance. Prompts, context, retrieval, embeddings, outputs, logs, memory, tool calls, and evidence stores all need thoughtful classification and controls. Agents need purpose-bound permissions and review gates. Vendors need AI-specific assurance. Incidents need AI context. Audit needs reviewable evidence.

The safest posture is neither panic nor blind adoption. It is disciplined security governance: know what information assets AI touches, know what actions AI can take, know which controls protect those pathways, test whether controls work, and retain evidence. For autonomous AI in regulated environments, that discipline is quickly becoming table stakes.