ASD ISM 2135 Recording identifier, owner, identities, credentials and access for each AI agent
What it says
An AI agent register contains the following for each AI agent: - its unique identifier - its owner and business purpose - the identities assigned to it - any user accounts and credentials it uses - the tools, permissions and data repositories it can access.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery AI agent gets a register entry that names it, says who owns it and why it exists, and lists the identities, accounts, credentials, tools, permissions and data it can use.
An AI agent is software that acts on its own to complete tasks, often by logging in to systems, calling tools and reading or writing data. Because it behaves like a user with its own access, the organisation needs to know exactly what each one is and what it can touch. This control sets the minimum content of the AI agent register. For every agent, the register must record five things: a unique identifier so the agent can be told apart from every other agent; its owner and the business purpose it serves; the identities assigned to it; any user accounts and credentials it uses; and the tools, permissions and data repositories it can access. Why it matters: without these details, an agent can quietly accumulate access nobody is accountable for. If an agent is compromised, misbehaves or is simply forgotten, the organisation cannot quickly work out which accounts to disable, which credentials to rotate, which data it could have reached, or who to call. A complete register turns an unknown, hard-to-contain risk into something that can be reviewed, reduced and shut off when needed.
Free. Save your status, tasks and notes.
Why it matters
If the register is missing or incomplete, the organisation loses visibility of what its AI agents can do. Orphaned agents keep running with live credentials after their purpose ends, over-privileged agents hold access to tools and data repositories no one approved, and when an agent is compromised or acts unexpectedly there is no fast way to identify its accounts, revoke its credentials or scope what data it could have exposed. Incident response slows, accountability is unclear, and a small agent fault can become a wider data breach.
How to implement
The AI or platform owner defines the register schema with one mandatory field for each item in the statement (unique identifier, owner, business purpose, assigned identities, user accounts and credentials used, and accessible tools, permissions and data repositories) and hosts it in a controlled system such as the CMDB, IAM tool or an access-controlled spreadsheet.
The change or onboarding process owner adds a gate so that no AI agent is deployed until its register entry is created and all fields are populated, and the identifier is generated by the register rather than chosen by the requester so it stays unique.
Each agent's business owner completes and signs off the owner and business purpose fields, and confirms the list of identities, accounts and credentials the agent uses by checking them against the identity provider and secrets store rather than from memory.
The identity and access team records the tools, permissions and data repositories each agent can access by exporting the agent's actual role assignments and integration scopes from the systems concerned, then pasting the result into the register entry so it reflects real access.
The register custodian links register updates to the access-change workflow so that every grant, change or removal of an agent's account, credential, tool, permission or data access automatically triggers an update to that agent's entry, and closes the entry when the agent is decommissioned.
Keep it running
Day to day, the register is a living record rather than a one-off document. A new entry is created when an AI agent is approved, and it is completed with all five fields before the agent goes live: the identifier, the owner and business purpose, the identities assigned, the user accounts and credentials in use, and the tools, permissions and data repositories it can access.
Entries change whenever the agent changes. When an agent is given a new tool, a new permission, a new account or access to another data repository, the register is updated at the same time as the access is granted. When an owner leaves or a purpose changes, the entry is reassigned or amended. When an agent is retired, its entry is marked closed so the accounts and credentials listed against it can be removed.
Credentials themselves are not stored in the register; the register records which accounts and credentials the agent uses (for example the account name and where the secret is held) so they can be found and revoked. Access to the register is limited to those who need it, because it describes exactly how each agent can reach organisational systems.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the AI agent register and a separate list of AI agents currently running in the environment, for example from the AI platform, integration catalogue or identity provider.
Look at
Compare the two lists and check that every running agent has a register entry with a unique identifier that is not shared with any other agent.
Good evidence
Every deployed agent appears in the register exactly once, and there are no agents in the environment that the register does not know about.
- Check 2 of 5What an auditor asks for
Ask for
Ask for a sample of register entries and the names of the people recorded as owners.
Look at
Check that each entry names a current, identifiable owner and states a specific business purpose rather than a generic description.
Good evidence
Owners are real, current staff who confirm they own the agent, and the purpose is specific enough to judge whether the agent's access is appropriate.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the identities assigned to a sampled agent, as recorded in the register, and the corresponding records in the identity provider.
Look at
Check that the identities in the register match those actually assigned to the agent in the identity system, with none missing or extra.
Good evidence
The register and the identity provider agree on exactly which identities the agent holds.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the user accounts and credentials each sampled agent uses, as listed in the register, and evidence from the secrets store or account directory.
Look at
Check that every account and credential the agent uses is listed, and that the register points to where the credential is managed rather than containing the secret itself.
Good evidence
All accounts and credentials in use are recorded and traceable to their managed location, so they could be found and revoked quickly.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the tools, permissions and data repositories recorded for a sampled agent, plus the agent's actual role assignments, API scopes and data access from the systems it connects to.
Look at
Check that the register reflects the agent's real access and that the entry has been updated when access changed.
Good evidence
The recorded tools, permissions and data repositories match the live configuration, and change history shows the entry is kept current.
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-2135 requires maintaining an AI agent register that records identifiers, ownership, assigned identities, credentials, and the tools/permissions/data repositories each agent can access. Annex A 5.15 requires establishing access control policies for physical and logical access based on business and security requirements. ISM-2135 is a specific record-keeping mechanism within the broader access control policy framework of Annex A 5.15.
This control partially overlaps A.5.17.
ISM-2135 mandates documenting user accounts and credentials an AI agent uses, alongside identities. Annex A 5.17 requires managing authentication information securely, involving proper handling. They overlap on managing authentication information for non-human actors, with ISM-2135 focused on register completeness and Annex A 5.17 on secure lifecycle management of authentication secrets.
This control supports A.5.18.
ISM-2135 requires recording identities, accounts, credentials, and access scope for each AI agent. Annex A 5.18 requires provision, review, modification and removal of access rights per access control rules. The ISM-2135 register offers the necessary inventory for reviewing and governing an agent's access rights lifecycle, although it does not itself mandate the provisioning processes.
ISO/IEC 42001: 3 mappings
This control partially meets A.4.2.
ISM-2135 requires an AI agent register entry that records identifiers, owner, assigned identities, credentials, and the tools/permissions/data repositories it can access. Annex A 4.2 requires documenting resources needed for AI lifecycle stages, including identities, tools, and data resources underpinning AI agents. ISM-2135 is a more specific, security-focused resource documentation targeting AI agents' access footprints.
This control partially overlaps A.4.3.
ISM-2135 requires an AI agent register entry listing data repositories accessible to each AI agent. Annex A 4.3 requires documenting the data resources used for AI systems, identifying repositories within scope for access recording. Annex A 4.3 involves broader data-resource documentation, whereas ISM-2135 links specific agents to data repositories and permissions in a security context.
This control partially overlaps A.4.4.
ISM-2135 requires an AI agent register entry listing the user accounts/credentials used by the agent and the tools it can access. Annex A 4.4 involves documenting tooling resources for AI systems, which helps organisations systematically identify tools for recording and governance. While Annex A 4.4 focuses on inventorying tooling resources generally, ISM-2135 applies that information to agent-level identity and access traceability.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.