What does ASD ISM 2157 require?

policyASD Information Security Manual (ISM)

ASD ISM 2157Agentic AI Tool Calls Limited by User Access and Task-Scoped Authorisation

When an AI agent calls a tool, it can only do what both the user who started it and the agent's own task-scoped authorisation allow, whichever is narrower.

Preventative NC OS P Artificial intelligenceASD Information Security ManualGuidelines for software development access control least privilege logging

record_voice_over

Plain language

Agentic AI applications do not just answer questions. They call tools: they query databases, send emails, run scripts, open tickets, read files and call APIs on the user's behalf. This control says that every one of those tool calls must pass two separate permission checks, and the agent only gets the overlap between them. The first check is the invoking user's own access controls. If the person who kicked off the agent cannot read the finance share, the agent acting for them cannot read it either. The agent must never become a way to reach data or actions the user is not entitled to. The second check is agent-specific, task-scoped authorisation. Even if the user personally has broad access, the agent should only be granted the narrow set of tools and permissions the specific task needs. An agent asked to summarise a document does not need the ability to delete files or send mail, regardless of what the user could do by hand. The effective permission is the minimum permitted by both. If either check says no, the tool call is denied. Why it matters: agents follow instructions, and those instructions can be hijacked through prompt injection in a web page, email or document the agent reads. They can also misread a task and take unintended actions. Without the user check, an agent running under a powerful service account becomes a privilege-escalation path for anyone who can talk to it. Without the task check, a hijacked or confused agent inherits every permission the user has. Applying both keeps the blast radius of any single mistake or attack as small as possible.

01 - Overview

Framework

ASD Information Security Manual (ISM)

Control effect

Preventative

Classifications

NC, OS, P, S, TS

ISM last updated

Sept 2026

Control Stack last updated

05 Sept 2026

E8 maturity levels

N/A

Guideline

Guidelines for software development

Section

Artificial intelligence application development

Topic

Excessive agency

Official control statement

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.

policyASD Information Security Manual (ISM)ISM-2157

priority_high

Why it matters

If tool calls are not constrained by both the invoking user's access and task-scoped agent authorisation, an agentic AI application becomes an over-privileged actor. A user could use the agent to reach data or perform actions they are not personally authorised for, defeating existing access controls. A prompt-injection attack or an agent that misunderstands its task could use the full breadth of the user's permissions (or a shared service account's permissions) to exfiltrate data, modify or delete records, send messages, or trigger changes in connected systems, with actions attributed to the user rather than the attacker. The result can be unauthorised disclosure, integrity loss and business disruption that is hard to trace back to the agent.

settings

Operational notes

In day-to-day operation the control shows up as two gates in front of every tool the agent can call.

Identity propagation: the agent runs each tool call under the invoking user's identity (or a delegated token bound to that user), not under a broad shared service account. When the user lacks access, the tool returns a denial and the agent reports it rather than working around it.
Task-scoped agent grants: each agent (or each task type an agent performs) has a defined allow-list of tools and, within each tool, the narrowest operations and data scope needed. New tasks get a new, separately approved scope rather than expanding an existing one.
Intersection at runtime: the platform computes the effective permission as the overlap of the two. Neither the user's broad rights nor the agent's grant can widen what the other permits.
Change handling: when a tool is added, an agent is repurposed, or a user's role changes, the relevant scope is reviewed and the intersection re-evaluated before the change goes live.
Logging: each tool call records which user invoked it, which agent and task scope applied, what was requested, and whether it was allowed or denied, so denials and unexpected reach can be investigated.
Periodic review: agent scopes are reviewed alongside normal access reviews so that task grants do not silently accumulate.

02 - Implement

build

Implementation tips

The AI platform or engineering team configures every tool integration used by an agentic AI application to execute under the invoking user's identity, for example by passing a delegated, user-bound token to each downstream system rather than a shared service credential, so the target system enforces the user's own access controls on each call.
The application owner, with the security team, documents a task-scoped authorisation profile for each agent (or each task an agent performs) listing the permitted tools, the permitted operations within each tool, and the data scope, limited to the minimum needed for that task, and has it approved before the agent is deployed.
The engineering team implements a policy enforcement point in the agent's tool-calling layer that evaluates both the user's access and the agent's task-scoped profile on every call and permits only the intersection, denying any call that fails either check and returning a clear denial to the agent instead of a fallback path.
The engineering team tests the enforcement before release by running the agent as a low-privilege test user and confirming it cannot reach data or actions that user lacks, and by running it as a high-privilege user and confirming it still cannot use tools or operations outside its task scope.
The platform team enables per-call logging that records the invoking user, the agent and task scope applied, the tool and operation requested, and the allow or deny decision, and routes denials and out-of-scope attempts to the security monitoring queue for follow-up.

03 - Audit

fact_check

Audit / evidence tips

AskAsk for the design or architecture document showing how tools invoked by the agentic AI application authenticate to downstream systems.Look atLook at whether each tool call carries the invoking user's identity or a user-bound delegated token, or whether it uses a shared service account.GoodEvery tool call runs under the invoking user's identity so the downstream system applies that user's access controls; shared broad credentials are not used for user-initiated agent actions.
AskAsk for the approved task-scoped authorisation profile for each agent or task type.Look atLook at the list of permitted tools, operations and data scope, and whether each entry is justified by the task the agent performs.GoodEach agent has a written, approved scope limited to what its task needs, with no blanket grants and no operations unrelated to the task.
AskAsk for the policy enforcement configuration or code in the tool-calling layer that combines the user and agent checks.Look atLook at how the two checks are evaluated and what happens when only one of them permits the call.GoodBoth checks are evaluated on every call and the effective permission is the minimum of the two; a call denied by either check is blocked rather than allowed through.
AskAsk for test evidence or a live demonstration of the agent running as a low-privilege user and as a high-privilege user.Look atLook at whether the low-privilege run is blocked from data that user cannot access, and whether the high-privilege run is still blocked from tools outside the agent's task scope.GoodThe agent cannot exceed the user's access in the first case and cannot exceed its task scope in the second, demonstrating that neither side widens the other.
AskAsk for a sample of tool-call logs from a recent period, including denied calls.Look atLook at whether each record identifies the invoking user, the agent and task scope, the tool and operation, and the allow or deny outcome, and whether denials were reviewed.GoodLogs show both authorisation dimensions on every call, denials are present and explainable, and out-of-scope attempts were followed up.

04 - Mappings

link

Cross-framework mappings

How ISM-2157 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.

ISO 27001

Control	Notes	Details
layersPartially meets(2)expand_less
Annex A 5.15	ISM-2157 requires dual-bounding of permissions for agent tool calls (user permissions plus task-scoped agent authorisation) so actions ca...
Annex A 8.3	ISM-2157 requires that tools invoked by an agentic AI application are constrained by both the invoking user's access and an agent-specifi...