ASD ISM 2134Develop, Maintain and Regularly Verify an AI Agent Register
Keep a single, current record of every AI agent operating in the organisation, and check it regularly against reality so no agent runs unknown or unaccounted for.
Plain language
An AI agent is an AI-driven component that can take actions on its own, such as calling tools, reading and writing data, sending messages or triggering workflows, rather than just answering questions. This control asks the organisation to build a register of those agents, put it into use, keep it up to date as agents are added, changed or retired, and regularly verify that what the register says matches what is actually running. The reason this matters is that agents are easy to create and easy to forget. A developer can wire an agent to a mailbox, a ticketing system or a production database in an afternoon, and a business unit can switch one on inside a SaaS platform without involving IT. Each of those agents holds credentials, has permissions and acts on the organisation's behalf. If nobody has a complete picture of which agents exist, who owns them, what they can access and what they are allowed to do, then nobody can assess the risk they carry, apply security controls to them, or respond properly when one misbehaves or is compromised. The verification part is just as important as the register itself. A list that was accurate six months ago but has drifted from reality gives false confidence. Regular verification means comparing the register against sources of truth (platform consoles, service accounts, API keys, deployment pipelines, cloud tenancy inventories) and correcting the differences, so the register stays something the organisation can actually rely on.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system accessTopic
Artificial intelligence agent register
Official control statement
An AI agent register is developed, implemented, maintained and regularly verified.
Why it matters
Without a maintained and verified AI agent register, agents can operate that nobody in security or IT knows about, often with standing credentials and broad permissions to email, documents, code repositories, customer records or cloud infrastructure. Those unknown agents receive no risk assessment, no hardening, no monitoring and no decommissioning when their purpose ends. If one is manipulated through prompt injection, misconfigured, or has its credentials stolen, the organisation may not be able to identify what it could reach, who is accountable for it, or even that it exists, which slows incident response and can turn a contained problem into a data breach or unauthorised action across systems. Governance, assurance and audit activities also become unreliable because they are working from an incomplete or stale picture of where AI is actually acting on the organisation's behalf.
Operational notes
Day to day, the register works best when it is treated like any other authoritative asset inventory rather than a one-off spreadsheet. Give it a clear owner, agree what a minimum entry looks like (name, purpose, owner, hosting platform or environment, the systems and data it can access, the tools or actions it can invoke, the credentials or service identities it uses, status and dates), and make creating or updating an entry a routine step whenever an agent is built, bought, connected or turned off.
Feed the register from wherever agents actually appear: AI platform consoles, low-code and workflow tools, chat platforms with bot integrations, cloud accounts, code repositories and procurement records. Verification should happen on a set cadence and should be an active reconciliation, not a re-read of the list. Compare the register with those sources, investigate anything running that is not registered, mark anything registered that no longer exists as retired, and record the outcome and any corrections. Track the verification dates and findings over time so the organisation can show that the register has been checked regularly and that drift is being caught and fixed.
Implementation tips
- The cyber security or IT governance lead defines the register's scope and fields: what counts as an AI agent for the organisation (for example, any AI-driven component that can invoke tools, act on systems or data, or trigger workflows autonomously), and the minimum attributes each entry must capture, such as name, purpose, business owner, technical owner, hosting environment, connected systems and data, permitted actions and tools, identities or credentials used, status and last verified date.
- The asset or configuration management team builds the register in a tool the organisation will actually maintain (a CMDB class, an asset management module, or a controlled spreadsheet if nothing else is available), then populates it by sweeping AI platform consoles, workflow and low-code tools, chat bot integrations, cloud tenancies, code repositories and procurement records to capture every agent currently in operation.
- The change and project management functions add a mandatory step to their processes so that anyone deploying, purchasing, connecting or retiring an AI agent must create or update its register entry before the change is approved, with the register owner confirming the entry is complete.
- The register owner schedules regular verification (for example quarterly, or more often where agents change frequently) and performs it as a reconciliation: export the current list of agents, bots, service identities and API keys from each platform, compare them against the register, add any unregistered agents, retire any entries that no longer exist, correct inaccurate details, and record the date, method, findings and fixes.
- The security team assigns a named owner for every entry and, where a platform supports it, sets up automated discovery or alerts for newly created agents, bots or agent service identities so that new agents are flagged for registration between scheduled verifications rather than waiting to be found.
Audit / evidence tips
- AskAsk for the current AI agent register and the document that defines its scope and required fields.Look atCheck that the register exists as a controlled, owned record and that each entry captures enough to understand the agent: purpose, owners, environment, connected systems and data, permitted actions and identities used.GoodA single authoritative register with a named owner, a clear definition of what must be recorded, and entries that are consistently completed rather than partially filled.
- AskAsk how the register was populated when it was first implemented and where new entries come from now.Look atLook for evidence that agents were discovered from real sources (platform consoles, cloud tenancies, workflow tools, code repositories, procurement) and that there is a defined trigger for adding entries when agents are created or acquired.GoodThe register was built from an active sweep of the environment and is fed by change, project and procurement processes, not just by staff remembering to report.
- AskAsk for the verification schedule and the records from the last two or three verification cycles.Look atCheck that verification is a genuine reconciliation against platform exports or inventories, with dates, method, discrepancies found and corrections made, and that cycles occurred at the stated frequency.GoodVerification records show the register was compared with sources of truth on the agreed cadence, unregistered agents and stale entries were identified, and the register was corrected as a result.
- AskPick a sample of agents visible in a platform console, chat bot directory or cloud tenancy and ask to see their register entries; then pick a sample of register entries and ask to see the live agent.Look atCompare the details in both directions: does every live agent have an accurate entry, and does every entry correspond to something that still exists with the recorded owner, access and status?GoodBoth samples match with only minor, recently introduced differences, and any gaps found can be explained by a change that is already in progress.
- AskAsk for evidence of entries that were updated or retired following an agent change or decommissioning.Look atTrace a recent change record or decommissioning ticket for an agent through to the corresponding register update, checking timing and whether the entry reflects the change accurately.GoodRegister updates follow closely behind changes to agents, retired agents are marked as such rather than deleted silently, and the change process shows the register step being completed.
Cross-framework mappings
How ISM-2134 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
E8
| Control | Notes | Details |
|---|---|---|
handshakeSupports(2)expand_less | ||
| E8-PA-ML1.1 | ISM-2134 requires the organisation to keep an AI agent register current and regularly verified against reality | |
| E8-PO-ML1.1 | ISM-2134 requires a maintained and regularly verified AI agent register | |
ISO 42001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| Annex A 4.2 | ISM-2134 requires the organisation to develop, maintain and regularly verify a complete register of all AI agents in operation | |
handshakeSupports(2)expand_less | ||
| Annex A 4.3 | ISM-2134 requires a current, verified register of every AI agent operating in the organisation | |
| Annex A 4.4 | ISM-2134 requires the organisation to maintain and regularly verify an AI agent register so no AI agent operates unknown or unaccounted for | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System access
See all Guidelines for system access controls, or browse the full ASD ISM library.