PulseFlow Tecnologia
← Insights
·7 min de lectura·guia-tecnica·guardrails·tool-use·autorizacion
PulseFlow Tecnologia

Cómo crear guardrails para el uso de herramientas en agentes

Una investigación académica reciente encontró algo incómodo en tres de los frameworks de agentes más usados del mercado - LangChain, LlamaIndex y Stripe Agent Toolkit: todos "conflate tool exposure with authorization". Es decir, exponer una herramienta al modelo no significa, por defecto, que cada llamada individual esté autorizada con valores específicos antes de ejecutarse. En la práctica, los investigadores demostraron una llamada de pago no autorizada ejecutándose bajo el dispatch por defecto de LangChain - el clásico problema del "confused deputy", ahora en agentes de IA.

Una lista de herramientas permitidas no es lo mismo que autorización por llamada

El error común es confundir "la herramienta está en la lista de tools disponibles" con "esta llamada específica está autorizada". Los tres frameworks auditados ofrecen capability gating por defecto - decidir qué herramientas existen —, pero ninguno ofrece, por defecto, un gate determinístico de autorización por valor y por llamada, fail-closed.

Riesgo por herramienta: no toda tool necesita el mismo guardrail

Una herramienta de solo lectura tiene un perfil de riesgo completamente distinto al de una que mueve dinero, elimina un registro, o envía comunicación externa. Guardrails proporcionales al riesgo de cada herramienta - no un guardrail genérico aplicado por igual a todo - es lo que evita tanto el exceso de fricción en herramientas de bajo riesgo como el exceso de exposición en las críticas.

ScopeGate: el mecanismo de cinco etapas que eliminó los bypasses

La respuesta que proponen los propios investigadores, ScopeGate, estructura el guardrail en cinco etapas: alcance (qué puede hacer la herramienta), autorización (quién/qué aprobó esta llamada específica), límite monetario (valor máximo por llamada), idempotencia (la misma llamada no se ejecuta dos veces por error), y denegación por defecto (fail-closed cuando algo no está explícitamente permitido). Probado contra 48 intentos estáticos de bypass y 29 intentos adaptativos a lo largo de 40 iteraciones, el resultado fue cero éxitos en ambos casos - con contención de 10 sobre 10 en un agente de pagos, y cero falsos positivos en casos legítimos.

Validación de argumentos como parte del gate, no como etapa separada

Autorizar la herramienta correcta con el argumento equivocado sigue siendo una falla. El gate de autorización por llamada necesita validar no solo si la herramienta puede invocarse, sino si los valores específicos de esa llamada (monto, destinatario, alcance del dato) están dentro de lo permitido.

Entornos aislados, registros, alertas y revocación

Cada llamada a herramienta debería correr en un entorno lo bastante aislado como para contener el daño si algo pasa el gate. Los registros de cada tool call - no solo errores, todas las llamadas - permiten auditar después del hecho. Las alertas para patrones fuera de lo esperado (volumen anormal, valores fuera de rango) complementan el gate determinístico con detección de anomalías. Y la revocación de acceso - la capacidad de apagar una herramienta o credencial de inmediato cuando se identifica un incidente - cierra el ciclo.

Checklist de guardrails

  1. Lista de tools permitidas - capability gating, el punto de partida, no el final
  2. Riesgo por tool - guardrail proporcional, no genérico
  3. Validación de argumentos - parte del gate de autorización, no etapa separada
  4. Política de aprobación - quién/qué autoriza cada llamada
  5. Default deny - fail-closed cuando no está explícitamente permitido
  6. Límites financieros - valor máximo por llamada, no solo por día
  7. Entornos aislados - contener el daño si el gate falla
  8. Registros de tool calls - cada llamada, no solo errores
  9. Alertas - anomalías de volumen o valor
  10. Revocación de acceso - apagar rápido cuando sea necesario

Fuentes