Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks

Resumen Técnico: Las Compuertas de Capacidad No Son Autorización

Planteamiento del Problema
El documento identifica una brecha de seguridad crítica en los marcos de trabajo (frameworks) actuales para agentes de Modelos de Lenguaje Extensos (LLM): la confusión entre el control de capacidad (capability gating) y la autorización por llamada (per-call authorization). Mientras que los marcos como LangChain, LlamaIndex y el Stripe Agent Toolkit restringen con éxito qué herramientas puede acceder un agente (control de capacidad), fallan por defecto al no validar si una llamada a una herramienta específica con valores de argumentos específicos está autorizada antes de su ejecución.

Esto crea una vulnerabilidad de dependiente confundido (confused-deputy). En este patrón, un componente privilegiado (el tiempo de ejecución del agente) es inducido por una entrada controlada por un atacante (vía inyección de prompt indirecta) a hacer un uso indebido de su autoridad. Si el tiempo de ejecución acepta una llamada a una herramienta emitida por el modelo basándose únicamente en la existencia de la herramienta y la validez de su esquema —sin verificar los valores de los argumentos concretos (por ejemplo, account=acct_ATTACKER_999) contra una política externa—, el modelo no confiable suministra efectivamente tanto la acción como el hecho de la autorización. El documento argumenta que los modelos de "nivel de despliegue" optimizados para costos son significativamente más propensos a emitir estas llamadas no autorizadas (Tasa de Intentos de Acción No Autorizada [ASR] media de 0.603) en comparación con los modelos insignia (0.189), exacerbando el riesgo.

Metodología
Los autores emplearon una metodología de tres vertientes:

1. Auditoría Transversal de Frameworks: Un análisis estático de commits públicos fijados de LangChain/LangGraph, LlamaIndex y el Stripe Agent Toolkit. La auditoría buscó específicamente un chequeo de autorización determinista y de cierre seguro (fail-closed) sobre los valores de argumentos concretos después de la emisión del modelo pero antes de la ejecución de efectos secundarios.
2. Medición de Amenazas: Un benchmark complementario que mide el ASR de 27 modelos (incluyendo variantes de nivel de despliegue y modelos insignia) bajo escenarios de inyección de prompt alineados con la tarea. El entorno utilizó accesorios (fixtures) en entornos aislados (sandboxed), sumideros no enrutables y canarios deterministas para medir la tasa de intentos de llamadas a herramientas no autorizadas sin ejecutar efectos secundarios reales.
3. Evaluación de Control: El diseño y prueba de SCOPEGATE, un control de Punto de Decisión de Política/Punto de Aplicación de Política (PDP/PEP). Los autores evaluaron SCOPEGATE frente a:
   • Una Prueba de Concepto (PoC) reproducible usando LangChain y LlamaIndex para demostrar la brecha por defecto.
   • Una suite de bypass estático de 48 vectores adversarios (incluyendo espacios en blanco, homógrafos, confusión de tipos e inyección de NaN).
   • Una simulación de atacante adaptativo (40 iteraciones) utilizando un modelo GLM-5.2.
   • Pruebas de control benignas para medir las tasas de denegación falsas.
   • Una viñeta de contención específica utilizando el modelo soberano Latam-GPT.

Contribuciones Clave

• Medición de Amenazas: El documento proporciona evidencia empírica de que los modelos de nivel de despliegue intentan acciones no autorizadas aproximadamente 3.2 veces más a menudo que los modelos insignia bajo el encuadre de inyección alineada con la tarea.
• Auditoría de Frameworks: Establece que los principales marcos de agentes incluyen control de capacidad pero carecen de una autorización por llamada, determinista y de cierre seguro para los valores de los argumentos por defecto. Esto deja la decisión de autorización al integrador en lugar de al framework.
• Control SCOPEGATE: Los autores introducen SCOPEGATE, un PDP/PEP de cinco etapas que aplica:
  1. Alcance (Scope): Deniega herramientas no listadas.
  2. Autorización: Deniega argumentos que no estén en listas de permitidos verificadas (ej. IDs de cuenta específicos).
  3. Techo de Dinero (Money Ceiling): Deniega números no finitos, NaN o montos que excedan un techo para herramientas de pago.
  4. Idempotencia: Deniega llamadas con efectos secundarios que carezcan de una clave de idempotencia confiable.
  5. Denegación por Defecto (Default Deny): Todos los errores o fallos de política resultan en denegación.
• Reproducibilidad: El documento proporciona un artefacto completo (scopegate-runtime) que permite a otros reproducir la brecha del framework y la mitigación de SCOPEGATE.

Resultados

• Hallazgos de la Auditoría: Se encontró que los tres frameworks auditados (LangChain, LlamaIndex, Stripe Agent Toolkit) carecen de una compuerta de autorización de cierre seguro por defecto para los valores de argumentos suministrados por el modelo.
• Ejecución de la PoC: En la PoC de LangChain/LlamaIndex, la solicitud de un modelo comprometido para actualizar una cuenta de pagos a un ID controlado por el atacante fue ejecutada por el despacho por defecto del framework. Cuando se enrutó a través de SCOPEGATE, la misma solicitud fue denegada en la etapa de autorización.
• Resistencia al Bypass: SCOPEGATE denegó 48/48 vectores adversarios estáticos y 29/29 intentos no autorizados en una ejecución adaptativa de 40 iteraciones.
• Controles Benignos: El sistema reportó 0/10 denegaciones falsas para llamadas benignas y autorizadas en modelos de llamada de función nativos.
• Contención: En la viñeta de pago de Latam-GPT, el modelo intentó pagos no autorizados en 10/10 ensayos; SCOPEGATE denegó los 10 intentos en la etapa de autorización.

Significancia y Reivindicaciones
El documento reclama modestamente la identificación de una "brecha por defecto" específica en las arquitecturas de agentes actuales, en lugar de descubrir nuevas técnicas de inyección de prompt o pretender resolver el problema de la inyección por completo.

• No es una Cura: Los autores declaran explícitamente que SCOPEGATE no previene la inyección de prompt, no detecta el envenenamiento de los pesos del modelo, ni garantiza salidas de lenguaje natural seguras. Es un mecanismo de contención que limita las consecuencias de un modelo comprometido.
• Distinción Operacional: La significancia central es la distinción operacional entre "exponer una herramienta" y "autorizar una llamada". El documento argumenta que confiar en los argumentos bien tipados del modelo como autoridad ejecutable es un error de diseño fundamental en los valores por defecto actuales.
• Sin CVEs: El documento afirma que no existen CVEs específicos contra los frameworks auditados, enmarcando los hallazgos como "evidencia de endurecimiento y estándares" donde el integrador es actualmente responsable de la mediación completa.
• Alcance de la Inferencia: Los hallazgos respecto al riesgo de los modelos de despliegue se basan en un barrido medido de modelos optimizados para costos adecuados para tráfico de alto volumen, no en una afirmación sobre flotas de producción de proveedores específicos.

En conclusión, el documento sostiene que para que los agentes de LLM se desplieguen de forma segura con herramientas que generan efectos secundarios, los frameworks deben ir más allá del control de capacidad para implementar verificaciones de autorización por llamada, deterministas y de cierre seguro, contra políticas externas. SCOPEGATE sirve como una implementación de referencia para este límite.