Tool-use permissions for agentic AI — least privilege for agents

The tool manifest is the list of tools made available to the model at runtime. It is typically defined in the agent configuration — a JSON schema, a Python list of tool definitions, or a similar structure — and it is what the model sees when it decides what action to take next.

Each tool in the manifest has a name, a description, and a parameter schema. The model reads the name and description to understand what the tool does. When the model decides to invoke a tool, it generates the parameters, and the tool executes with those parameters. The model does not check whether it “should” invoke a tool in a security sense — that check is the application developer's responsibility.

This matters because the model reasons about what it can do in terms of the tool manifest. If the manifest includes a “send_email” tool, the model knows it can send emails. If prompted — by a user, by retrieved content, or by a hijacked reasoning loop — to send an email, it will, as long as “send_email” is in the manifest. Remove the tool, and the capability is gone.

Tool manifests are almost always built during development, where the developer's goal is to make the agent capable and useful. In that context, the tendency is to add tools speculatively: "We might need to send emails," "Let's include file write access in case we want to log things," "The admin console API might be useful later."

Several structural factors reinforce this tendency:

Development vs production parity failures.Developers build and test with a full manifest because it makes development easier. The manifest is never audited before production deployment because "it's the same one we tested with."

Tool consolidation pressure. In systems where tools are shared across multiple agents, it is easier to give all agents access to a shared tool set than to define separate manifests per agent per deployment context. The result is every agent having access to every tool the system supports.

Missing ownership. No one is clearly responsible for auditing the tool manifest before deployment. The developers who built the agent consider the manifest a technical configuration. The security team, if consulted, focuses on infrastructure rather than agent configuration. The manifest ships as-is.

The performance halo. An agent that can do more seems better. There is social pressure to demonstrate capability breadth — including more tools makes demos more impressive. This pressure rarely reverses before production.

In assessed systems, we routinely find tool manifests that include capabilities with no plausible connection to the agent's declared task. An internal Q&A agent with calendar management tools. A document summariser with code execution access. These are not edge cases — they are the norm in first-generation agentic deployments.

The principle of least privilege as applied to agentic AI is straightforward: the tool manifest for a given deployment should include only the tools the agent requires to complete its specific task in its specific deployment context.

This has two key qualifiers that are often missed:

“Specific task” means the task this deployment is designed to perform, not the full range of tasks the agent could theoretically perform. A document review agent should not have web search access because some document review tasks could conceivably benefit from external research. It should have web search access only if the defined task explicitly requires external research.

“Specific deployment context” means the environment in which this instance of the agent runs. The same agent design might run in a development environment with broad tool access, a staging environment with production data but restricted tool scope, and a production environment with the minimal manifest required. Context changes what is needed — and therefore what should be permitted.

Least privilege is not just about removing tools entirely. It also applies to tool parameters:

• A file read tool should specify which directories it can read from, not accept arbitrary paths
• A database tool should be scoped to specific tables or schemas, not the full database
• An email tool should be restricted to specific domains or recipients, not open to any destination
• A code execution tool should run in a sandboxed environment with no network access and restricted filesystem scope

The manifest audit is a structured review of every tool the agent has access to, conducted against the specific deployment task. The audit follows four steps for each tool:

Step 1: Task necessity check.Is this tool required to complete the agent's defined task? The answer must be “yes, because [specific task step]” — not “possibly,” not “it might be useful,” and not “we had it from development.” Anything that does not pass this check is a removal candidate.

Step 2: Context appropriateness check. Even if the tool is task-necessary, is it appropriate for this deployment context? A tool that is appropriate in an internal-only deployment may not be appropriate when the agent is customer-facing. A tool that is appropriate with authenticated users may not be appropriate with anonymous inputs.

Step 3: Parameter scope review. For tools that pass Steps 1 and 2, review the parameter schema. Are the parameters constrained to the minimum scope needed? A file read tool that accepts an arbitrary path should be scoped to the directory the agent needs. A database tool that accepts arbitrary SQL should be replaced with typed operations.

Step 4: Authorization review.For tools that pass Steps 1-3, confirm that authorization is enforced at the tool level — not just by the model's reasoning. The tool should verify that the invoking identity (the agent, and by extension, the user whose session the agent is serving) has permission for the specific operation before executing.

A well-designed agentic system defines separate tool manifests for each distinct deployment context. The implementation mechanism varies by framework, but the principle is consistent: the manifest loaded at runtime is determined by the deployment context, not by a single shared definition.

Consider a customer service agent deployed in three contexts:

• Unauthenticated pre-sales context: Read access to public documentation, FAQ lookup, contact form submission. No access to customer data, order systems, or internal tools.
• Authenticated customer context: Read access to that customer's order history and account data, support ticket creation, knowledge base search. No access to other customers' data or admin functions.
• Internal support agent context: Read access to any customer record for which the support agent has an open ticket, support ticket update, internal notes. No access to billing or account administration tools.

Each context has a distinct manifest. The same model, running in each context, has fundamentally different capabilities. This scoping limits the blast radius in each context to actions that are appropriate for that context — regardless of what an attacker might attempt to inject.

Verifying that the manifest is correctly scoped requires both static and behavioral testing.

Static verification: Review the manifest definition against the task specification. Every tool should have a documented justification tied to a specific task step. Any tool without a documented justification is a finding.

Behavioral verification:Attempt to invoke each tool that was removed or restricted, via both direct request (“call the send_email tool”) and indirect request (“send me an email summary of this document”). In a correctly scoped deployment, removed tools should not be available — the model should report that it cannot perform that action.

Parameter boundary testing: For tools that remain in the manifest, test parameter boundaries. Attempt to pass paths outside the scoped directory, queries against tables outside the scoped schema, or email addresses outside the permitted domain. The tool should reject these with a permission denied response, not execute them and return an error.

The distinction matters: an execution error means the tool ran and then failed. A permission denied means the tool never executed. Only the latter verifies that the parameter constraints are enforced at the authorization layer, not just in error handling.

The evidence a security review must produce for tool manifest scope includes:

• Manifest snapshot — the complete tool manifest as deployed, with all tools, descriptions, and parameter schemas documented
• Justification record — for each tool, the specific task step that requires it, and the deployment context in which it applies
• Removal record — any tools that were identified in the development manifest but removed before deployment, with the rationale
• Parameter constraint documentation — for each scoped tool, the parameter constraints applied and the authorization enforcement mechanism
• Verification test results — behavioral test outcomes confirming that removed tools are unavailable and parameter constraints are enforced at the tool level

This evidence set supports the tool-use permissions section of the risk disposition in the agentic AI security review. Without it, a reviewer cannot confirm that the least-privilege claim in the disposition is grounded in the actual deployment configuration.