ASD ISM 2133 Assign each AI agent a unique identity distinct from personnel accounts
What it says
Each AI agent is assigned a unique identity that is distinct from the user accounts of personnel and the identities of other AI agents.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery AI agent gets its own identity. It must never run under a person's user account or share an identity with another AI agent, so its actions can be told apart from everyone else's.
An AI agent is software that acts on its own to carry out tasks, such as reading mailboxes, calling APIs, running scripts or updating records. To do any of that it needs to authenticate to systems, and whatever identity it authenticates with is the identity that logs, access controls and investigators will see. This control says each AI agent must have its own identity, and that identity must be separate in two directions. First, it must not be a person's user account: an agent should never log in as the developer who set it up, the administrator who owns the platform or the staff member it is working for. Second, it must not be shared with any other AI agent: two agents should never run under one service account or one API credential. Why it matters: when an agent borrows a person's account, everything it does looks like that person did it, the person's access becomes the agent's access, and revoking or investigating the agent means disrupting the human. When several agents share one identity, you cannot tell which agent performed an action, cannot scope permissions to what each one actually needs, and cannot switch off one misbehaving agent without switching off the rest. A distinct identity per agent is the foundation that makes least privilege, monitoring and incident response possible for AI agents at all.
Free. Save your status, tasks and notes.
Why it matters
If AI agents run under personnel accounts or shared identities, actions cannot be reliably attributed to the agent that took them, so suspicious activity may be blamed on a staff member or go unexplained. Agents inherit whatever access the borrowed account holds, which is usually far more than they need, and a compromised or malfunctioning agent then has that full reach. One agent cannot be disabled, rate-limited or investigated without affecting the person or the other agents sharing the identity, slowing incident response and making it hard to demonstrate accountability to auditors or regulators.
How to implement
Identity and access administrators create a dedicated identity (service account, workload identity or equivalent) for every AI agent at provisioning time, using a naming convention that marks it clearly as an AI agent and identifies which agent it is.
Platform and engineering teams configure each AI agent to authenticate with its own credentials only, removing any embedded personal usernames, personal API keys or shared tokens from agent configuration, code and secrets stores.
The security team writes and enforces a policy rule that AI agents must not run under personnel user accounts and must not share an identity with another agent, and adds this check to the approval gate for deploying any new agent.
The AI platform owner reconciles the identities observed in authentication logs each quarter against the known set of AI agents to find any agent using a personal or shared identity, and moves each one found onto its own dedicated identity.
Identity administrators confirm, before issuing an identity to any new or replacement AI agent, that the identity is not already assigned to another agent and is not a personnel user account, so that every agent's identity remains unique at the point of creation.
Keep it running
Treat the creation of a new AI agent identity as a standard step in onboarding any agent, in the same way a new staff member or new service gets an account. Nobody should be able to stand up an agent using their own credentials "just for now".
Periodically compare the identities that are actually authenticating to your systems with the AI agents you know about, so that agents reusing a person's credentials, or two agents sharing one identity, are caught. An AI agent register, which separate ISM controls cover, is a convenient source for that comparison, but the check this control cares about is that each identity belongs to exactly one agent and to no member of personnel.
Identity naming should make it obvious that the principal is an AI agent and which agent it is, so that log reviewers and administrators are not left guessing. When an agent is decommissioned, retire its identity rather than reassigning it to a different agent, so historical records stay unambiguous.
Expect this to touch several teams: the identity and access team who provision identities, the platform or engineering team who build and deploy agents, and the security operations team who consume the logs. Agree where agent identities live (directory, cloud IAM, API gateway, AI platform) so there is one authoritative source.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register or inventory of AI agents in use, including the identity each agent authenticates with and the owner responsible for it.
Look at
Compare the identity column across agents and against the staff directory to see whether any entry is a person's user account or is listed against more than one agent.
Good evidence
Every agent has exactly one identity, no identity appears against two agents, and none of the identities belongs to a member of personnel.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the policy or standard that governs how AI agents are provisioned and authenticated.
Look at
Check whether it explicitly requires a unique identity per agent and prohibits using personnel accounts or sharing identities between agents.
Good evidence
The requirement is written down, approved, and referenced by the agent deployment or change process so it is applied before an agent goes live.
- Check 3 of 5What an auditor asks for
Ask for
Ask to see the configuration or secrets for a sample of deployed AI agents.
Look at
Look at the credentials the agent actually uses to connect to systems and whether they belong to the agent's own identity rather than a developer, administrator or another agent.
Good evidence
Each sampled agent authenticates with its own dedicated credentials and no personal or shared credentials are present in its configuration.
- Check 4 of 5What an auditor asks for
Ask for
Ask for authentication or activity logs from a system that AI agents interact with, covering a recent period.
Look at
Trace agent activity back to the identity that performed it and check whether it maps to a single named agent rather than a staff member or a generic shared principal.
Good evidence
Agent actions are attributed to distinct agent identities in the logs, and reviewers can say which agent did what without further investigation.
- Check 5 of 5What an auditor asks for
Ask for
Ask for records of recent AI agent onboarding, such as tickets or change requests.
Look at
Check that a new identity was created for each new agent and that it was not a personnel user account or an identity already in use by another agent.
Good evidence
Provisioning records show one new, distinct identity per new agent, with no new agent placed on a person's account or on an identity another agent already uses.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.15.
ISM-2133 mandates a specific access-control design rule: every AI agent must have a distinct identity, separated from personnel and other agents for accountability. ISO/IEC 27001:2022 Annex A 5.15 requires an organisation to establish and implement access control rules and procedures based on business and security requirements, including how identities are used in access decisions. ISM-2133 fits as a concrete policy rule under the broader access control policy framework required by Annex A 5.15.
This control partially meets A.5.16.
ISM-2133 requires each AI agent to be issued its own unique identity that is not a personnel account and not shared with other agents. ISO/IEC 27001:2022 Annex A 5.16 (Identity life cycle management) requires managing identities across their full life cycle, including creation, changes, suspension, and removal for all identity types (human and non-human). ISM-2133 is a prescriptive constraint within the broader identity governance processes expected by Annex A 5.16.
This control supports A.5.18.
ISM-2133 requires a unique identity per AI agent so access and actions can be attributed to the correct non-human actor. ISO/IEC 27001:2022 Annex A 5.18 governs provisioning, review, modification, and removal of access rights in line with access control rules. Unique per-agent identities under ISM-2133 make Annex A 5.18 practically enforceable for agents (rights can be granted/revoked per agent rather than via shared or human accounts), but Annex A 5.18 does not itself require identity uniqueness.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML1.2.
ISM-2133 requires AI agents to use unique identities that are not personnel accounts and are not shared across agents. ASD Essential Eight E8-RA-ML1.2 requires privileged users to have dedicated privileged accounts for admin tasks, enforcing separation between identities used for different purposes to improve accountability and reduce misuse. Both controls implement an anti-sharing/separation principle for traceability, but E8-RA-ML1.2 is focused on human privileged administration rather than non-human agent identity uniqueness.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.