Agentic AI changes a foundational assumption in enterprise security: that the thing requesting access is either a human or a predictable, hard-coded service account. An agent is neither. It reasons, chains tools together, calls APIs you did not anticipate, and acts on behalf of a person who is not watching. For Australian enterprises already stretched by enterprise identity debt, this is the moment identity stops being a back-office control and becomes the operating layer for AI itself.
Why agentic AI breaks traditional IAM assumptions
Identity and access management was designed around two clean categories. Human identities get lifecycle management, MFA, and periodic access reviews. Machine identities — service accounts, API keys, certificates — get provisioned once and largely forgotten. Agentic AI collapses both categories into something new.
An agent behaves like a human: it makes decisions in the moment, interprets ambiguous instructions, and reaches for whatever tool solves the problem in front of it. But it authenticates like a machine: no browser, no push notification to approve, no second factor a person can respond to. It also operates at machine speed and machine scale. A misconfigured human account might cause damage over hours. A misconfigured agent with broad API scope can do it in seconds, repeatedly, across every system it can reach.
Three specific assumptions break:
- Static entitlement is safe. Traditional role-based access assumes the set of things an identity needs is knowable in advance. Agents discover what they need at runtime — that is the entire point of them.
- The authenticated principal is the accountable party. When an agent acts on behalf of a user, the credential presented is often the agent’s, not the person’s. Your audit trail records the wrong actor.
- Standing access is manageable. Long-lived tokens issued to agents are the new orphaned service account, except they are created faster and by more teams.
The agentic AI IAM control set
The good news is that this does not require an entirely new discipline. It requires applying identity fundamentals — the ones many organisations deferred for machine identities — with far more rigour. Four controls matter most.
1. Give every agent a first-class identity
Agents should be registered identities in your directory or identity provider, not credentials embedded in an application config. That means each agent has an owner, a business justification, a defined scope, a lifecycle, and an expiry. If an agent cannot be listed in an access review alongside human accounts, it is invisible — and invisible identities are how breaches start.
Practically, this means treating agent onboarding like joiner-mover-leaver. When an agent’s use case is retired, its identity, tokens, and downstream entitlements are revoked together. This is standard identity governance practice extended to a new population.
2. Separate the agent’s identity from the user’s authority
The most consequential design decision in agentic AI is how delegation works. There are two viable patterns:
On-behalf-of (delegated) access — the agent exchanges the user’s token for a scoped, short-lived token that carries the user’s entitlements, constrained to what the task needs. The agent can never exceed what the requesting user could do themselves. This is the safer default for agents serving individual users, and OAuth 2.0 token exchange gives you a standards-based way to implement it.
Agent-owned (autonomous) access — the agent holds its own narrowly-scoped entitlements, independent of any user. Appropriate for background automation such as reconciliation, monitoring, or ticket triage, where there is no human in the loop. Here the scope must be minimal and the monitoring aggressive, because there is no user permission ceiling to contain it.
The failure mode to avoid is the middle ground most pilots land in: an agent with broad, admin-like permissions serving many users, where every user effectively inherits the agent’s power. That is privilege escalation by architecture.
3. Make access ephemeral and just-in-time
Standing privilege is the risk that compounds. Agents should receive short-lived credentials, scoped to a single task or session, issued at the moment of use and expired immediately after. The privileged access management patterns enterprises already use for administrators — vaulting, brokered sessions, time-bound elevation, approval workflows for sensitive scopes — map directly onto agent access. If you have already built just-in-time elevation for humans, you have most of the machinery.
4. Log the reasoning, not just the request
Conventional access logs record that an identity called an API at a point in time. For agents that is insufficient. When something goes wrong, the questions are: which user prompted this, which agent handled it, what plan did it form, which tools did it invoke, and what data did it touch along the way. That requires correlating the originating user, the agent identity, the session, and every downstream call into a single traceable chain. Build this in from the start — retrofitting provenance into an agent platform after an incident is painful and often impossible.
What this means under Australian regulation
For APRA-regulated entities, CPS 234 obligations do not soften because the actor is an AI. Information assets accessed by agents still need classification, controls proportionate to criticality, and testing of control effectiveness. If an agent can read customer data, it sits inside your security control framework and inside your incident notification obligations. CPS 230 adds operational risk and service-provider considerations where the agent platform or model is vendor-supplied.
The Essential Eight also has a direct read-across. Restricting administrative privileges is the mitigation most obviously stressed by autonomous agents, and application control becomes interesting when an agent can decide at runtime which tools to invoke. Australian organisations should expect assessors to ask how agent identities are governed, not whether AI is in use.
Across APAC the pattern is similar — MAS technology risk guidelines in Singapore, and privacy regimes across the region, land on the same core question: can you demonstrate who or what accessed the data, under whose authority, and with what controls in place.
A practical starting sequence
Organisations that navigate this well tend to move in the same order:
- Inventory the agents you already have. Copilots, automation scripts with LLM calls, vendor features switched on by a business unit. Most enterprises find more than they expected, and almost none of it is in the identity register.
- Bring agent identities under governance. Owner, purpose, scope, expiry, and inclusion in access certification cycles.
- Fix delegation before scale. Decide the on-behalf-of versus autonomous pattern per use case, and enforce it in the platform rather than by convention.
- Eliminate standing credentials. Move agents to short-lived, task-scoped tokens brokered through your PAM platform or identity provider.
- Instrument end-to-end traceability. User to agent to tool to data, in one correlated trail your security operations team can query.
- Then expand. Scale agent use cases only once the first five hold under load.
This sequence deliberately mirrors the discipline that separates successful production deployments from stalled experiments — a theme we covered in Agentic AI for the Enterprise: From Pilots to Production. The organisations that get agents into production are the ones that solved identity first, because identity is what makes autonomy auditable.
Identity is the control plane for enterprise AI
The distinction between standard user access and privileged, non-human access is worth revisiting here. If that difference is not clear across your teams, our explainer on IAM vs PAM is a useful grounding before you design agent access.
The strategic point is simple. Every meaningful constraint you can place on an autonomous system — what it can see, what it can change, on whose authority, for how long — is expressed through identity. Model guardrails and prompt-level controls are useful, but they are advisory. Identity controls are enforceable. An agent that cannot obtain a token for a system cannot act on that system, regardless of what it decides to do.
Enterprises that treat agentic AI as an identity programme rather than purely an AI programme will move faster, because they will not have to stop and rebuild controls when the first agent does something unexpected in production.
Where Delivery Centric fits
Delivery Centric has spent years delivering identity and access management, privileged access, and identity governance programmes for banking, telecommunications, healthcare, and government clients across Australia and APAC. That same foundation is what agentic AI now depends on. We help organisations extend existing IAM and PAM capability to cover agent identities, design delegation and just-in-time access patterns that stand up to audit, and build the traceability regulators will ask for.
If you are piloting agents and want the identity architecture right before you scale, get in touch with our team for a working session on your current state and the gaps that matter. And if you would rather build this from the inside, we are hiring identity and cloud security specialists across our Australian and APAC offices — see our current openings.
Recent Comments