Wesfarmers has agents running across Kmart, Officeworks, Bunnings, Priceline and OnePass. ANZ has Salesforce Agentforce embedded across its national business banking rollout, the first APAC deployment at that scale. From 1 July, the entire Australian Public Service can pull Microsoft Copilot agents through the new whole-of-government Microsoft deal. Every one of these deployments passed procurement. Almost none of them cleared identity governance.
That is the gap now sitting on every Australian CIO's desk. And the calendar makes it a five-month problem, not a strategic one.
The two deadlines that reframe the conversation
Two Australian regulators have already moved on this, and their timing lines up on purpose.
APRA's Letter to Industry on Artificial Intelligence dated 30 April 2026 was short and unambiguous. Regulated entities are expected to extend their identity governance frameworks to explicitly include AI agents as governed identities. Assurance practices, APRA said in the same letter, are failing to keep pace with the scale, speed and complexity of AI adoption. In prudential language, that is a warning shot.
The OAIC is running the second track. On 10 December 2026, APP 1.7 to 1.9 commence under the Privacy Act. APP entities using personal information in automated decision-making that could reasonably be expected to significantly affect an individual's rights or interests will have to disclose the kinds of information used and the kinds of decisions made. The OAIC has said its formal guidance will land by September 2026. The Commissioner has also signalled a broad reading of "substantially and directly related to making a decision", which pulls in agent-assisted workflows, not only fully autonomous ones. If a Copilot agent reads a customer file and drafts a rejection letter for a human to sign, the obligation attaches.
So the December 2026 deadline is not about the model. It is about proving what an agent touched, on whose behalf, under what authority, and for what purpose. That is an identity problem before it is a privacy problem.
What actually changed inside the SaaS estate
Traditional identity architecture assumes a person logs in, works inside a session, and logs out. Every mature Australian enterprise built its IAM around that pattern. Okta, Entra ID, SailPoint, CyberArk: all optimised for humans with entitlements and reviewers.
Agents break every assumption in that model.
An agent runs unattended for hours, sometimes days. It jumps between systems that were never designed to trust one another. It reasons, adapts, and discovers tools at runtime. It can spawn other agents. It carries the standing access of the identity it was provisioned under, usually a broad service account or a delegated user, and it holds that access whether the deploying human is at their desk or on annual leave.
The scale is not marginal. Non-human identities already outnumber human users in most enterprises by 100 to 1, and in some environments the ratio hits 144 to 1. Copilot Studio users alone have created more than one million agents since 2025. Salesforce reported roughly USD 440 million in Agentforce-linked revenue last year. Inside an Australian enterprise deploying across email, files, CRM and finance, the number of agent identities can now exceed the total headcount within a single quarter.
The governance gap sits underneath that number. A 2026 industry survey found 92% of security leaders agree governing AI agents is critical, but only 44% have implemented any policy. 78% of organisations have no documented process for creating or removing AI agent identities. Around 80% of agents surveyed had already performed actions beyond their intended scope, including accessing systems they were not authorised for and sharing sensitive data outside the intended perimeter.
None of that shows up on an APRA return or an OAIC privacy policy today. All of it will need to, soon.
Why current Australian frameworks miss it
Three frameworks anchor Australian enterprise identity practice, and none of them were written with autonomous software identities in mind.
CPS 234 covers information security for APRA-regulated entities. It obliges boards to maintain information security capability commensurate with the size and extent of threats to information assets. It does not describe how to enrol, monitor, review or retire an AI agent as an identity object.
The Essential Eight, published by the Australian Cyber Security Centre, is the operational baseline most Australian security teams are measured against. Application control, restricting admin privileges, patching, MFA: all designed for human accounts and traditional endpoints. Agents that hold delegated OAuth tokens across ten SaaS platforms do not fit the model.
ISO 27001 sits behind most vendor onboarding requirements. Its Annex A controls cover access management and cryptographic controls in language that assumes stable, human-authorised sessions. Autonomous agents that request just-in-time task tokens and negotiate access at runtime do not.
APRA's April letter was, in effect, an acknowledgement that these frameworks need extending, and that the extension is the regulated entity's responsibility, not the standard body's. The OAIC guidance in September 2026 will function similarly. It will describe what has to be disclosed. It will not describe how to instrument an agent's identity so that disclosure is possible in the first place.
The five layers of an agent identity control model
An enterprise-grade agent identity model has to answer five distinct questions. Each one produces evidence for the next.
Registration. Every agent gets a unique, machine-readable identity object at creation time. Not a shared service account. Not a delegated user credential. An identity that carries the deploying human owner, the business purpose, the data domains it is allowed to touch, the model provider, and the tools registered against it. This is the record APRA and the OAIC will eventually ask to see.
Delegation. Agents almost never act as themselves in a vacuum. They act on behalf of a business owner, a customer, or a workflow. Delegation captures who authorised the action and under what scope. OAuth 2.0 Token Exchange (RFC 8693) and Rich Authorization Requests (RFC 9396) exist for this reason. Both let the authorisation server issue tokens scoped to a specific task context, not a standing entitlement. Enterprises deploying Copilot, Agentforce or Gemini Enterprise at scale need to be able to point at the delegation record for any material action, not the login record.
Authorisation. Scopes for AI agents in most SaaS products are still too broad. A user-level "Files.ReadWrite.All" scope grants an agent the same reach across a Microsoft 365 tenancy as a human power user, without the checks a human hire would trigger. Task-level authorisation, backed by fine-grained scopes, is the standard emerging in enterprise agent deployments. WorkOS, Scalekit, Strata, Okta Auth for GenAI, and CyberArk Secure AI Agents are converging on that pattern from different starting points.
Runtime assurance. Configuration-time approval is not enough. Agents change what they do at runtime, discover new tools, chain into other agents, and can be manipulated through prompt injection or poisoned tool metadata. The identity control needs to continue evaluating whether an action still fits the registered purpose, and interrupt when it does not. Runtime policy engines that sit between the agent and the SaaS APIs are how most mature deployments now enforce this.
Termination. Agents proliferate faster than humans and disappear less predictably. A pilot that ran for six weeks leaves credentials, tokens, connectors and cached state behind. A working identity model treats termination as a first-class lifecycle event, revokes tokens across every downstream system, and archives the evidence trail. The 78% of organisations with no documented process for removing AI identities are the ones sitting on the largest silent risk.
An enterprise that can answer these five questions for every production agent will have most of what APP 1.7 disclosure requires already sitting in its identity graph.
The Australian enterprises already on this curve
The pattern inside the biggest Australian AI deployments is instructive. Wesfarmers hedged its Gemini Enterprise rollout with a parallel Microsoft deal. Executives at Wesfarmers have spoken publicly about running a custom AI upskilling programme for staff so that agent deployment sits inside a defined operating model, not outside it. Behind that, the identity work is happening quietly: agent registration inside its own Google Cloud IAM structure, delegated authority scoped to specific brands and workflows, audit trails at the Gemini Enterprise layer.
ANZ's Agentforce rollout replaced twenty legacy systems, consolidating data and rebuilding the trust boundaries at the same time. That kind of migration only works if identity is treated as an architectural layer, not a deployment afterthought. ANZ's stated goal of growing business banker headcount by nearly 50% while improving productivity through technology assumes agents can operate with real customer data under a governance model APRA will accept.
The APS Microsoft deal is the one to watch most closely. The Australian Public Service is now the largest single agent-eligible tenancy in the country. The whole-of-government agreement gives every eligible agency access to Copilot, Azure and Dynamics 365 under a single procurement wrapper. Every Copilot agent enrolled inside a departmental tenancy will touch personal information about Australians. APP 1.7 attaches. So does the OAIC's stated expectation of a broad reading. So does the Commonwealth's own Digital Transformation Agency guidance on responsible use.
Enterprises without that structural clarity are approaching December 2026 in a very different position.
The July to December operating plan
Five months is enough time to close the gap, if the work is sequenced properly.
The July task is inventory. Not a spreadsheet exercise. A live catalogue of every AI agent currently running inside the tenancy, whether it was deployed by IT, by a business unit, or by an individual employee under a shadow SaaS budget. Copilot agents, Agentforce agents, Gemini agents, custom internal builds, browser-based automations, third-party assistants embedded inside other SaaS products. If the identity team cannot see it, it is already outside governance.
August moves to classification. Which agents touch personal information. Which touch decisions that could reasonably significantly affect an individual. Which sit in the payments, credit, hiring, welfare or clinical pathways where the OAIC will look first. Which sit inside APRA-regulated business lines where the April letter already applies.
September to October is the control layer. Rebuild registration around identity objects that carry owner, purpose, scope and audit fields. Move away from shared service accounts. Implement Token Exchange for delegated actions. Restrict OAuth scopes to task level. Deploy a runtime policy engine that can evaluate actions against the registered purpose. This is engineering work, not policy work, and it takes a real team six to eight weeks.
November is disclosure drafting. Privacy policies need to describe the kinds of personal information used in automated decision-making and the kinds of decisions made. Legal will draft that language. The identity graph has to feed it. Enterprises that get to November with no live agent catalogue will publish disclosures they cannot defend.
Early December is dry runs and board attestation. APRA-regulated entities should be able to answer, in a single briefing, which agents are in production, what identities they hold, what data domains they touch, and what evidence exists that they operated inside scope. The board will eventually be asked this in a review or a hearing. Better to answer it once inside the organisation first.
What buyers will start expecting from vendors
The identity work does not stop at the tenancy boundary. Every SaaS vendor selling agent capability into Australian enterprises will be pulled into the same conversation.
Expect procurement questionnaires to add:
- Whether the vendor supports task-level OAuth scopes for agent actions
- Whether Token Exchange or Rich Authorization Requests are available for delegated agent work
- Whether the vendor exposes a per-action audit trail that identifies the agent, the delegating user and the tool invoked
- Whether the vendor supports enterprise-managed agent identities rather than shared platform accounts
- Whether agent lifecycle events (create, modify, terminate) can be exported to the enterprise IAM system
- Whether the vendor has a documented process for handling prompt injection and tool poisoning incidents
Vendors that cannot answer these questions confidently will lose competitive positions in Australian enterprise renewals through late 2026 and 2027, particularly inside APRA-regulated buyers and government procurement.
Wai works with enterprise buyers preparing agent identity readiness and with technology vendors reshaping their platforms to meet those buyer questions. ARC, Wai's authority and AI visibility platform, is used by technology companies whose credibility inside AI answer engines depends on being cited for exactly this kind of substantive guidance rather than surface commentary.
The board question that changes everything
The uncomfortable question sitting behind APRA's letter and the OAIC's guidance is a simple one. When an AI agent takes an action that harms a customer, breaches a policy, or triggers a regulatory review, can the enterprise show, from a single system of record, who authorised it, under what scope, and what evidence exists that it operated within that scope?
Almost no Australian enterprise can answer that question today for its agent estate. Every Australian enterprise will be expected to by December 2026.
The technology to close the gap is already in market. The regulatory motivation to close it has already been published. The board-level attention required to fund it is the variable in play right now.
Frequently Asked Questions
How do you govern AI agents in enterprise IAM?
Register each agent as a unique, non-shared identity carrying owner, purpose, scope, and audit fields. Delegate authority through explicit protocols like OAuth Token Exchange rather than blanket service account tokens. Enforce task-level scopes at runtime. Instrument every action for audit, and terminate agent identities with the same rigour as offboarding a privileged user. Governance for agents is a runtime discipline, not a configuration setting.
What does APRA CPS 234 mean for AI agents in Australia?
CPS 234 does not name AI agents directly, but APRA's 30 April 2026 Letter to Industry made the interpretation explicit: identity governance frameworks must extend to include AI agents as governed identities. Regulated entities are expected to apply the same rigour of access review, privileged access management and continuous monitoring to agents that they apply to human privileged users. APRA also flagged that current assurance practices are not keeping pace with AI adoption.
What must Australian companies disclose under APP 1.7 for automated decision-making?
From 10 December 2026, APP entities using personal information in decisions that could reasonably significantly affect an individual must disclose in their privacy policies the kinds of personal information used and the kinds of decisions made. The obligation applies where a computer program is used to make or do a thing substantially and directly related to making a decision, including where a human remains in the loop. The OAIC will release formal guidance by September 2026 and has signalled a broad reading of scope.
How do you give AI agents least-privilege access in production?
Move away from user-level or blanket admin scopes. Use task-scoped OAuth tokens, RFC 9396 Rich Authorization Requests, or vendor-native fine-grained permission models. Bind the token lifetime to the task, not to a standing session. Interpose a runtime policy engine between the agent and downstream APIs to enforce the intended scope even if the agent reasons its way toward an out-of-scope action.
What is a non-human identity and how is it different from a service account?
A non-human identity is any digital credential used by a system, workload, application or automated process to authenticate and take action. It includes service accounts, but also API keys, secrets, tokens, workload identities, and now AI agents. AI agents differ from traditional service accounts because they do not follow a predictable script. They adapt at runtime, discover tools, and can chain into other agents. That requires an identity model that evaluates behaviour continuously, not just at provisioning time.
How do you audit AI agent actions across SaaS platforms?
Require every agent action to carry an identifiable agent identity, the delegating human owner, the invoked tool, and the data domain touched. Centralise the audit stream into a single system of record rather than relying on each SaaS platform's native logs. This is what makes APP 1.7 disclosure defensible and what allows an APRA-regulated entity to reconstruct what an agent actually did, not just what it was authorised to do.
How should Australian enterprises prepare for 10 December 2026 ADM transparency?
Inventory every AI agent in production, classify which ones touch personal information and consequential decisions, rebuild identity registration around dedicated agent identity objects, restrict OAuth scopes to task level, deploy runtime policy enforcement, and draft privacy policy language grounded in the live agent catalogue. Board attestation and dry runs should be complete before the OAIC guidance lands in September 2026, not after.
What OAuth scopes should an AI agent have inside an enterprise?
The narrowest scopes required to complete the task at hand, issued for the shortest useful lifetime. Standing user-level scopes like broad "read all files" or "write all mail" grants should be avoided for agent identities. Task-context scopes issued through Token Exchange or Rich Authorization Requests, refreshed per task, and revocable independently of the delegating human user, are the emerging enterprise pattern.
Wai is an Australian technology studio building AI, SaaS and platform infrastructure for enterprises operating at the intersection of regulation, agent adoption and identity governance. ARC is Wai's authority and AI visibility platform for organisations that need to be discoverable, and citable, inside modern AI answer systems.