The access problem that governance missed
When an organisation gives a new employee access to its systems, there is typically a process. A request is submitted, a manager approves it, IT provisioning creates credentials with defined scope, and an access review cycle will eventually ask whether that access is still appropriate.
When an organisation deploys an AI agent, that process often does not happen.
The agent is configured, connected to the systems it needs to function, and deployed, sometimes with access that would be unusual even for a privileged human employee. There is often no formal access request. No named approver. No access review cycle. And no clear owner who is accountable if the agent does something it should not.
This is the over-privilege problem. It is one of the most concrete and addressable AI governance gaps in enterprise environments today, and it is one that Australia's prudential regulator has now named directly.
What APRA said
APRA's 30 April 2026 letter to all regulated entities in Australia included the following observation: identity and access management capabilities have not yet adjusted to nonhuman actors such as AI agents.
This is a precise diagnosis of the over-privilege problem. AI agents are nonhuman actors. They operate with identity credentials, access rights, and system permissions. But the identity and access management practices built for human employees, least-privilege provisioning, periodic access review, role-based access control, offboarding and credential revocation, have not been extended to cover them.
APRA expected regulated entities to address this as part of their information security obligations under CPS 234, and as part of their operational risk management obligations under CPS 230. The letter does not create new legal obligations, it makes clear that existing obligations apply to AI agents, and that many entities are not meeting them.
Why agents end up over-privileged
Understanding the access problem requires understanding why it happens. Over-privilege in AI agent deployments is not usually the result of negligence. It typically follows from several compounding factors:
Broad access enables useful agents. An AI assistant that can read your email, search your documents, query your CRM, and write to your calendar is more useful than one that can only do one of those things. There is a genuine tension between utility and least-privilege, granting narrow access creates a less capable agent, and the teams deploying agents are typically optimising for capability, not access minimisation.
Task scope is often genuinely uncertain at deployment. The principle of least-privilege requires that you grant access proportionate to task requirements. But the task requirements of an AI agent are often not fully defined at deployment, particularly for general-purpose assistants. Teams respond to this uncertainty by granting broader access to avoid having to revisit permissions repeatedly.
Vendor defaults are often permissive. AI tools supplied by software vendors often request the maximum available access scope during setup. Users typically approve whatever the vendor requests, because declining some elements of the requested scope is technically complex and the consequence of doing so is often unclear.
Shadow deployment bypasses review entirely. Many AI agents in enterprise environments are deployed informally, by individual employees or teams, using personal accounts or shared service accounts, without going through any IT or security review. The access those deployments receive is never assessed by anyone with a governance perspective.
No access review mechanism exists for agents. Even where AI agent access is carefully scoped at deployment, there is typically no ongoing process to review whether that access is still appropriate. Human access reviews are a standard element of identity and access management programs. AI agent access reviews are not.
The blast radius problem
Over-privilege matters because it determines the blast radius of failure.
When an AI agent makes an error, acts outside its intended parameters, processes an injected instruction, experiences a model behaviour anomaly, or is actively compromised, the harm it can do is bounded by its access scope.
An agent with read access to a single database table can expose the contents of that table. An agent with read access to the entire customer database, the email system, the document repository, and the CRM can expose a great deal more. The difference between those two scenarios is access scope.
Security researchers have described this as the combination of autonomy and access creating compounding risk. The more autonomously an agent can act, and the broader the access it holds, the greater the potential impact of any failure mode.
This is why least-privilege is not merely a security principle, it is a risk management principle. Reducing an agent's access scope reduces the maximum impact of any failure, including failures you have not anticipated.
The three access control failures
In practice, AI agent access control fails in three ways:
1. Scope too broad at deployment. The agent is connected to systems and data that exceed what its specific function requires. A customer service agent that can write to the billing system as well as read from it. A document assistant that has access to all file shares, not just the team's workspace. A coding assistant that can access production environment credentials.
2. Scope that drifts over time. Even where initial scope is appropriate, agents accumulate access over time. Integrations are added. Tokens are reused across contexts. Service accounts are repurposed. Without a periodic review mechanism, scope creep is the default trajectory.
3. No named owner. For access governance to function, there must be someone accountable for each agent's access. In most organisations, AI agent ownership is undefined. The employee who deployed the agent may have moved to a different team. The agent itself may have outlived the project it was created for but continues to operate with live credentials.
What the access review should look like
A practical AI agent access review covers five questions:
What systems and data does this agent have access to? This is the inventory question. Many organisations cannot answer it for their AI agents. The answer requires discovery, identifying all agents in operation and cataloguing the access each one holds.
Is that access proportionate to the agent's function? For each connected system, is there a genuine operational reason the agent needs that access? Can the agent perform its intended function with narrower scope?
What can the agent do, not just read? Read access and write access carry very different risk profiles. An agent that can read customer data is a confidentiality risk. An agent that can write to customer records is an integrity risk. An agent that can initiate transactions is an operational risk. Scope review must distinguish between read and write permissions.
Who approved the access, and when? If access was granted informally or without a documented approval, that is a gap. If access was approved two years ago and has never been reviewed, that is also a gap.
Who is currently accountable for this agent? There should be a named individual who owns responsibility for the agent, including responsibility for its access scope, its behaviour, and its decommissioning when it is no longer needed.
What least-privilege looks like for AI agents
Least-privilege for AI agents is the same principle as for human employees: grant the minimum access necessary for the specific function, review that access regularly, and revoke it when no longer needed.
In practice, this means:
Narrow the scope at deployment. Resist the default of granting the maximum access the vendor requests. Work through what the agent's specific function actually requires, and configure access accordingly. Accept the constraint that a more narrowly scoped agent may be less convenient, that is the nature of the principle.
Use purpose-specific credentials. Where possible, create distinct credentials for each agent deployment, rather than using shared service accounts. Purpose-specific credentials make it possible to revoke access for one agent without affecting others, and to attribute agent actions to a specific deployment.
Apply the same offboarding process to agents that you apply to employees. When an AI tool is decommissioned, retired, or replaced, its credentials should be revoked and its access removed. Persistent token access that outlives the intended use is a common and avoidable exposure.
Include AI agents in your access review cycle. Whatever cadence your organisation uses for human access reviews, quarterly, semi-annual, annual, AI agent access should be reviewed on the same cycle, or more frequently given how rapidly agent deployments change.
Log agent actions at the operation level. Least-privilege is more effective when combined with monitoring. Operation-level logging, recording what the agent did, what data it accessed, what it wrote, enables detection of behaviour that exceeds the agent's intended scope and provides the attribution trail needed for incident response.
For boards: the two questions that matter
Boards do not need to understand the technical implementation of AI agent access control. They do need to hold management accountable for it.
Two questions are enough to establish whether the organisation has addressed this gap:
First: for every AI agent operating in this organisation, can management tell me what it has access to, whether that access is proportionate, and who is accountable for it? If the answer is no, if management cannot produce an agent inventory with access mapping and named owners, that is a governance gap that needs to be closed.
Second: are AI agents included in our access review cycle? If the answer is no, if the organisation reviews human access but has no equivalent process for AI agents, that is the gap APRA identified in its April 2026 letter, and it needs to be addressed.
These are not technical questions. They are governance questions. And they are the right questions for boards to be asking now.
Primary regulatory reference: APRA Letter to Industry on Artificial Intelligence (AI), 30 April 2026. This article is general information and does not constitute legal or compliance advice.