Skip to main content
Tool exposure policy removes tools before the model sees them. This is different from blocking a request. A request can continue with a smaller tool set, so the agent can still answer or use safer tools.

​
When to Use It

Use tool exposure when:
  • the same agent should behave differently at different risk levels
  • some tools have side effects and others are read-only
  • you want graceful degradation before a full request block
  • newly discovered tools need explicit policy coverage
Examples:
  • allow search_docs but hide send_email
  • hide browser or outbound action tools during prompt-extraction attempts
  • remove all tools for very high-risk requests

​
Where It Lives

Tool exposure is configured inside a policy. Different policies can expose different tools even in the same organization. The policy detail page also shows discovered tools for that policy, which is the fastest way to see what tool identities Averta has observed from real traffic.

​
Rule Semantics

Each tool exposure policy contains one or more rules. Inside one rule, conditions are combined with AND. Across rules, rules are combined with OR. That means:
  • a single rule matches only when all its conditions match
  • the policy restricts tools when any rule matches

​
Rule Inputs

InputMeaning
Binary thresholdActivates the rule when request risk reaches the threshold.
Intent labelsRestrict the rule to selected classified intent categories.
Intent minimum confidenceRequires stronger intent confidence before the rule activates.
Block toolsRemoves specific tool identities from the request.
Block all toolsRemoves every tool from the request.
Threshold and confidence values must be between 0 and 1.

​
Rule Validation

The editor enforces important constraints:
  • every rule needs at least one condition
  • every rule needs at least one action
  • a rule cannot both block all tools and list named blocked tools
  • duplicate tool names are rejected
  • duplicate intent labels are rejected
  • intent confidence requires at least one intent label
These constraints are useful. A vague rule with no condition or no action is worse than no rule because it creates misleading coverage.

​
Tool Identity

Blocked tool names must match the normalized identity Averta sees. Common identities:
Provider surfaceIdentity
OpenAI Responses function toolname
OpenAI Responses custom toolname
OpenAI hosted tooltype
OpenAI MCP toolmcp:<server_label> when server_label exists
OpenAI Chat Completions function toolfunction.name
Anthropic client toolname
Use discovered tools and Events to avoid guessing identities.

​
Discovered Tools

Discovered tools are the tools Averta has seen for a specific policy. For each tool, the dashboard can show:
  • tool name
  • description, when available
  • mapped or unmapped status
  • first-seen time
A tool is mapped when a rule explicitly blocks it or a rule blocks all tools. A tool is unmapped when Averta has seen it but no current rule accounts for it. Newly discovered tools stay allowed until you block them with a rule. If that is not what you want, review discovered tools after every meaningful agent or SDK change.

​
Rollout Pattern

  1. Start with side-effectful tools first.
  2. Add one or two threshold bands before adding complex intent conditions.
  3. Confirm restrict_tools decisions in Events.
  4. Review discovered tools after deployments.
  5. Prefer selective blocking before block all tools unless the request risk is extreme.

Policies

See the broader policy lifecycle and request threshold controls.

Events

Investigate restrict_tools and other runtime decisions.