Tool limiting strategies: o controle invisível que separa demo de produção

Agente em demo recebe acesso a 50 tools “para mostrar potencial”. Agente em produção recebe acesso a 5-10 tools, com escopo cirúrgico. A diferença não é técnica — é stewardship.

Tool limiting é a camada 2 do Harness Stack. Cinco estratégias com tradeoffs.

Estratégia 1 · Allowlist explícita

Lista hardcoded de tools que o agente pode chamar. Default deny.

tools:
  - read_user_profile
  - search_kb
  - create_ticket
  # Nada mais é acessível.

Quando usar: agente em produção com escopo definido. Default para qualquer agent live em 2026.

Tradeoff: rígido. Adicionar tool nova exige deploy.

Estratégia 2 · Capability-based + RBAC

Tool pode ser chamada se: agente tem capability “X” AND usuário tem role “Y”.

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

Quando usar: SaaS multi-tenant onde mesmo agente serve users com permissões diferentes.

Tradeoff: complexidade de policy. Vale para sistema com >5 tools sensíveis.

Estratégia 3 · Scope per channel

Mesma tool, escopo diferente por canal. WhatsApp tem reversibility menor que Telegram interno, então constraint aperta.

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

Quando usar: agente multi-canal (ex.: gateway multi-canal open-source).

Tradeoff: testes precisam cobrir cada canal.

Estratégia 4 · Time-boxed grants

Capability concedida por janela curta. Após N minutos, revoga.

agent.grant_tool('transfer_funds', expires_in=300)  # 5 minutos
# Após expirar, agente perde acesso. Precisa renovar via humano.

Quando usar: action sensível com fluxo de trabalho específico (transferência aprovada para essa transação).

Tradeoff: state management. Não trivial em sistema stateless.

Estratégia 5 · Budget-based limits

Tool tem orçamento (calls/dia, $/dia, volume processado). Quando estoura, bloqueia.

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

Quando usar: tools com custo direto (vendor API caro, cota externa).

Tradeoff: estimar limites realistas. Muito apertado → agente trava em horário de pico.

Matriz de decisão

Cenário	Estratégia primária
Agente single-user, tools poucas	Allowlist
SaaS multi-tenant, RBAC existente	Capability + RBAC
Agente multi-canal	Scope per channel
Fluxo workflow com escalation	Time-boxed grants
Vendor API com cota	Budget-based

Combinações são comuns. Allowlist + budget é o padrão para a maioria dos agentes em produção 2026.

O que NÃO fazer

Anti-pattern 1 · “Implícito no prompt”

System prompt: “Não delete dado sem confirmar”. Constraint via prompt é frágil — prompt injection (vetor 1 da Prompt Infection Taxonomy) bypassa.

Tool limiting é código, não esperança.

Anti-pattern 2 · “Liberar tudo e auditar”

“Deixa o agente fazer, auditoria pega quando errar”. Em ação irreversível, auditoria depois é só relatório de incidente. Constraint antes da ação é o ponto.

Anti-pattern 3 · “Mesmo escopo para todos os ambientes”

Dev, staging, prod precisam de constraints diferentes. Dev pode ter mais. Prod tem menos. Não invente: tool limiting é por ambiente.

Integração com o Trust Stack

Tool limiting alimenta dimensões de Agent Trust Stack:

• Reversibility: tools de write escapam de “totalmente reversível”.
• Blast radius: tools que tocam infra compartilhada vs sandbox.
• Auditability: cada tool call logada com input + output + actor.

Onde aprofundar

Harness Stack hub para o framework completo. Prompt Infection Taxonomy para os vetores que tool limiting bloqueia.