Helmwart
← Atlas · Mitigations Tier 2 · Real-composable

MITIGATION · m-tool-scope

Least-privilege tool scoping — a hard boundary on what each tool exposes

Each tool in an agent's catalog should expose only the methods, resources, and parameter ranges its designated role requires. Over-broad tool surfaces let individually authorised primitives compose into actions no human intended to grant; narrowing the scope at design time reduces both the attack surface and the blast radius of any compromise.

Last reviewed 2026-05-12 · Status: published · Evidence →

At a glance

MATURITY
Tier 2
Available off-the-shelf or as a documented pattern, but newer or less broadly proven. Expect integration work and some operational nuance.
PLACES ON
edge · node
Restricted to node kinds: tool-bus
COVERAGE
5 threats
T2 · T3 · T16 · T29 · T39
TRADE-OFFS
LAT
low
COST
low
UX
low
DEV
medium
Latency · cost · UX friction · dev effort.
TL;DR
  • Design every tool in the catalog with the minimum operation set its role requires, never add methods, resources, or parameter ranges "just in case".
  • Over-broad tool surfaces let individually authorised primitives compose into actions no human intended to grant, blast radius control starts at design time, not at call time.
  • Unlike m-tool-jit (controls when a tool is accessible) and m-tool-preexec (validates each call's parameters), m-tool-scope controls what the tool is designed to expose: which methods exist, which resources those methods reach, and which parameter ranges are in-schema.
  • A tool that has never had a transfer method cannot be prompted, manipulated, or chained into performing a transfer, regardless of the calling agent state, scope is a design invariant.

How it behaves

At tool design time, the team defines the minimum method set, resource namespace, and parameter ranges the tool needs for its designated role, nothing more.
The resource server (or API gateway) validates the caller token scope claim or IAM policy on every request; requests referencing methods or resources outside the defined surface return 403 before any business logic runs.
A single tool exposes read, write, delete, and transfer methods. A prompt-injection or chained call can reach any method the agent token allows, including ones the task never needed.
Each tool exposes only the method set its role requires. A delete or transfer method that does not exist in the schema cannot be reached by any call path, regardless of token permissions or prompt manipulation.
Scope enforcement is stateless per call: the resource server validates the token scope claim on every request with microsecond latency. Unlike JIT grants (which require a policy broker round-trip), persistent least-privilege scoping adds zero per-call overhead once the token is issued.

What it is

A tool is, from the agent's perspective, a callable surface: a set of methods, the resources those methods can reach, and the parameter ranges each method accepts. The failure mode specific to agentic systems is composition: an agent that holds legitimate access to a read method and a send method can chain them to exfiltrate data, even though neither capability in isolation was intended to enable that outcome. OWASP Agentic AI v1.1 §Tool Misuse Scenario 2 (Tool Chain Manipulation) is the canonical illustration. Least-privilege tool scoping addresses this at the design stage, by ensuring each tool exposes only what its designated role actually requires, so the composition never becomes possible in the first place.

Three scope dimensions apply:

  1. Action scope. Which methods does the agent's role include? payment.read is not the same grant as payment.transfer. Avoid wildcard method sets; enumerate the exact operations the role needs.
  2. Resource scope. Which resources can the agent's calls reach? Customer X's records, not the full customer table. Tenant A's vector store, not the cross-tenant namespace.
  3. Parameter scope. Even within an authorised action, which parameter values are permissible? transfer.amount ≤ user.daily_limit; email.to ∈ user.address_book. This is where role-based access control hands off to attribute-based conditions (both described in RBAC/ABAC): the action is allowed, but only within specific parameter envelopes.

In MCP and A2A deployments, a tool's self-description becomes a fourth surface. OWASP v1.1 T16 "Tool Misuse via Descriptive Exploitation" and the OWASP Multi-Agentic System Threat Modeling Guide v1.0 §5 T47 scenario (Rogue MCP Server in Ecosystem) both depend on scope being inferred from a description rather than enforced at the call boundary. Tool description content should be validated separately (tool description validation); scope enforcement must hold at the call boundary regardless of what the description claims.

Detection signals

  • Scope-denial rate per agent identity. A rising rate means the agent is attempting calls outside its declared surface, which points to prompt injection, scope misconfiguration, or adversarial probing.
  • Tool calls succeeding outside the agent's declared scope set. Any success here is a scoping misconfiguration; the call should not have reached the tool at all.
  • Drift between declared scope and observed call frequency. Consistently unused scopes are candidates for removal; unexpected new call patterns suggest scope has widened without a corresponding policy change.

Threats it covers

  • T2 Tool Misuse −2 severity steps

    WHY IT HELPS Tool Misuse works by chaining or parameter-polluting calls that are individually authorised. When each tool exposes only the methods and resources its role actually needs, those chains cannot reach capabilities outside the defined surface, regardless of how the calls are composed.

  • T3 Privilege Compromise −1 severity step

    WHY IT HELPS Privilege abuse after an agent compromise is bounded by what the agent's token scope permits. Least-privilege scoping ensures a fully compromised agent still holds only the narrowest authority the task required, not the broadest authority it could ever have needed.

  • T16 Insecure Inter-Agent Protocol Abuse −1 severity step

    WHY IT HELPS Descriptive Exploitation (OWASP T16) relies on the agent inferring broad capability from a tool's self-description. When scope is enforced at the call boundary independent of the description, a misleading description cannot unlock methods or resources that were never included in the tool's defined surface.

  • T29 Plugin Vulnerability Leading to Agent Compromise −1 severity step

    WHY IT HELPS A vulnerability in a plugin can only be leveraged to the extent of that plugin's declared scope. Over-broad scopes amplify what an attacker gains from a plugin exploit; narrow scopes contain the reachable damage to the tool's designated operation set.

  • T39 Unintended Resource Consumption via MCP −2 severity steps

    WHY IT HELPS An agent that lacks scope to invoke a resource-intensive tool cannot trigger it, regardless of whether it is prompted or manipulated to attempt the call. Unintended MCP resource consumption requires the agent to have scope first; this control removes that prerequisite.

Principle coverage

Defence-in-Depth stage: Prevent — and it advances:

  • Least Privilege Tool scoping is the direct application of least privilege to agent capabilities: each tool's method set, resource namespace, and parameter ranges are bounded to what the designated role actually requires, so the agent never holds more authority than its current task warrants.
  • Default / Implicit Deny A tool that does not expose a method cannot be reached by any call path; the absence of the capability in the schema is a structural deny, not a runtime decision that could be misconfigured or bypassed.
  • Attack Surface Minimization Every method, resource, and parameter range removed from a tool's defined surface is a path that no attack can traverse, scope reduction at design time shrinks the combinatorial surface available to prompt injection, chaining, and confused-deputy exploits.
  • Least Agency / Minimal Autonomy Tool scoping removes the agent's ability to act beyond the task's defined boundaries by ensuring the callable surface is bounded at design time, not left to the agent's runtime judgment about what is appropriate.
  • Confused-Deputy Prevention A confused-deputy attack requires the agent to invoke a capability beyond its intended mandate. When that capability is absent from the tool's defined scope, the agent cannot be induced to exercise it regardless of how the request is framed.
  • The Lethal Trifecta Tool scoping limits the third leg of the lethal trifecta, capability, by ensuring an agent with access to sensitive data and network egress cannot compose a full exfiltration path if the required transfer or send methods were never included in the tool's scope.

Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.

Implementation options

Five implementation patterns ordered by prevalence. OAuth scopes and cloud IAM cover hosted API tools; MCP inputSchema covers local/MCP-native tools; the capability flag matrix covers teams that own their tool implementations end-to-end.

OAuth 2.0 scopes Assign a dedicated OAuth scope string to each tool action: payment.read, payment.transfer, files.read, files.delete. The agent bearer token is issued with only the scope strings its role requires. The resource server validates the scope claim on every request and returns 403 if the required action scope is absent. Wildcard or overly-broad scopes (files.*, *) defeat the control, enumerate exact action names.

Why choose it: Authorization server must disclose any scope reduction in the response, surfacing scope mismatches for audit. RFC 6749 §3.3 is the canonical grammar: space-delimited, case-sensitive strings.

More details:

AWS IAM Attach a distinct IAM policy to each agent-tool identity (IAM role or service account). Specify exact Action strings, never wildcards, exact Resource ARNs scoped to the tenant prefix, and Condition keys to enforce parameter-range constraints (e.g. s3:prefix, aws:PrincipalTag/tenant_id). IAM Access Analyzer generates least-privilege policies from CloudTrail activity logs. Permission boundaries limit the maximum effective permissions even if a more permissive role policy is later attached.

Why choose it: AWS IAM documentation states the goal as "granting least privilege, or granting only the permissions required to perform a task." Access Analyzer removes the manual burden of enumerating exact actions from observed usage.

More details:

Google Workspace Google OAuth 2.0 publishes a per-API scope list with multiple granularity levels: gmail.readonly is read-only; gmail.modify adds write; mail.google.com/ is full access. Grant the narrowest scope that covers the tool operation set. Broader scopes trigger mandatory security review and user consent UI, a friction signal that enforces scope discipline at the developer stage.

Why choose it: The consent UI friction for broader scopes creates a developer-time enforcement signal: if a broad scope triggers security review, teams are incentivised to narrow the scope before shipping.

More details:

MCP tool descriptor MCP tool descriptors include a name, description, and inputSchema (JSON Schema). The inputSchema defines which parameters the tool accepts and their allowed types, formats, and enum values, anything outside the schema is rejected at the protocol layer before the server processes it. MCP spec Security Considerations require servers to validate all tool inputs and implement proper access controls. Scope must be enforced at the server call boundary independent of what the description says.

Why choose it: Protocol-layer rejection of out-of-schema calls means no application code path can reach an undefined parameter or method. Server-side access controls checking caller identity against a permission list for the requested tool name operationalise the MUST requirement.

More details:

Capability flag matrix For teams that own the tool implementations, a capability flag matrix documents for each tool: which methods are exposed, which resource namespaces each method can access, which parameter ranges are in-schema, and which agent roles are permitted to invoke it. The matrix is a checked-in YAML or JSON document reviewed during tool design and diffed on every change. A checklist item, "Does this tool expose only the minimum method and resource surface its role requires?", makes scope audits part of the normal change process.

Why choose it: OWASP AI Exchange names "blast radius control" as the goal of least model privilege. The matrix is the artifact that proves compliance: scope decisions are visible, versioned, and reviewable by anyone on the team.

More details:

Trade-offs

  • Scope enforcement is stateless and adds zero per-call latency once the token is issued, unlike JIT grants, there is no broker round-trip on each request.
  • Scope creep over time: agents that gain new responsibilities accumulate scopes that are never removed. Pair with m-nhi-lifecycle to re-attest scopes on a schedule.

When NOT to use

  • General-purpose assistants whose tool surface is legitimately open-ended and determined at runtime by user requests, over-scoping causes scope-denial errors without security gain; use m-tool-preexec and m-intent-attestation as the binding controls instead.
  • As a substitute for secure tool implementation, a tool scoped to read that has a server-side injection vulnerability is still exploitable; scope limits reach but does not fix implementation bugs.

Limitations

  • Descriptive exploitation: a malicious tool description that claims narrow scope while implementing broad behaviour is not stopped by the description, scope must be enforced at the server call boundary independent of what the description says.
  • Delegation chains: individually narrow scopes can compose across trust boundaries in ways that exceed any single tool surface, pair with m-intent-attestation for end-to-end intent binding.

Maturity tier reasoning

  • OAuth scopes, cloud IAM, and MCP inputSchema enforcement are all production-mature primitives widely deployed outside the agentic context.
  • The agentic application layer sits at T2 because there is no industry-standard tool-scope vocabulary, scope strings (OAuth) and action names (IAM) are system-specific enumerations that each team must define for their tool catalog.

Last verified against upstream docs: 2026-05-30.