I have watched organisations stand up their first serious agent and discover, weeks later, that nobody could answer a question a junior security analyst would ask about a new employee on day one. Who is this? What can it touch? When does its access lapse? If it goes wrong at 2am, who turns it off, and how fast?
For a person, those answers are routine. There is a joiner-mover-leaver process, a manager, a role, a credential that expires, an account that gets disabled when they walk out the door. For a static script, the answers differ but are still tractable: it runs on a schedule, under a service account, doing one known thing, and a change to it goes through a pipeline somebody reviews.
An autonomous agent is neither.
It is not a person, so the human identity machinery does not quite fit. It is not a static script, because it decides what to do next, calls services no human approved in that moment, chains across systems, and can run for hours on a goal rather than a fixed instruction. It sits in the gap between the two, and that gap is where most enterprise security models have no vocabulary.
That gap is the work of D9, AI Security and Identity, in the framework. This dimension is easy to flatten into a cybersecurity checklist with the word “AI” stapled on. The security baseline still matters — an agent runs on infrastructure, and patching, hardening, and access control do not stop mattering because something autonomous now sits on top. But the distinctive problem of D9 is not the baseline. It is that the enterprise has introduced a new class of actor that acts with intent, holds credentials, and reasons its way into systems, and the identity fabric was built for humans and machines, not for things that improvise.
So the differentiator in this dimension is D9.1: agent identity. Not “do we have IAM” — almost everyone does. The question is whether every autonomous agent in the estate has an identity distinct from the human who launched it and from the platform it runs on; whether that identity carries a known owner, a known purpose, a known criticality tier, and a known lifecycle; and whether the enterprise can enumerate its agents the way it can enumerate its people. An agent that borrows a developer’s credentials, or runs under a shared service principal that three other workloads also use, does not have an identity. It has a disguise.
This matters because every other control in D9 depends on it. You cannot scope access for an actor you cannot name, expire a credential you cannot attribute, or revoke something you cannot distinguish from everything else using the same key. When an incident review asks “what did the agent touch”, the honest answer in an immature estate is often “we can see what the service account touched, but several things share it, so we are inferring.” Inference is not evidence. The non-human identity problem is the foundation, and it is the part most 2026 estates have not actually solved — they have a model, a platform, and a use case, and an identity story that quietly resolves to “it runs as us.”
I am deliberately not going to draft the cryptography here. The cryptographic-services and identity-engineering teams determine credential type, key management, rotation mechanics, workload-identity federation, and quantum-readiness positioning. That is specialist work, and an operating-model essay that tried to itemise it would be both wrong and presumptuous. The operating-model question is the one I can stand behind: does the identity, credential, and access design support the blast-radius constraints that D5 set for this agent’s autonomy level, and can the people who run security actually consume that design when something goes wrong?
D9.2 is where identity becomes consequence: agent-to-API access control. An autonomous agent is, functionally, a thing that calls APIs. Its power is exactly the set of scopes it can reach. The maturity signal is least-privilege that is real rather than aspirational — access granted per task and per agent, scoped to what the use case needs, with permissions that are just-in-time rather than standing where the risk warrants it. A standing, broad credential held by an agent that runs unattended is the agentic-era equivalent of a shared admin password: convenient, and the thing the incident report will be about.
The harder discipline is expiry and revocation, and they are different problems. Expiry is a clock: the credential lapses on its own, so a forgotten agent does not retain live access for a year. Revocation is a switch: a human, or a control, can withdraw an agent’s access while it is still running, and that withdrawal takes effect quickly enough to matter. An estate that can grant access beautifully but cannot answer “how do we turn this one off, right now, mid-task, and confirm it is off” has built an accelerator with no brake. The identity-engineering team determines the mechanism. The operating-model question is whether the brake exists, whether it has been tested, and whether the test is recent.
D9.3 is the threat the technology actually brought with it: prompt injection and jailbreak defences. This is genuinely new in a way most AI security risk is not. A model that takes instructions in natural language, and reads untrusted content — a web page, an email, a document, a tool result — cannot fully separate the content it is reasoning about from instructions hidden inside that content. An attacker who can get text in front of the model can attempt to redirect it. When the model is also an agent with credentials and API access, a successful injection is not a clever party trick. It is an actor with the agent’s permissions doing the attacker’s bidding.
There is no single setting that makes prompt injection go away, and anyone who tells a board otherwise is selling something. The security and platform teams determine the specific defences — input handling, privilege separation between the reasoning layer and the action layer, constraining what an agent can do with untrusted content, monitoring for anomalous tool use. The operating-model question is whether the enterprise has treated injection as a first-class threat tied to the agent’s access — so the blast radius of a compromised agent is bounded by D9.2’s scopes, not by the model’s good behaviour — and whether that thinking happened before the agent went live, not after the first odd transcript.
D9.4 is the other side of the same coin: model and data exfiltration controls. Agents are connected to data by design; that is most of their value. The risk is that the same connectivity that lets an agent answer from the corporate knowledge base also lets it move sensitive information somewhere it should not go — into a prompt sent to an external model, a tool call that leaves the perimeter, or an output channel a wider audience can read. This is where D9 meets the privacy obligations D7 owns and the vendor-boundary questions D8 owns. APP 11 of the Privacy Act 1988 sets the obligation to protect personal information the entity holds; privacy counsel determines what that requires for a given dataset and flow. The operating-model question is whether the agent’s data paths are mapped, whether sensitive egress is controlled rather than assumed-benign, and whether the controls hold when an agent does something its designers did not anticipate.
D9.5 is the baseline that holds the rest up: security baseline alignment. An agent estate does not get to opt out of the disciplines the rest of the technology estate lives by. The recognised reference points are familiar — the ASD Essential Eight as the Australian baseline, ISO/IEC 27001 for the information-security management system, the NIST AI RMF and its generative-AI profile as a global benchmark for AI-specific risk. None of these is an Australian legal mandate in itself; they are baselines and benchmarks the security function adopts. The maturity signal is not that the organisation can name them. It is whether the agent estate is actually inside the baseline — under the same hardening, monitoring, and control expectations — rather than living as an exciting exception the security review has not caught up with.
Australia gives this dimension its sharpest anchor in APRA CPS 234, the information-security standard, in force since 2019 for APRA-regulated entities. CPS 234 is not an operational-resilience standard — that is CPS 230, which lives next door in D10 — and it is not an AI law. It is the standard under which the board is responsible for the information security of the entity’s information assets, including those managed by related parties and third parties, with requirements around capability, controls, testing, and incident response for security events. It matters here because an autonomous agent with credentials and API access is an information asset that acts, and a thing that acts is a new kind of attack surface and a new kind of insider. Specialist regulatory counsel determines the entity-specific obligations and notification timing; there is no AI-specific Australian notification scheme as at 2026, and AI-related security incidents map onto the schemes that already exist where their preconditions are met. The operating-model obligation is to make the agent estate visible enough — its identities, its scopes, its data paths — that the people accountable under CPS 234 can govern it as the information-security exposure it is.
This is also where “integrate into existing committees” becomes too soft unless it is coupled with hard accountability. Agent security cannot float as a special project. It belongs in the security governance the enterprise already runs — but belonging is not the same as being owned. The accountable outcome is that someone with authority owns the agent identity register, sets and enforces the access and expiry standards, holds the revocation capability, and gates new agents into production against a security bar. That accountability can sit with a CISO as the natural primary, with an extended CIO or CTO mandate, with a security-and-risk executive forum operating under a three-lines model, or with CEO-direct sponsorship where the agent program is strategically central. The framework requires the named owner, the decision rights, and the gate, not a particular title. What it does not tolerate is an estate where every team can launch an agent and no single accountable person can say which agents exist, what they can reach, and how to stop them.
The L4 buyer question for D9 is deliberately unforgiving: pick one autonomous agent currently running in production, and show — for that same agent, as live evidence in the same quarter — its distinct identity and named owner, the scoped and time-bound credential it actually holds, the just-in-time or least-privilege access it was granted for its task, the revocation path with a dated test that proves it can be turned off mid-run, the exfiltration controls on its data paths, and its place inside the security baseline. Then show what changed the last time one of those controls failed.
Single-agent selection matters, because an estate will otherwise present its one well-governed flagship agent and imply the rest are the same. Live evidence in one quarter matters, because identity, access, and revocation assembled from different time periods is a story, not a control. The dated revocation test matters most of all, because the difference between a governed agent and an ungoverned one is rarely visible while everything is working. It is visible at the moment someone needs to pull the credential, and either can, or discovers they cannot.
The Responsible and Agentic AI Governance pillar keeps returning to a single idea: an enterprise can grant capability without surrendering control, but only if it can still see what it granted. D9 is that idea applied to the most literal surface there is. The agent has an identity or it has a disguise. The credential expires or it lingers. The brake works or it is decorative.
So the test I would actually apply is small and quiet. Walk up to one agent that is running right now and ask it the day-one questions you would ask any new actor with access to your systems. Who are you. What are you allowed to touch. When does that stop. And if I need to, how do I switch you off before you finish. If the estate can answer for that one agent, with evidence, while it is still running, D9 is doing its job. If it cannot, the organisation has not deployed an agent. It has onboarded a stranger and given it a key.