Australia ISM agent controls: who authorises the tool call?

ASD has published two September 2026 documents that, read together, turn "govern your AI agents" into a concrete control list. This is technical commentary and general information, not legal advice.

Two documents, two jobs

On 3 September 2026, ASD's Information Security Manual guidance on system access landed with agent-specific controls: each AI agent gets an identity distinct from people and from other agents, organisations maintain and regularly verify an agent register, and tools are limited to the minimum needed.

The companion software-development guidance adds the dual-authority test: every tool call passes two checks — the invoking user's access, and the agent's task-scoped authority. The effective permission is the narrower of the two. Tool invocations, external requests and outputs are centrally logged.

On 11 September 2026, ASD published a separate guide on agentic AI harnesses — the software layer around the model. Its core point: some risks, including prompt injection, cannot be reliably addressed within the model alone, and require controls across the harness, connected systems and governance processes. The harness is the component organisations can most directly govern.

Note the distinction: the ISM pages (3 September) and the harness guide (11 September) are separate instruments with separate jobs. Don't collapse them into one publication or one control set.

Guidance, not law

The ISM is ASD cyber-security guidance, not a general Australian AI law. ASD says an organisation is not required as a matter of law to comply with the ISM unless legislation or another lawful authority compels it. Applicability, risk assessment, control implementation, system authorisation and incident response remain the customer's own work. General information only — talk to qualified advisers about your circumstances.

An illustrative scenario

A procurement assistant reads an untrusted supplier email suggesting a change to a purchase order. Hypothetical, not a reported incident. The email is data, not an authority grant. The question is whether the proposed action survives a defined policy check before the side effect happens.

A separate isolated test

We ran one check against the real HaltState policy engine, in isolation, against an immutable source commit (73dfe7ed) with authored in-memory policy fixtures — no production systems, no customer data:

• A synthetic purchase_order.change with no approved task mandate returned DENY, matching the authored demo policy (au_ism_po_change_no_task_mandate_deny_v1).
• A second synthetic proposal carrying both the user's access and an approved task mandate returned APPROVAL_REQUIRED — human review required next.

Neither action was executed. The evidence record is hash-only and unsigned, with a verified content digest (e92e7342…). That is not a compliance certificate, not a live tenant configuration, and not proof of legal compliance. It is what a decision boundary looks like when authority is explicit: the action, the policy version, the decision and the digest, retained.

What to do Monday

1. Map every agent: identity, owner, purpose, credentials, tools, data scope, approved action classes.
2. Limit every tool to the minimum for the task; effective permission = narrower of user access and task authority.
3. Treat retrieved content as data, not authority.
4. Log tool calls, external requests and outputs centrally.
5. Make authority explicit before the side effect happens.

Selected excerpts from the official guidance:

"Each AI agent is assigned a unique identity that is distinct from the user accounts of personnel and the identities of other AI agents."

ISM guidelines for system access, September 2026.

"Tools invoked by agentic AI applications are subject to both the access controls of the invoking user and agent-specific, task-scoped authorisation, with effective permissions limited to the minimum permitted by both."

ISM guidelines for software development, September 2026.

"Some risks, including prompt injection, cannot be reliably addressed within the model alone and require additional controls across the harness, connected systems and organisational governance processes."

Agentic AI Harnesses, first published 11 September 2026.

Before a real release, check scope, ownership and the actual controls your systems enforce. Keep decision evidence that says what happened without pretending it proves legal clearance. Explore HaltState.

Inspect the isolated test record and limitations.