Tool limiting strategies: the invisible control separating demo from production

Demo agents get access to 50 tools “to show potential.” Production agents get 5-10 tools with surgical scope. The difference isn’t technical — it’s stewardship.

Tool limiting is layer 2 of the Harness Stack. Five strategies with tradeoffs.

Strategy 1 · Explicit allowlist

Hardcoded list of tools the agent can call. Default deny.

tools:
  - read_user_profile
  - search_kb
  - create_ticket
  # Nothing else accessible.

When to use: agent in production with defined scope. Default for any live agent in 2026.

Tradeoff: rigid. Adding a new tool requires deploy.

Strategy 2 · Capability-based + RBAC

Tool can be called if: agent has capability “X” AND user has role “Y”.

tools:
  delete_account:
    requires_agent_capability: dangerous_action
    requires_user_role: admin
    requires_durable_pause: true

When to use: multi-tenant SaaS where the same agent serves users with different permissions.

Tradeoff: policy complexity. Worth it for systems with >5 sensitive tools.

Strategy 3 · Scope per channel

Same tool, different scope per channel. WhatsApp has lower reversibility than internal Telegram, so constraint tightens.

tools:
  send_email:
    whatsapp_channel: { requires_human: true }
    telegram_internal: { requires_confirmation: false }
    discord_public: { blocked: true }

When to use: multi-channel agent (like a multi-channel open-source gateway).

Tradeoff: tests must cover each channel.

Strategy 4 · Time-boxed grants

Capability granted for a short window. After N minutes, revoked.

agent.grant_tool('transfer_funds', expires_in=300)  # 5 minutes
# After expiry, agent loses access. Must renew via human.

When to use: sensitive action with specific workflow (transfer approved for this transaction).

Tradeoff: state management. Non-trivial in stateless systems.

Strategy 5 · Budget-based limits

Tool has a budget (calls/day, $/day, volume processed). When exceeded, blocks.

tools:
  expensive_llm_call:
    daily_budget_usd: 50
    daily_call_limit: 1000
    hourly_burst: 100

When to use: tools with direct cost (expensive vendor API, external quota).

Tradeoff: estimate realistic limits. Too tight → agent stalls at peak.

Decision matrix

Scenario	Primary strategy
Single-user agent, few tools	Allowlist
Multi-tenant SaaS, existing RBAC	Capability + RBAC
Multi-channel agent	Scope per channel
Workflow with escalation	Time-boxed grants
Vendor API with quota	Budget-based

Combinations are common. Allowlist + budget is the standard for most 2026 production agents.

What NOT to do

Anti-pattern 1 · “Implicit in the prompt”

System prompt: “Don’t delete data without confirming.” Constraint via prompt is fragile — prompt injection (vector 1 of Prompt Infection Taxonomy) bypasses.

Tool limiting is code, not hope.

Anti-pattern 2 · “Allow everything and audit”

“Let the agent act, audit catches when it errs.” In irreversible action, after-the-fact audit is just an incident report. Constraint before action is the point.

Anti-pattern 3 · “Same scope across all environments”

Dev, staging, prod need different constraints. Dev can have more. Prod has less. Don’t invent: tool limiting is per environment.

Integration with Trust Stack

Tool limiting feeds Agent Trust Stack dimensions:

• Reversibility: write tools escape “fully reversible.”
• Blast radius: tools touching shared infra vs sandbox.
• Auditability: every tool call logged with input + output + actor.

Where to go deeper

Harness Stack hub for the complete framework. Prompt Infection Taxonomy for vectors that tool limiting blocks.