ISM-2156: Limit AI Agents to the Tools They Need

ISM-2156 says an agentic AI application, meaning software that uses an AI model to decide on and take actions through tools, not only answer questions, is given only the tools, functions and permissions its intended purpose needs. In practice you write down what each agent is for, give it the narrowest set of tools and access that does that job, and have the systems it calls enforce the limit, because the model itself can be fooled. The control is new in the September 2026 Information Security Manual and works with ISM-2157, which caps each tool call at what both the user and the task allow, and with the AI agent register (ISM-2135), where each agent's purpose and access are recorded.

#What does ISM-2156 require?

ASD's guidance for the subsection explains what makes an application agentic: applications "that can autonomously invoke tools, browse external content, execute code or call other systems introduce risks beyond those of conversational AI applications." An assistant that drafts a reply for you to send is conversational. One that reads your inbox, files documents, raises tickets, updates records or runs code by itself is agentic, whatever the product calls it.

The control names three things to keep to a minimum:

• Tools: the connectors, plug-ins and interfaces the agent can call at all, such as mail, file storage, a customer database, a web browser or a code runner.
• Functions: what each tool lets the agent do. A mail connector may read, send and delete; an agent that summarises incoming mail only needs to read.
• Permissions: the access rights behind the tools, held by the agent's identity or token in each system. Read access to one folder is not read access to every file.

The measure is the agent's "intended purpose", so the purpose must be written down before anyone can judge the minimum. ISM-2135 asks for exactly that pairing in the AI agent register: each agent's "owner and business purpose" beside "the tools, permissions and data repositories it can access".

The control sits in ASD's software development guidelines, so it speaks first to whoever builds an agent. Our reading is that building one in a low-code agent builder, or connecting a model to your systems with a few lines of code, counts. For agents inside software you buy, the matching duties sit elsewhere: agent identities and the register in the system access guidelines (ISM-2133 to ISM-2135), and human approval for sensitive or high-impact actions in system hardening (ISM-2113). ISM-2156 applies at every classification ASD marks, from non-classified systems to TOP SECRET, and is not part of the Essential Eight.

#Why does it matter?

An agent acts on the output of an AI model, and that output can be wrong or manipulated. ASD describes excessive agency as damaging actions performed "in response to unexpected, ambiguous or manipulated output from AI applications, regardless of the cause of the malfunction". A common cause is content the agent reads. ASD says content retrieved "via web browsing, email, document processing or retrieval-augmented generation, may contain instructions that the underlying AI model treats as legitimate", and that validation, sanitisation and delimitation "cannot be relied upon to make retrieved content trustworthy or eliminate indirect prompt injection."

So limiting what an agent can do is the control that still works after the model is fooled. In OWASP's example, an assistant that summarises mail through a connector that can also send receives an email with hidden instructions, then searches the inbox and forwards sensitive messages to the attacker. OWASP's fixes: a connector that can only read, a read-only permission, and a person who reviews and sends any reply (OWASP).

Joint guidance from ASD's Australian Cyber Security Centre and partner agencies in four other countries recommends "never granting it broad or unrestricted access, especially to sensitive data or critical systems". Their examples of permissions that are too broad include "an email assistant with write access to any inbox". They also describe the confused deputy: a user with little access gets a well-connected agent to do what the user could not, and because the agent acts under its own trusted identity, "the system produces audit logs that appear legitimate and delay detection" (ASD).

#How does it fit with the other controls?

ISM-2156 sets the ceiling for an agent as a whole. The controls around it make that ceiling hold:

• ISM-2157 limits each tool call twice: by the access of the person who asked and by the agent's own authorisation for the task, and the lower of the two wins. An agent summarising invoices for a finance manager cannot approve a payment, even though the manager could, and cannot open a file the manager could not.
• ISM-2158 treats anything the agent fetches, such as web pages, emails and documents, as untrusted data that can never change its instructions, tool permissions or human approval requirements.
• ISM-2113 has AI applications ask a person before sensitive or high-impact actions. ASD's examples are actions "that change privileges, that disable security controls, that initiate financial commitments, that transfer data outside the system boundary or that are otherwise irreversible".
• ISM-2159 logs every tool call, external request and output centrally for investigations.
• ISM-2133 gives each agent its own identity, separate from staff accounts and other agents, and ISM-2135 records in the register what each agent is for and what it can reach.

#How do you meet ISM-2156?

1. Find every agent. ASD notes that agents are often created "by personnel operating outside of traditional software deployment processes", so look beyond the development team, at assistants connected to mail and files and at agents built in business platforms. Each goes in the register (ISM-2134).
2. Write each agent's purpose in a sentence or two, specific enough to test a tool or permission against, with the things it must never do.
3. Remove the tools the purpose does not need. OWASP advises to "Avoid the use of open-ended extensions where possible", such as running any command or fetching any web address; where the purpose needs one, sandbox it and allow-list its destinations.
4. Within each tool, switch on only the functions needed: read rather than write, draft rather than send, one mailbox, folder or project rather than all of them.
5. Give the agent its own identity (ISM-2133) and the narrowest permissions, preferably access that acts on behalf of the requesting user with a further limit for the task (ISM-2157), using short-lived credentials rather than long-lived secrets.
6. Enforce the limits outside the model, in the identity platform, the tool's settings or a gateway. OWASP's advice is to "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not." An instruction in the prompt that says "never delete" is guidance to the model, not a control: the joint guidance warns that agents "may even bypass system-level instructions to achieve their objectives".
7. Put a person in front of high-impact actions (ISM-2113), and let the designers or operators, not the agent, decide which actions those are. ASD's guidance for that control is to show the person "the proposed action, target, data being disclosed and expected consequences".
8. Start narrow and widen with evidence. The joint guidance recommends "phased deployment with progressively increasing access and autonomy".
9. Review against the logs (ISM-2159): compare what each agent used with what it was granted, remove what it never uses, and repeat whenever its purpose, tools or model change.

#What evidence shows ISM-2156 is met?

Ask	Look at	Good looks like
Which agents do we run?	The AI agent register (ISM-2134, ISM-2135)	Every agent listed with an owner, including those staff set up
What is each agent for?	The purpose recorded for each agent	A purpose specific enough to judge a tool or permission against
Does each agent have only what that purpose needs?	Its configured tools and functions, and the permissions on its identity	Each traceable to the purpose; no wildcard or organisation-wide write access
Where are the limits enforced?	The identity platform, tool settings or gateway	In the systems the agent calls, not only in its instructions
Can an agent do more than the person who asked?	A test request from a user without the access	Refused (ISM-2157)
Who approves high-impact actions?	Approval settings and a sample of approvals (ISM-2113)	A person sees and approves the action before it runs
Are grants kept current?	Tool-call logs (ISM-2159) and review records	Unused tools and permissions removed after each review

#What gets in the way?

Agents arrive without a project. An assistant can be connected to mail and files in minutes without anyone recording it. Without a register, ASD notes, "an organisation cannot effectively restrict AI agents to the minimum permissions they require".

Connectors with coarse permissions. Some connectors offer only one broad grant, such as full access to a mailbox or a whole database. Choose a narrower connector, put a small tool you control in front of it, or record the risk and add an approval step.

Convenience. Broad access up front avoids repeated consent prompts and broken workflows. The Model Context Protocol, an open standard many agents use to reach their tools, lists "Bundling unrelated privileges to preempt future prompts" among its common mistakes and recommends "a progressive, least-privilege scope model" (Model Context Protocol).

Smaller and larger organisations. A smaller organisation usually meets agents as features in software it already uses, such as the office suite, accounting package or help desk. Its work is to switch off connectors it does not need, prefer read-only modes, keep a person approving sends and payments, and ask the supplier what the agent can reach. A larger organisation has many teams building agents and needs a shared pattern: central agent identities, an approved tool catalogue, a gateway that checks each call, central logs and a reviewed register.

The business case. The cost is design time and some user friction. What it buys is a limit on the damage when an agent is fooled or simply wrong, which the joint guidance says to plan for: organisations "should assume that agentic AI systems may behave unexpectedly and plan deployments accordingly". An agent that can only read one folder cannot leak the rest.

#What tools and skills help?

• An identity platform that issues agents their own identities and limits what they can be granted. Microsoft, for example, documents that Microsoft Entra Agent ID blocks agents from being granted many high privilege roles or permissions, and says "This design recognizes that agents should operate with least privilege" (Microsoft).
• Narrowly scoped, delegated access for each tool, with permissions that start small and grow only when an action needs them, as the Model Context Protocol's security guidance describes.
• A gateway or policy enforcement point that checks each call against the agent, the user and the task, and logs it for ISM-2159.
• Sandboxes, destination allow-lists and approval workflows for agents that run code, browse the web or take high-impact actions (ISM-2113).
• Testing, such as red teaming and prompt injection exercises that try to make an agent misuse its tools.
• Skills: someone who knows identity and access management and the agent platform, and can threat model an agent with OWASP's Top 10 for Agentic Applications, which ASD lists as further reading. OWASP calls the goal "Least-Agency", because "deploying agentic behavior where it is not needed expands the attack surface without adding value."

Which of the products you already pay for help here? The free coverage check shows which ISM and Essential Eight controls your current products can reach, in about three minutes. To see ISM-2156 among the other AI controls, open it in our sample coverage report, or read what an ISM assessment involves.

#What changed in recent ISM releases?

ISM-2156 is new: ASD added it in the September 2026 release, at revision 0, with ISM-2157 to ISM-2159 in the same subsection and the AI agent identity and register controls (ISM-2133 to ISM-2135) in the new system access guidelines. The same release changed ISM-2113 from flagging "organisationally defined risky actions" for approval to requiring "human approval before executing sensitive or high-impact actions" (ASD). ISM-2092 and ISM-2093, the two older controls in the subsection, were added in December 2025; the June 2026 release only shortened "artificial intelligence" to "AI" in both. Our ISM September 2026 summary covers the rest of the latest release.

#Sources

• ASD, Information security manual: ISM-2156, the excessive agency, AI agent and AI application controls, and the section guidance quoted on this page
• ASD, ISM September 2026 changes
• ASD's ACSC, CISA, NSA, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK, Careful adoption of agentic AI services (May 2026)
• OWASP GenAI Security Project, LLM06:2025 Excessive Agency
• OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications for 2026 (December 2025)
• Model Context Protocol, Security Best Practices: Scope Minimization
• Microsoft, Authorization in Microsoft Entra Agent ID