APRA AI Governance: Why Access Controls Don’t Work on AI Agents
Your access model assumes a person behind every credential. AI agents don’t fit that assumption, and APRA has noticed.
Most of the commentary on APRA’s April 2026 letter has focused on inventories, dependencies and boards. One line gets skipped over: identity and access management has not adjusted to non-human actors. An agent is not a person, does not work office hours, and will do the same thing ten thousand times without noticing it’s wrong. This piece looks at what that means in practice, and what evidence a governed agent actually needs to produce.
There’s a simple test for where you stand: if a supervisor asked today for your AI inventory, its dependencies and its controls, would the answer be assembled, or retrieved?
We’ve turned APRA’s five questions into a free one-page checklist that names what a supervisor or internal auditor would expect to see under each one: not what to buy, what to look for.
The Agentic Blind Spot in AI Governance
Every access model most entities run today assumes a person behind the credential. Someone logs in, does something, logs out. Reviews happen on a schedule that matches how people work: quarterly, or after a role change.
An AI agent breaks that assumption in every direction. It doesn’t request access once and use it occasionally. It calls the same system thousands of times a day, often across data sources a human in that role would never touch in a year. When something goes wrong, the question isn’t just what the agent did. It’s what it was allowed to see, on whose behalf, and whether anyone can prove that afterward.
What APRA’s Letter Says About Non-Human Identity
APRA’s April 2026 letter didn’t introduce a new AI standard. Its framework stays principle based, and technology and vendor agnostic. What it did was name a specific gap: identity and access management capabilities have not yet adjusted to non-human actors such as AI agents.
The letter also flagged a widening attack surface that sits directly behind this gap: prompt injection, data leakage, insecure integrations, exploit injection, and manipulation or misuse of autonomous agents. It went further on frontier models specifically, engaging across the sector on increased cyber threat and pointing entities toward current ASD advice. APRA’s own summary was direct: the speed at which entities can identify and patch vulnerabilities needs to move much faster, in line with an AI-accelerated threat.
None of this is a compliance deadline. It’s a description of where existing controls stop working, because they were built around a different kind of actor.
Why a Policy Isn’t a Control
APRA’s supervisory review found something specific about how entities were responding to shadow AI: staff using enterprise AI tools outside approved frameworks, and where controls existed, they were mostly policy, or detective and after the fact, rather than actual technical restrictions.
There’s a real difference between the two. A policy that says an agent should not access customer PII is a rule. Something that stops the agent from retrieving it in the first place is a control. Most data security programs are full of the former and thin on the latter, and an agent operating at machine speed will find every gap between them.
The rule
Written into a policy document. Assumes the reader will comply, and that the reader is a person who can read it.
The gap
Enforcement depends on a human noticing after the fact, usually in a log nobody reviews until something has already gone wrong.
The control
Classification and access policy applied at the point of retrieval, so the restriction holds regardless of who or what is asking.
Governing What an Agent Is Allowed to See
Closing this gap is a metadata orchestration problem before it’s an AI problem. An agent needs to know, at the moment it asks, what a piece of data is, how it’s classified, and what the requesting user or process is actually entitled to see. That context has to travel with the data, not sit in a separate policy document the agent never reads.
This is also where structural change matters. A data source shifts shape, a new field appears, a classification changes upstream, and an agent needs that reflected immediately, not at the next scheduled review. What’s realistic today is retained change history rather than a reconstruction after the fact: nothing is overwritten, and structural drift is detected on every re-harvest of the estate. That’s a meaningfully different claim from a live, point-in-time view of every dependency, and it’s the honest version of what continuous monitoring looks like in practice.
An automated data lineage tool built for this does more than trace where data came from. It connects that lineage to policy and classification, so the same governed context an agent retrieves is also the evidence an auditor can retrieve later. That’s the practical shape of agentic data operations: governance that’s built into how the estate runs, not a parallel process someone owns for the next review cycle. Analysts including Gartner have described this convergence of metadata orchestration and AI governance as one of the more consequential shifts in how enterprise data programs are structured going forward.
What This Looks Like in Practice
Alex Solutions provides governed context to whatever is asking for it, human or agent, through the same interface. When an assistant or an autonomous agent requests data, it receives back what that data is, its classification, and what the requesting user is entitled to see, and answers within those bounds. The same interface works whether it’s Alex’s own assistant or an enterprise AI tool built somewhere else in the organisation.
This is the same lineage and data risk foundation Alex Solutions has applied with two of Australia’s Top 4 banks on APRA-aligned data risk and BCBS 239 work, extended to the identity questions the agentic era raises. It doesn’t claim to satisfy APRA on its own. What it gives you is something to hand a supervisor, and something a sceptic can push on.
Frequently Asked Questions
What does AI governance mean when the actor isn’t a person?
It means classification, access policy and audit evidence have to work the same way for an agent as they do for a human user, applied automatically at the point data is requested rather than reviewed afterward by a person.
Does APRA require identity controls specifically for AI agents?
APRA’s April 2026 letter doesn’t introduce a new standard or a specific technical requirement. It identifies that identity and access management has not adjusted to non-human actors, and signals this as an area supervision will focus on going forward.
What’s the difference between a data policy and a data control for AI?
A policy states what should happen, such as an agent not accessing customer PII. A control enforces it technically at the point of access, regardless of whether the request comes from a person or an agent, so the restriction doesn’t depend on someone noticing after the fact.
How do you monitor AI agents without a point-in-time audit?
By retaining change history instead of overwriting it, and detecting structural drift, such as a new data source or a shifted schema, on each re-harvest of the estate. That gives a continuous record to check against, rather than a single snapshot taken once a year.
See how governed context reaches an AI agent, not just a person.
Revan Oluklu and Roberto Sammassimo walk through this exact identity gap, and a working demonstration of governed context reaching an AI agent through the same interface a human uses, in our on-demand webinar on APRA’s AI risk expectations. Alex Solutions supports APRA-aligned AI governance and evidence-readiness. It does not replace privileged access management, model validation, legal review or supplier contracting.
