Skip to main content
Tool Permission controls which tools the LLM is even allowed to see. It filters the tools array in the outgoing LLM request, removing any tool that isn’t authorized for the current route, application, or identity — before the model has a chance to plan a call against it. It’s the foundational security layer for AI agents. Even if your application code hands 20 tools to the LLM, Tool Permission can restrict the model’s view to just the 5 it actually needs.

​
What it does

  • Extracts the tools array from the LLM request.
  • Applies an allow-list (whitelist) or deny-list (denylist) to the declared tool names.
  • Rewrites the request body with the filtered tool set before forwarding to the model.
  • Tool names must match exactly the names in the request’s tools array — no fuzzy matching.
Because filtering happens at the gateway, the LLM never sees removed tools at all. The model can’t pick them, hallucinate calls to them, or be nudged toward them by an injected prompt.

​
Where it lives in the picker

Tool Permission sits under the Agent Security category in Create Policy → When, alongside Tool Guard and Tool Selection. Attach it to a policy, choose between a whitelist or a denylist, and set the outcome in the Then step:
  • Log — emit an observability record describing which tools would have been filtered.
  • Block — reject the request if the filter would strip all tools (optional, strict mode).
  • The default action is to rewrite the request with the filtered list and let it proceed.
Pair the detection with the policy’s Where filters (application, endpoint, identity) so a tool policy targets only the surfaces that need it.

​
Configuration

Use Whitelist OR Denylist — not both. If both are configured, Whitelist takes priority and Denylist is ignored.
FieldPurpose
WhitelistList of allowed tool names. Only these tools are sent to the LLM; everything else is removed.
DenylistList of blocked tool names. These tools are removed from the request; the rest pass through.

​
When to pick which

  • Whitelist — recommended default. Start from the minimal set of tools the route needs and keep the surface locked down. Useful for production routes where the tool catalog is known and stable.
  • Denylist — useful when a large catalog needs a handful of temporary blocks (e.g. during an incident, or to deprecate a tool across every route with one policy) without re-enumerating every allowed tool.

​
Typical patterns

  • Read-only routes — whitelist only *.read / *.list tools; writes, deletes, and outbound HTTP are removed automatically.
  • Tenant isolation — different whitelists per tenant identity so cross-tenant tools are never exposed.
  • Incident mode — push a denylist policy that removes a compromised tool across every application in minutes.

​
Pairs well with

  • Tool guard — once a tool is allowed through, scan the system prompt and tool descriptions for jailbreak content.
  • Tool selection — validate the tool call the model actually produces against the declared schema.