Idea en 30 segundos
Blind Tool Trust es un anti-pattern donde el agente acepta el tool output "tal cual", sin verificar formato, contenido y seguridad.
Como resultado, errores de herramienta pasan a la cadena de decisiones: el modelo "completa" datos faltantes, y el sistema puede ejecutar una acción externa incorrecta.
Regla simple: todo tool output debe pasar validación antes del siguiente paso, o el run debe terminar con stop_reason claro.
Ejemplo del anti-pattern
El equipo construye un agente de soporte que lee el perfil del cliente y ejecuta una acción de inmediato con base en eso.
Cuando la herramienta devuelve output inválido o parcial, el agente igual continúa.
tool_result = run_tool("get_customer_profile", customer_id)
# account_status missing / credit_limit None, pero el run sigue
decision = agent.decide_next_action(tool_result)
execute(decision)
En este esquema falta la etapa de protección:
# no hay strict parse
# no hay schema validation
# no hay invariant checks
Para este caso se necesita un validation-gate antes de usar tool output:
parsed = validate_tool_output(tool_result)
if not parsed.ok:
return stop("invalid_tool_output")
Si la validación falla, el run no debe continuar a un paso write.
En este caso, la confianza ciega en tool output agrega:
- riesgo de corrupción silenciosa de datos
- acciones incorrectas sobre output inválido
- incidentes complejos difíciles de explicar
Por qué aparece y qué sale mal
Este anti-pattern aparece cuando el equipo asume: "la herramienta es nuestra, entonces podemos confiar".
Causas típicas:
- se valida input, pero no output
- la schema validation se deja "para después"
HTTP 200se interpreta como señal de datos correctos- se espera que el modelo "se arregle solo" con output sucio
Como resultado aparecen problemas:
- corrupción silenciosa - output inválido pasa a pasos siguientes
- decisiones incorrectas - el agente actúa sobre datos parciales o contradictorios
- riesgo de side effects - una write action puede ejecutarse sobre payload roto
- debug frágil - cuesta probar dónde los datos se volvieron inválidos
- incidentes repetidos - sin stop reason explícito, reproducir es difícil
A diferencia de Tool Calling for Everything, el problema central aquí no es la cantidad de llamadas, sino que el resultado no pasa validación obligatoria.
Señales típicas de producción de que confías en tools "a ciegas":
- una herramienta devuelve payload parcial o inesperado, pero el run continúa
- en logs casi no aparece
invalid_tool_output, aunque haya incidentes de datos - la tasa de malformed payload o tool errors es visible, pero casi nunca termina en
invalid_tool_output - fallos downstream aparecen más tarde en la cadena y no en el punto de ingreso del tool output
- el mismo tipo de error vuelve periódicamente en escenarios similares
- el equipo no tiene regla clara de cuándo parar un run por output inválido
Es importante: el tool output es dato externo, no verdad. Sin checks de parse/schema/invariant, el agente toma decisiones críticas sin base confiable.
Enfoque correcto
Empieza con un pipeline de validación simple para cada herramienta crítica. Si el output no pasa checks, no dejes que el run continúe "por inercia".
Marco práctico:
- valida
content_typey límites técnicos básicos (por ejemplo,max_chars) - aplica strict parse del formato esperado
- valida schema e invariants de negocio
- si falla, devuelve
stop_reason="invalid_tool_output"o cambia a safe-mode
def use_customer_profile(customer_id: str):
raw = run_tool("get_customer_profile", customer_id)
parsed = parse_json_strict(raw, max_chars=200_000) # rejects malformed JSON
profile = validate_schema("customer_profile", parsed)
if not check_invariants(profile): # required fields, ranges, business rules
return stop("invalid_tool_output") # or switch to safe-mode for read-only paths
action = agent.decide_next_action(profile)
return execute(action)
En este esquema, el sistema o trabaja con datos válidos o se detiene de forma transparente y más segura.
Prueba rápida
Si respondes "sí" a estas preguntas, tienes riesgo de anti-pattern Blind Tool Trust:
- ¿El run continúa aunque el tool output tenga formato dudoso?
- ¿
HTTP 200se interpreta como "datos válidos" sin chequeo de schema? - ¿Las acciones con side effects pueden iniciar antes de validar tool output?
Cómo se diferencia de otros anti-patterns
Write Access Default vs Blind Tool Trust
| Write Access Default | Blind Tool Trust |
|---|---|
| Problema principal: el acceso write está permitido por defecto. | Problema principal: se acepta tool output sin validación obligatoria. |
| Cuándo aparece: cuando deny-by-default no se aplica a acciones con cambio de estado. | Cuándo aparece: cuando checks de parse/schema/invariant se saltan o se hacen solo de forma formal. |
En resumen: Write Access Default trata de permisos excesivos, mientras Blind Tool Trust trata de confianza insegura en los datos usados para actuar.
Agents Without Guardrails vs Blind Tool Trust
| Agents Without Guardrails | Blind Tool Trust |
|---|---|
| Problema principal: faltan límites de sistema, policy y restricciones de ejecución. | Problema principal: no hay frontera de datos entre "raw output" y "datos confiables". |
| Cuándo aparece: cuando el agente puede ejecutar acciones riesgosas sin control runtime. | Cuándo aparece: cuando tool output entra a decisiones o pasos write sin validation-gate. |
En resumen: los guardrails controlan qué puede hacer el agente, y el validation-gate controla sobre qué datos se le permite actuar.
Autoevaluación: ¿tienes este anti-pattern?
Chequeo rápido del anti-pattern Blind Tool Trust.
Marca los puntos para tu sistema y revisa el estado abajo.
Revisa tu sistema:
Progreso: 0/8
⚠ Hay señales de este anti-patrón
Intenta mover los pasos simples a un workflow y dejar el agente solo para decisiones complejas.
FAQ
Q: Si la herramienta es interna, ¿también hay que validar?
A: Sí. Servicios internos también tienen schema drift, partial failures y respuestas inconsistentes. Que el origen sea interno no elimina la necesidad de validación.
Q: ¿Qué conviene: fail-closed o safe-mode?
A: Para escenarios write riesgosos, normalmente fail-closed. Para escenarios read-only o user-facing, suele funcionar mejor safe-mode con estado degradado explícito.
Q: ¿Alcanza solo con schema validation?
A: No. También necesitas invariants (rangos, campos obligatorios, reglas de negocio), porque datos "formalmente válidos" pueden seguir siendo inseguros en la práctica.
Qué sigue
Anti-patterns relacionados:
- Write Access Default - cuando acciones write se permiten sin suficientes restricciones.
- Agents Without Guardrails - cuando al sistema le faltan políticas runtime y límites.
- Tool Calling for Everything - cuando se llaman tools sin necesidad explícita.
Qué construir en su lugar:
- Allowed Actions - cómo limitar acciones del agente con reglas de acceso explícitas.
- Tool Execution Layer - dónde centralizar validación de output y políticas de ejecución.
- Stop Conditions - cómo terminar runs de forma transparente ante datos inválidos.