.png)
A look at APRA's letter to industry on AI, what it signals for securing AI and agents, and what security leaders should be doing about it.
It is clear that AI adoption in financial services has moved well past experimentation, with banks, insurers and superannuation trustees putting AI into customer-facing work such as claims triage, loan application processing, and fraud and scam disruption.
That said, the governance and security practices around that adoption have been slower to mature, and regulators have started to say so in writing. On 30 April 2026, the Australian Prudential Regulation Authority (APRA) published a letter to industry on AI, sent to every entity it regulates, warning that governance, risk management, assurance and operational resilience are not keeping pace with AI adoption.
In this article, I will walk through why the letter carries the weight it does, what it signals about securing AI and agents, what security leaders should be doing in response, and where we at Noma can help.
So, let's check it out!
Why a Letter Carries This Much Weight
For those unfamiliar, APRA is Australia's prudential regulator, responsible for the safety of authorised deposit-taking institutions, general, life and private health insurers, and superannuation funds. It works through prudential standards and direct supervisory pressure on boards and accountable executives, which makes it a different animal from a privacy or technology regulator.
The letter grew out of a targeted engagement APRA ran in late 2025 with a group of the largest banks, insurers and superannuation trustees, and it was published for the benefit of all regulated entities, including those earlier in their AI adoption. It was signed by APRA Member Therese McCarthy Hockey, and its attachment is written specifically to help CROs, CTOs and CISOs understand what APRA expects.
I want to help unpack what the letter signals for industry. First, it is worth clarifying that it creates no new prudential standard. APRA describes its framework as "technology and vendor agnostic", and its position is that the existing standards already apply to AI. Ironically this is a sentiment being echoed by policy makers in the U.S., including recently by our former head of the FTC, in the wake of AI security incidents.
Some of those existing APRA standards include CPS 234 on information security, where the board is ultimately responsible and material incidents must be reported to APRA within 72 hours, CPS 230 on operational risk, which came into force on 1 July 2025 and applied to pre-existing service provider contracts from 1 July 2026 at the latest, and CPS 220 on risk management, with CPG 235 covering data risk alongside them.
For security leaders, that framing has a practical consequence. There is no implementation runway to wait out, because the obligations are already on the books. APRA states plainly that where entities fail to identify, manage or control AI risks in a manner proportional to their size, scale and complexity, it will take stronger supervisory action and pursue enforcement where appropriate. It is also finalizing a forward plan of entity prudential reviews, thematic activities and AI supplier engagement.
Law firm Clayton Utz described the letter as APRA's first published AI-specific expectations of boards and accountable executives, and the most prescriptive AI-specific intervention APRA has made. Eight days later, ASIC followed with its own open letter to licensees on AI-accelerated cyber threats, calling cyber resilience a core licensing obligation.
For those of us outside Australia, including myself, I would read this as a preview, as other nations will inevitably look to follow in the path of nations ahead of the pack on governing AI risks. APRA reviewed how its largest institutions are running AI and published specific expectations against rules it already had, with no new legislation needed. Other regulators with principle-based frameworks can do the same.
What APRA Signaled on Securing AI and Agents
The cover letter speaks mostly to boards, while the attachment is where security practitioners should spend their time, and a good portion of it deals with agents specifically, which is unique, as some other nations have lumped agents in with broader AI, while some have called it out specifically.
APRA observes that AI adoption is materially changing the cyber threat landscape for regulated entities, and it names the attack pathways it is seeing, which include prompt injection, data leakage, insecure integrations, exploit injection, and the manipulation or misuse of autonomous AI agents. If you’re in cyber and focused on securing AI and agents, many of those likely sound familiar because they have been involved in incidents, vulnerabilities of course featured in publications such as the OWASP Agentic AI and LLM Top 10’s. Seeing a prudential regulator list agent misuse next to prompt injection tells you how far the conversation has moved in a short time, especially when regulation tends to lag technology historically.
It then gets into the control gaps. Identity and access management capabilities have not yet adjusted to nonhuman actors such as AI agents. The volume and speed of AI-assisted software development is straining change and release management controls, and security testing programs have gaps in scope and coverage for AI implementations. This isn’t too surprising given how rapidly AI has impacted fields such as software engineering but it is reassuring to see our industry in cyber look to quickly address the challenges.
APRA also raises staff using enterprise AI tools outside approved control frameworks (e.g. shadow usage). It commends entities for encouraging experimentation, but found that in many cases they were relying on policy direction or detective, after-the-fact measures, with enforceable technical restrictions and preventative controls lacking. Anyone who has tried to manage shadow IT, shadow SaaS and now shadow AI with an acceptable use policy knows how that tends to go. Visibility is foundational, but ultimately we need runtime enforcement to mitigate risks.
On governance, APRA found that most entities recognize the existing standards apply to AI, yet few have operationalized governance in practice, with a tendency to treat AI risk as "just another technology". The resulting gaps sit across the lifecycle, including post-deployment monitoring, model behaviour monitoring, change management and decommissioning.
Suppliers get similar treatment. Some entities depend heavily on a single provider across multiple AI use cases, few had tested exit or substitution strategies, and contracts lagged on audit rights, model updates and incident notification. APRA also points out that AI is increasingly embedded in software, platforms and developer tools, which leaves upstream dependencies such as foundation models, training data sources and fourth parties opaque to the entity relying on them.
One of the observations I expect to age well is on assurance. APRA found entities leaning on point-in-time and sample-based assurance methods, which it calls ill suited to probabilistic models that learn, adapt and degrade over time. This is a point I’ve made myself many times, calling for GRC to evolve from an analog to digital era, and move away from static, snapshot in-time assessments towards real continuous assurance.
The language also calls out that few had continuous validation or monitoring in place, and many internal audit and risk functions lacked the specialist skills and tools to assess AI, particularly where agentic behaviour, automated decision making or AI-assisted code generation were involved. As someone who has spent years criticizing snapshot-in-time compliance, it is encouraging to see a regulator say the same thing about AI.
Lastly, the letter notes that APRA is engaging across the sector on increased cyber threats from high capability frontier models, points entities to current ASD advice, and acknowledges that AI can also help identify and resolve vulnerabilities. The challenge it flags is one every vulnerability management team will recognize, remediating at the speed with which vulnerabilities are now being found.
What Security Leaders Should Be Doing
APRA's expectations are written as minimums, and they translate fairly directly into a work plan. I won't belabor every item, but several deserve priority if you’re looking at securing your organizations use or dependencies as it relates to AI and agents.
The fundamental critical security control is inventory. APRA expects an inventory of AI tooling and AI use cases, with ownership and accountability running from design through to decommissioning. A spreadsheet populated by an annual survey will be stale the week it is finished, given how quickly agents, MCP servers and coding assistants show up in an environment. The inventory needs to be discovered continuously, and each asset needs a named owner.
Next, treat agents as entities with distinct identities. APRA's finding that IAM has not adjusted to nonhuman actors lines up with what most of us see in practice, agents running on shared or over-permissive credentials with nobody quite sure what they can reach. Know which identities, roles and credentials each agent uses, and apply privileged access management to them the way you would a human administrator. We’ve already struggled with securing IAM for decades, and the explosive growth of agents is poised to add fuel to that fire.
Then move from detective to preventative controls and activities. APRA explicitly expects controls over agentic and autonomous workflows, and it was critical of entities relying on policy and after-the-fact detection. That means enforcement at runtime, where you can inspect what an agent is about to do and block it if it falls outside policy, along with human involvement for high-risk decisions.
Testing needs to become recurring, not a snapshot-in-time. The expectations cover penetration testing, automated vulnerability discovery, and robust security testing across AI-generated code, software components and libraries. A single pre-production assessment of a system whose model, prompts and tools keep changing gives you limited assurance, so testing should be triggered by change as well as by the calendar.
Map the AI supply chain, including fourth parties, and feed it into your material service provider work under CPS 230. Where AI supports a critical operation, APRA requires a credible fallback process, and credible means it has been exercised.
Equip the second line and internal audit. APRA expects them to have the technical capability and tooling to independently assess AI systems, including agentic workflows. Security leaders can help by giving risk and audit direct access to evidence, so they are not dependent on the delivery teams they are meant to challenge. The same evidence gives the board something more factual than the vendor presentations APRA found many of them relying on.
Finally, take APRA up on its invitation to engage and work collaboratively. The letter strongly encourages entities to engage early with its Non-Financial Risk Team on unexpected or heightened AI-related risk concerns.
Where Noma Helps
I’m Noma’s VP of Security Strategy, so read this section with that context in mind. Yes, I am a “vendor”, but I’m also a longtime security practitioner, having lived with these sorts of requirements in prior technological paradigms, including in high-assurance and regulated environments here in the U.S. I also want to be specific about which expectations a platform like ours addresses, because several of them are organizational and no vendor should claim to meet them for you.
On inventory and ownership, Noma continuously discovers AI across cloud AI services, low-code agent platforms, source code, model registries, data platforms and endpoints, building a register of models, agents, datasets, tools and MCP servers. Every asset carries an owner, environment, source, and first-seen and last-seen dates, so new assets surface for onboarding and assets that stop being observed surface for decommissioning review. Doing this sort of inventory, especially on dynamic technologies like AI and Agents manually and without a purpose-built platform would be incredibly difficult.
On preventative controls, Noma's AI detection and response (AIDR) detects and blocks prompt injection, sensitive data in prompts and responses, malicious content in tool results, and unsafe tool and MCP calls. Runtime Protection Profiles inspect each agent tool call with its actual arguments and block actions outside policy, such as destructive operations or data movement. Endpoint and SaaS discovery finds unsanctioned agents, coding assistants and MCP servers, and runtime policy on those surfaces turns a detective finding into an enforceable restriction, which is the exact gap APRA called out. Having policy around these sorts of risks is one thing, but you ultimately need a way to enforce it.
On testing and assurance, Noma runs scheduled and CI/CD-triggered red teaming against deployed models and agents, with retests, so regressions get caught when models, prompts or tools change. Risk and audit teams can run their own red-team campaigns and read inventory, posture and session evidence independently of delivery teams. Policies and issues carry alignment to ISO/IEC 42001, NIST AI RMF, MITRE ATLAS and OWASP, among others, with export to GRC tooling, allowing you to pull evidence of controls into your GRC platform of choice to work collaboratively with internal and external auditors and assessors.
In other areas Noma contributes evidence while the function stays with the entity. We map the identities and credentials each agent uses and flag over-permissive access, and the IAM platform remains yours. Our dependency and lineage view shows the foundation models, providers, MCP servers and datasets behind each agent, which feeds the material service provider register, while contracts, exit plans and substitution are yours to negotiate and test. Detections reach the SOC through SIEM and webhook integrations as they happen, and classification, escalation and the 72-hour APRA notification remain your process. Board education, risk appetite, and statistical model performance and bias monitoring sit outside what we do.
We have published a solution brief that maps each of APRA's expectations to these capabilities line by line, for anyone who wants the detail.
Closing Thoughts
This is far from an exhaustive discussion of the letter, and much remains to be seen about how APRA's supervisory plan plays out over the next year. That said, the direction is clear. A major financial regulator has looked closely at how its largest institutions are securing AI and agents and found security and assurance practices trailing adoption, with its expectations tied to standards that are already enforceable.
Security has been late to nearly every prior technology wave, and then spent years bolting controls on after the fact. With agents, we have the regulator's expectations in writing while the architectures are still taking shape. Will we use that head start?
