Skip to content
System access
ASD ISMISM-2134

ASD ISM 2134 Develop, maintain and regularly verify an AI agent register

What it says

An AI agent register is developed, implemented, maintained and regularly verified.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

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.

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.

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.

How to implement

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Keep it running

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.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the current AI agent register and the document that defines its scope and required fields.

    Look at

    Check 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.

    Good evidence

    A 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.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask how the register was populated when it was first implemented and where new entries come from now.

    Look at

    Look 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.

    Good evidence

    The 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.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the verification schedule and the records from the last two or three verification cycles.

    Look at

    Check 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.

    Good evidence

    Verification 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.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Pick 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 at

    Compare 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?

    Good evidence

    Both samples match with only minor, recently introduced differences, and any gaps found can be explained by a change that is already in progress.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for evidence of entries that were updated or retired following an agent change or decommissioning.

    Look at

    Trace 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.

    Good evidence

    Register 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.

Mappings

Closest match in ISO/IEC 42001: A.4.2, Resource documentation, which partially overlaps with this control.

ISO 42001

ISO/IEC 42001: 4 mappings

  • A.4.2Resource documentationPartially overlaps
  • A.4.3Document the data resources used by your AI systemPartially overlaps
  • A.4.4Document the tooling resources used for AI systemsSupports
  • A.4.5Document system and computing resources used by AI systemsDepends on

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.