Tool limiting strategies: el control invisible que separa demo de producción

Agente en demo recibe acceso a 50 tools “para mostrar potencial”. Agente en producción recibe acceso a 5-10 tools, con scope quirúrgico. La diferencia no es técnica — es stewardship.

Tool limiting es la capa 2 del Harness Stack. Cinco estrategias con tradeoffs.

Estrategia 1 · Allowlist explícita

Lista hardcoded de tools que el agente puede llamar. Default deny.

tools:
  - read_user_profile
  - search_kb
  - create_ticket
  # Nada más es accesible.

Cuándo usar: agente en producción con scope definido. Default para cualquier agent live en 2026.

Tradeoff: rígido. Agregar tool nueva exige deploy.

Estrategia 2 · Capability-based + RBAC

Tool puede ser llamada si: agente tiene capability “X” AND usuario tiene role “Y”.

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

Cuándo usar: SaaS multi-tenant donde el mismo agente sirve users con permisos diferentes.

Tradeoff: complejidad de policy. Vale para sistema con >5 tools sensibles.

Estrategia 3 · Scope per channel

Misma tool, scope diferente por canal. WhatsApp tiene reversibility menor que Telegram interno, entonces constraint aprieta.

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

Cuándo usar: agente multi-canal (ex.: gateway multi-canal open-source).

Tradeoff: tests necesitan cubrir cada canal.

Estrategia 4 · Time-boxed grants

Capability concedida por ventana corta. Después de N minutos, revoca.

agent.grant_tool('transfer_funds', expires_in=300)  # 5 minutos
# Después de expirar, agente pierde acceso. Necesita renovar vía humano.

Cuándo usar: action sensible con flujo de trabajo específico (transferencia aprobada para esa transacción).

Tradeoff: state management. No trivial en sistema stateless.

Estrategia 5 · Budget-based limits

Tool tiene presupuesto (calls/día, $/día, volumen procesado). Cuando estoura, bloquea.

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

Cuándo usar: tools con costo directo (vendor API caro, cuota externa).

Tradeoff: estimar límites realistas. Muy apretado → agente se traba en horario pico.

Matriz de decisión

Escenario	Estrategia primaria
Agente single-user, tools pocas	Allowlist
SaaS multi-tenant, RBAC existente	Capability + RBAC
Agente multi-canal	Scope per channel
Flujo workflow con escalation	Time-boxed grants
Vendor API con cuota	Budget-based

Combinaciones son comunes. Allowlist + budget es el padrão para la mayoría de los agentes en producción 2026.

Lo que NO hacer

Anti-pattern 1 · “Implícito en el prompt”

System prompt: “No borres dato sin confirmar”. Constraint vía prompt es frágil — prompt injection (vector 1 de la Prompt Infection Taxonomy) bypassa.

Tool limiting es código, no esperanza.

Anti-pattern 2 · “Liberar todo y auditar”

“Deja que el agente haga, auditoría pesca cuando errar”. En acción irreversible, auditoría después es solo informe de incidente. Constraint antes de la acción es el punto.

Anti-pattern 3 · “Mismo scope para todos los ambientes”

Dev, staging, prod necesitan constraints diferentes. Dev puede tener más. Prod tiene menos. No inventes: tool limiting es por ambiente.

Integración con el Trust Stack

Tool limiting alimenta dimensiones del Agent Trust Stack:

• Reversibility: tools de write escapan de “totalmente reversible”.
• Blast radius: tools que tocan infra compartida vs sandbox.
• Auditability: cada tool call logueada con input + output + actor.

Dónde profundizar

Harness Stack hub para el framework completo. Prompt Infection Taxonomy para los vectores que tool limiting bloquea.