Least-Privilege Tool Scoping

Least-Privilege Tool Scoping is the defensive pattern of granting each AI agent tool only the authority required for the immediate task, narrowed across the relevant axes — file system path, network domain, credential, action — rather than the maximum authority the underlying connector can theoretically provide. It is one of the four operational controls that close most exposure to OWASP ASI02 (Tool Misuse and Exploitation) and is closely related to the principle of least privilege from classical access-control theory, applied to the agentic context.

The pattern matters because the default for most MCP connectors and tool integrations is maximum privilege — a filesystem MCP server typically grants access to the entire user home directory, a network tool typically allows arbitrary outbound connections, a credential-bearing tool typically allows the full set of API actions the credential authorises. Each of these defaults makes integration easier. Each also gives any successful prompt injection or tool poisoning attempt the maximum possible blast radius.

How Scoping Should Be Applied

Effective tool scoping operates at the host level rather than relying on the connector to enforce its own limits. A connector's claimed scope cannot be trusted under compromise — if the connector itself is the threat, its scope-enforcement code is too. The host configures and enforces the scope.

Common scoping axes:

• Path scoping for filesystem tools: restrict to a specific working directory, refuse traversal, refuse symlink resolution outside the scope.
• Domain scoping for network tools: an explicit allowlist of outbound domains; refuse arbitrary URL fetches.
• Credential scoping for API tools: per-credential restriction on which actions the agent can take; refuse credential reuse across unrelated tasks.
• Action scoping for any tool that takes destructive operations (write, delete, send): explicit per-action authorisation rather than blanket "this tool can do X" approval.
• Tenant scoping where multi-tenancy applies: per-tenant authority is enforced at the host, not just at the connector. The June 2025 Asana MCP cross-tenant access bypass would have been blocked by host-level tenant scoping regardless of how the connector itself enforced (or failed to enforce) the boundary.

Operational Implications

The deliberate consequence of least-privilege scoping is friction. Some tasks the agent could have performed by happy-path reasoning will instead require explicit user confirmation or explicit re-scoping. This is by design. For high-authority deployments — anything touching wallets, signing keys, regulated data, or external API credentials — that friction is the security control. Removing it removes the protection.

For deeper operational guidance, see the OWASP ASI02 explainer and the MCP Security Audit service description.