Do You Need a Register of the AI Agents Running in Your Business?

Detailed Explanation

Most small businesses running AI-connected automation have never had to think about "agent identity" as a distinct concept — a workflow either runs or it doesn't, and whoever set it up is assumed to be responsible for it. The Australian Signals Directorate's Information Security Manual update in September 2026 is the first widely visible sign that this assumption is starting to look thin, at least at the level of formal guidance. It doesn't change the law for private business. It does show, in specific and fairly detailed terms, what "good" is starting to look like for anyone whose AI tools can act rather than just talk.

The ISM is published and maintained by the Australian Signals Directorate for Australian government agencies and their contractors — it has no direct legal force over an ordinary private business. What makes it relevant beyond government is that IRAP assessments (the formal process used to check government and defence suppliers' security posture) test against ISM controls, so any business selling into government, defence, or critical infrastructure programs should expect assessors to start looking for exactly what this update describes. For everyone else, it's an early, credible reference point for what "properly governed AI agents" means in practice — worth building toward before it becomes a customer's checklist item, not after.

What the September 2026 Update Actually Added

Five new controls address AI agents specifically:

• Agent identity (ISM-2133): each AI agent should have a unique identity, distinct from personnel accounts and from other agents — not a shared service account, and not the credentials of whoever built the automation.
• The register requirement (ISM-2134): an AI agent register should be developed, implemented, maintained, and regularly verified — not built once and left to go stale.
• What the register should contain (ISM-2135): for each agent — its unique identifier, its owner and business purpose, the identities assigned to it, any user accounts and credentials it uses, and the tools, permissions, and data repositories it can access.
• Risk-based access decisions (ISM-2136): access decisions for agents should be informed by contextual signals, not fixed permissions granted once and never reassessed.
• Restricting who can grant third-party access (ISM-2137): individual users shouldn't be able to grant consent to third-party integrations on the organisation's behalf — only an authorised administrator should be able to approve that.

Alongside these, an existing control on human approval — ISM-2113 — was tightened in the same release: from flagging organisation-defined "risky actions" for human sign-off, to requiring human approval before any sensitive or high-impact action executes. Read together, the direction is consistent: know exactly what each agent is, know exactly what it can touch, and don't let it act unsupervised on anything that matters.

Building One Without Overbuilding It

For a small or mid-sized Australian business, a genuinely useful version of this register doesn't need enterprise identity-management tooling to start. A spreadsheet with one row per agent — its name, what business process it handles, who owns it, what system credentials or connections it uses, and what it's allowed to touch — captures the substance of ISM-2134 and ISM-2135 well enough to be useful and to show someone who asks. The harder part, in practice, is the same obstacle every register runs into: most businesses don't have a complete list of what's actually running until they go and look — an n8n workflow set up eighteen months ago and forgotten, a Copilot Studio agent a departed staff member built, a Zapier automation nobody remembers approving.

A managed automation provider typically already keeps exactly this kind of record as a normal part of running the workflow. See what records a Glivent workflow can keep for review and audit — which is a natural reason this register tends to be more complete for outsourced automation than for internally built tools nobody's tracking centrally.

Things to Consider

• Voluntary today doesn't mean irrelevant today. Government-facing supply chains move guidance into contract requirements faster than into legislation — a business that waits for a legal mandate before starting this work is usually starting later than its competitors already bidding into those markets.
• The identity requirement is the part most businesses skip first. It's easy to build a list of agents; it's much less common to give each one its own credentials rather than sharing a builder's login or a generic service account — but shared credentials are exactly what makes it impossible to answer "which agent did this" after something goes wrong.
• This overlaps directly with blast-radius thinking. What can go wrong when an AI agent can take real actions covers the failure modes this register exists to make visible and contain — the register is the inventory; that page is the risk analysis that should inform what each row is allowed to do.
• Review cadence matters as much as the initial build. ISM-2134 explicitly calls for the register to be "regularly verified," not just created once — a stale agent register that still lists a decommissioned workflow is nearly as misleading as having none.

Common Mistakes

• Confusing this with a general software or AI-tool inventory. A register of "AI tools we use" and a register of "AI agents that can act on our systems" overlap but aren't the same document — see the differentiation in the FAQ below before merging them carelessly.
• Treating "voluntary" as "safe to ignore." For a business with any government, defence, or critical-infrastructure customers on the horizon, this is a checklist item in the making, not a curiosity — worth acting on before a tender response forces the timeline.
• Giving every agent the same broad credentials to save setup time. It's faster in the short term and is precisely the pattern ISM-2133 and ISM-2136 are written to close — a compromised or misbehaving agent with shared, broad access can do far more damage than one scoped tightly to its actual job.
• Building the register and never updating it. An agent register frozen at the moment it was created stops reflecting reality within months, as workflows get modified, replaced, or quietly retired — treat it as a living document with an owner, not a one-off compliance artefact.