The Australian Signals Directorate published the September 2026 Information Security Manual on cyber.gov.au. The changes PDF is ten pages. Most of the new ink is about things teams are already running: agents with tools, OAuth apps staff click through, vendor remote access, and backups ransomware can still delete.
June 2026 put AI applications into the ISM. September treats agents as principals. Each agent gets its own identity, a register, least privilege, untrusted retrieval, logged tool calls, and a human in the loop before a sensitive action runs. For IRAP assessors, that is written treatment of technology that already sat in systems with no mitigation text. For the teams who build those systems, it is a bar.
Quick answer
Stand up a verified AI agent register this week. Give every agent an identity that is not a person. Hold each agent to the smaller of the invoking user’s rights and a task-scoped grant. Treat anything an agent retrieves as untrusted input. Require a human before a payment, account change, or other high-impact tool runs. Log every tool call. Then tighten OAuth consent, vendor remote access, immutable backups, and the six-month KRBTGT / DCSync / pen-test clock. The official list is on cyber.gov.au. This page is the implementation order and the gaps we would still have to invent on a build.
Best for: platform, security, and AI-engineering leads on Australian government, IRAP-bound, or Essential Eight programmes who already have agents or Copilot-class tools in production. Honest limit: Cipher Projects is not an IRAP assessor and this page is not a substitute for the ISM. We prepare systems and evidence. An independent assessor still has to judge them.
Last updated: 7 September 2026. Cipher Projects is an Australian-led engineering studio. We come from cloud and security first, then AI. We evaluate agent sandboxes and the backends those agents sit on.
What changed in the September 2026 ISM?
ASD added a block of new controls from ISM-2124 to ISM-2167, tightened several existing ones, rescinded the IPv6-disable control, and started saying “human users” wherever the old text said “users.” That last edit is the conceptual shift. Agents are no longer a kind of user. They are a different kind of principal.
Control IDs below are from the official ISM September 2026 changes PDF. Use that file as the source of truth if wording drifts.
| Theme | What landed | Control IDs |
|---|---|---|
| Agentic AI | Unique agent identity, a verified register, least privilege, dual authorisation on tools, untrusted retrieval, logged tool calls, human approval before sensitive actions | ISM-2133 to 2135, 2156 to 2159, 2113 |
| Identity and credentials | Short-lived workload credentials, secrets management, unique creds per environment, device-bound tokens, session revoke on risk, KRBTGT and DCSync reviews every six months | ISM-2141 to 2148, 1847, 1934, 1593 |
| OAuth and device code | Consent only by an authorised administrator, six-monthly permission review, central logs, device-code flow off unless required | ISM-2137 to 2140 |
| Service-provider access | Approved tools, source addresses and time windows; independent logs the vendor cannot edit; unauthorised access treated as an incident | ISM-2124, 2125, 1576 |
| Windows hardening | Driver signature enforcement, kernel-mode code limited to privileged users, central WMI logging including permanent event subscriptions | ISM-2127 to 2129 |
| AD Certificate Services | Web enrolment off unless required (HTTPS + EPA if on), quarterly template review, central enrolment logging | ISM-2130 to 2132 |
| Backups | Technically enforced immutability for the retention period; backup infrastructure segregated, with separate admin authentication | ISM-2151, 2152 |
| Networking | Management interfaces on a dedicated segregated network; firmware and config checked against a known-good baseline; MACsec added as an ASD-approved protocol | ISM-2160 to 2167, 2161, 2162 |
| Software development | Dependencies pinned to approved versions, commit-time secret and credential scanning, reproducible builds | ISM-2154, 2030, 2155 |
| Synthetic impersonation | Staff who change accounts, banking details, or payments must verify the requestor on a pre-established channel | ISM-2126 |
| Assurance cadence | Threat hunting every three months; vulnerability assessments and penetration tests every six months after go-live | ISM-2153, 2118 |
| Incident response | Remediation on trusted systems separate from the compromised one; sequenced recovery; enhanced monitoring until you have evidence the actor is gone, not a fixed seven-day capture | ISM-1731, 1732, 1213 |
ASD also added risk-based access informed by contextual signals (ISM-2136), an allow-list for remote monitoring and management tools with unauthorised RMM blocked at the gateway (ISM-2149, 2150), and it rescinded ISM-0521, which told operators to disable IPv6 on dual-stack devices unless they were using it.
What do the new agentic AI controls actually require?
Five build jobs, plus a wording change on human approval. If you already ship production agents, you have been doing versions of these without a control number. September writes the number.
| Job | ISM says | What that looks like in a real stack |
|---|---|---|
| Identity | Each AI agent gets a unique identity, distinct from personnel and from other agents (ISM-2133) | A non-human principal in Entra ID, IAM, or your IdP. Not the developer’s laptop account. Not one “chatbot” service user shared by five workflows. |
| Register | Develop, implement, maintain, and regularly verify an AI agent register (ISM-2134). Each row needs a unique identifier, owner, business purpose, identities, accounts and credentials, and the tools, permissions, and data it can reach (ISM-2135) | The same evidence problem as a shadow-AI inventory, scoped to things that can call a tool. A spreadsheet is fine on day one. A row that says “ChatGPT” and nothing else is not. |
| Least privilege | Restrict agentic apps to the minimum tools and permissions for the intended purpose (ISM-2156). Tool calls sit under both the invoking user’s access controls and an agent-specific, task-scoped grant; the effective permission is the minimum of both (ISM-2157) | An agent that files a leave request as Alice cannot inherit Alice’s SAP admin role. The tool server must intersect “what Alice may do” with “what this agent is allowed to do on this task.” |
| Untrusted retrieval | External content an agent retrieves stays untrusted after validation. It must be delimited from system instructions and must not override instructions, policies, access controls, tool permissions, or human-approval rules (ISM-2158) | This is the prompt-injection control without using the words. A web page, ticket, email, or PDF the agent fetched cannot become a new system prompt. Delimit it. Sanitise it the way you sanitise any other untrusted input. Keep it untrusted after you do. |
| Logging | Centrally log every tool invocation, external request, and output, in enough detail to investigate an incident (ISM-2159) | Who invoked, which agent identity, which tool, which arguments, what came back, whether a human approved it. If you cannot reconstruct a payment from the log, the control is not met. |
| Human approval | June’s ISM-2113 said flag risky actions for approval. September says require human approval before executing sensitive or high-impact actions | A banner is not a control. The tool must not run until a named person approves it. Define “sensitive” in writing: payments, account or bank-detail changes, production writes, identity changes, outbound email to customers. |
June already asked AI apps that process classified data to cut external public sources (ISM-2112), to keep behavioural baselines (ISM-2114), and to delete chat prompts and outputs when a session is removed (ISM-2123). September does not replace those. It adds the identity and tool-use layer those controls never specified.
The May 2026 joint publication Careful adoption of agentic AI services (ASD with CISA, NSA, Cyber Centre, NCSC-NZ, and NCSC-UK) already told operators to treat each agent as a distinct cryptographic principal and to keep a trusted registry. September is the first time those ideas have ISM numbers. That is why assessors can now write a finding against a missing register instead of arguing from guidance.
How do you stand up an AI agent register this week?
Open a sheet. Hunt SSO apps, expense merchants, API keys, n8n or Zapier workflows, Copilot Studio agents, internal MCP servers, and any CI job that can call a model and then call a tool. One row per agent that can take an action, not per vendor logo.
Fill the ISM-2135 fields first. Then add the two columns assessors will ask for anyway:
| Field | Why it exists |
|---|---|
| Unique identifier | ISM-2133 / 2135. If two agents share a name, you cannot revoke one. |
| Owner and business purpose | A named human, not “IT.” Purpose in one sentence. |
| Identities assigned | The non-human principal. If this cell is a person’s UPN, the identity control has failed. |
| Accounts and credentials it uses | Secrets, tokens, certificates. Point at the vault path, not a password. |
| Tools, permissions, data it can reach | The blast radius. Include MCP servers, mail, ticketing, ERP, and the package registry. |
| Human-approval gate (add this) | Which actions block until a person says yes. Empty means ISM-2113 is unmet. |
| Last verified (add this) | ISM-2134 says regularly verified. Pick a date. Monthly is a sane default until you have a better one. |
The row people miss is the coding agent in CI that can push to the registry production pulls from. That is the same blast radius we walked after CVE-2026-82329. If it can write, it is an agent. Put it on the register.
Do not put “Microsoft Copilot” as one row and stop. Copilot in Word, a Copilot Studio agent with a SharePoint connector, and a plugin that can send mail are three different principals if they can do three different things. If the vendor will not give you a non-human identity, write that as a gap. That gap is one of the controls still missing, below.
What else landed besides agents?
The rest of the pack is the identity and recovery work that agents make more urgent. An agent with a long-lived secret is a stolen-credential incident waiting for a prompt.
Identity, tokens, and OAuth
Applications and workloads should use short-lived, dynamically issued credentials instead of long-lived static ones (ISM-2141). Static credentials that remain go in a secrets manager (ISM-2142), stay unique per app and per environment (ISM-2143), and get revoked when they are compromised, found in the clear, or no longer needed (ISM-2144, 2146). Authentication tokens, session cookies, and refresh tokens should be cryptographically bound to the device that received them (ISM-2147), and sessions should die when credentials reset, a device falls out of compliance, or a high-risk sign-in appears (ISM-2148).
OAuth is no longer a staff self-service problem. Humans must not grant consent to third-party OAuth apps; only an authorised administrator may (ISM-2137). Review those grants every six months and revoke unused or excessive scopes (ISM-2138). Log consent, token issuance, and token use (ISM-2139). Turn the device-code flow off unless you need it, and then restrict it to authorised accounts on managed devices (ISM-2140). Device-code is how a lot of CLI and TV-style logins work. Leaving it open is how a phishing page on another device finishes a login that started on yours.
KRBTGT credentials and reviews of accounts with DCSync permissions both move from annual to every six months (ISM-1847, 1934). Microsoft’s own KRBTGT rotation is a two-reset sequence. The ISM now sets the clock. It does not write the runbook.
Vendors, RMM, and backups
Service-provider access is limited to remote-management tools, source addresses, and time windows you explicitly approved (ISM-2124). You log that access in a store the vendor cannot modify or delete, and you read the logs in time to notice abuse (ISM-2125). Unauthorised vendor access is a cyber security incident, not a ticket (ISM-1576). Pair that with an allow-list of RMM and remote-access tools, and block the rest at the gateway (ISM-2149, 2150).
Backups need a technically enforced immutability mechanism for the whole retention period (ISM-2151). A policy that says “please do not delete” is not the control. Backup servers, repositories, and consoles sit off the production estate and use a separate admin authentication path (ISM-2152). If ransomware can reach the backup admin console with the same Entra group as production, the new control is already failed.
AD CS, Windows, and the network
AD CS web enrolment is off unless required; if it stays on, it needs HTTPS and Extended Protection for Authentication (ISM-2130). Review certificate templates every three months for escalation paths (ISM-2131). Log enrolment successes, failures, and template or configuration changes (ISM-2132). On the host: enforce driver signatures before load (ISM-2127), limit kernel-mode installs to people whose job needs them (ISM-2128), and centrally log WMI, including permanent event subscriptions (ISM-2129).
Networked management interfaces are reachable only from a dedicated management network, segregated from the wider LAN and the internet (ISM-2160). Verify device firmware and running config against a known-good baseline after patching, on odd behaviour, and at least monthly (ISM-2161). Disable unused device features (ISM-2162). MACsec is now an ASD-approved protocol, with confidentiality mode, AES-GCM (256 preferred), CAK lifetime under 24 hours, SA lifetime under four hours, fresh EAP-TLS when a new CAK is needed, and pre-shared-key fallback disabled (ISM-2163 to 2167).
How software is built, and how people are tricked
Pin dependencies to approved versions in source (ISM-2154). Scan commits for secrets, keys, and now credentials (ISM-2030). Build so an independent party can prove the release artefact came from the stated source (ISM-2155). That last one is reproducible builds. It is the control that makes “the model wrote this” auditable instead of folkloric. We already treat commit-time scanning as a gate, not a nice-to-have, once coding agents are on the repo.
ISM-2126 is the deepfake control. Before anyone changes a user account, changes banking details, or runs a payment, they must positively identify the requestor on a pre-established authentication method or an independent trusted channel. A voice call that started from the inbound number is not that channel. A call-back to a number already on file is.
Assurance and recovery clocks
Threat hunting, informed by current strategic and sector intelligence, at least every three months (ISM-2153). Vulnerability assessments and penetration tests stay required before go-live and before significant change; the ongoing clock moves from annual to six-monthly (ISM-2118). After an intrusion, plan remediation on trusted systems that are not the compromised one (ISM-1731), sequence the work so the actor cannot walk back in while you recover (ISM-1732), and keep enhanced monitoring until you have evidence they are gone, not for a fixed seven days of packet capture (ISM-1213).
Which ISM controls are still missing?
The register, the unique identity, and ISM-2158 close the gap June left on tool-using agents. They do not close the gap the May 2026 joint guidance already named, and they do not match what we still have to invent when we ship an agent that can reach mail, ERP, or a package registry.
| Gap | Why it matters on a build |
|---|---|
| Agent-to-agent authentication | ISM-2133 gives each agent a name. It does not say how two agents prove who they are. The May 2026 guidance asked for mutual TLS and a registry that denies unknown keys. September never wrote that control. |
| MCP and tool-server hardening | ISM-2156 to 2159 bind the invoking agent. They do not bind the tool server. An internet-facing MCP with a shared secret is still a service you have not identified as an agent, with no ISM row of its own. |
| Revocation SLA | The register exists. Nothing says how fast you must disable an agent identity across every system it can reach. A row in a spreadsheet is not a kill switch. |
| Vendor copilots that only act as the human | ISM-2133 wants an identity distinct from personnel. Most enterprise Copilot, Claude, and ChatGPT seats still act as the signed-in user. The ISM does not say what to record when the vendor will not issue a non-human principal. |
| Red-team of the agent itself | Pen-tests moved to six months. Nothing says the agent must be tested for prompt injection, tool abuse, or data exfil on that same clock. ISM-2119 still talks about using AI to augment a pen-test, not about pen-testing the agent. |
| What the agent writes | Inbound content is untrusted. Outbound mail, tickets, code, and payments have no labelling or destination-restriction control. A poisoned retrieval that fails to override the system prompt can still ask the agent to write a convincing lie to a customer. |
| Model-as-committer | June said software-developer controls apply to AI agents. September pins versions and scans secrets. It still does not say whose identity signs a model-generated commit, or how you treat a pull request the model opened. |
| Evidence format | ISM-2135 lists register fields. It does not require an export, a retention period, or a sampling method an IRAP assessor can repeat. Teams will invent five incompatible sheets and fail the “regularly verified” test in different ways. |
Those are the controls we would still write into a system security plan as organisation-defined mitigations. They are not ASD text. If you are an assessor reading this, that is the difference. We can show you a register and a dual-control tool gateway. We cannot show you an ISM number for killing an agent in ten minutes, or for refusing to speak to an unsigned MCP.
What should a team implement in the next 30 days?
Do the agent and identity work first. AD CS template reviews and MACsec lifetimes can land on the existing hardening backlog. A register you cannot produce is the finding that lands first.
| When | Do this | Controls it hits |
|---|---|---|
| This week | Build the agent register. One row per thing that can call a tool. Give each row a non-human identity, an owner, and a last-verified date. | ISM-2133, 2134, 2135 |
| This week | List every high-impact tool. Payments, bank or account changes, production writes, identity changes, customer email. Those tools do not run until a named person approves. | ISM-2113, 2126 |
| This week | Turn on admin-only OAuth consent. Disable device-code unless a named workload needs it. Pull the current consent grant list and revoke what nobody can explain. | ISM-2137 to 2140 |
| This fortnight | Delimit retrieved content from system instructions. Log tool name, arguments, identity, and approval. Intersect user rights with agent-scoped grants on the tool server. | ISM-2156 to 2159 |
| This fortnight | Move workload secrets into a manager. Prefer short-lived credentials. Split prod from non-prod. Write vendor access windows and log them somewhere the vendor cannot edit. | ISM-2141 to 2146, 2124, 2125 |
| This month | Pin dependencies. Block credential commits. Confirm backups are immutable for the retention period and that backup admin is not the production admin path. | ISM-2154, 2030, 2151, 2152 |
| This quarter | KRBTGT two-reset, DCSync review, AD CS template review, WMI logging, management-plane segregation, threat hunt, book the six-month pen-test. | ISM-1847, 1934, 2130 to 2132, 2129, 2160, 2153, 2118 |
If you only do one thing this week, open the register and list every agent that can call a tool. Give each one a name that is not a person. Then decide which of those tools still run without a human.
FAQ
Does the September 2026 ISM apply if we are not a government agency? The ISM is written for organisations that choose it as their cyber security framework, and it is the control set IRAP assessments use. If you sell into Australian government, defence, or many critical-infrastructure programmes, assessors will look for these controls even if you never opened the PDF. Essential Eight is still the baseline for many boards. The ISM is the deeper book those programmes already pointed at.
We only use ChatGPT or Copilot. Do we need an agent register? If the tool cannot call another system, you still need an AI inventory for governance and for the 10 December 2026 privacy-policy work. The ISM agent register is for things that have tools, permissions, or data stores. The moment Copilot Studio, an n8n workflow, or a coding agent can write to mail, ERP, or a registry, it is an agent. Put it on ISM-2134.
Is a spreadsheet enough for ISM-2134? On week one, yes, if it has the ISM-2135 fields and someone verifies it. By the first IRAP sample, you need a verification date, an owner who will retire a row, and a way to show the live agents match the sheet. A wiki page nobody opened since March will fail “regularly verified.”
What counts as a sensitive or high-impact action under ISM-2113? ASD leaves that to the organisation. Write it down. We treat payments, bank or payroll changes, account or identity changes, production data writes, and outbound customer communications as in-scope until a risk owner takes one off the list in writing.
Did ASD require MACsec everywhere? No. It added MACsec as an approved protocol and then specified how to run it if you use it. The control you cannot skip on the network side is management interfaces confined to a dedicated segregated network, plus integrity checks against a known-good baseline.
Who should implement this for an Australian team? A partner who already does cloud and security, and who has shipped agents with identity, logs, and approval gates. Cipher Projects will map the register, the non-human identities, and the tool gateway under your accounts. We prepare evidence for an assessor. We are not the assessor. Start at Security Engineering or contact.
Related: Can you prove how you govern AI? · AI inventory fields · Claude workflow vs production agent · Artifactory CVE and agent write-paths · Commit-time scanning · Where agent code should run · Security Engineering