Uso de herramientas verificablemente seguro para agentes de LLM: STPA se encuentra con MCP

He estado leyendo la literatura sobre barandillas de seguridad (guardrails) durante un tiempo — GuardAgent, ShieldAgent, AGrail — y todos mejoran las tasas de detección mientras admiten discretamente que no pueden garantizar nada realmente. Este artículo de ICSE NIER 2026 de Doshi et al. de CMU y NC State toma un ángulo diferente: en lugar de preguntar cómo detectar comportamientos inadecuados de los agentes de forma más fiable, se preguntan cómo hacer que el comportamiento inseguro sea formalmente imposible. Es un artículo de posicionamiento, no un estudio empírico, pero el planteamiento es lo suficientemente agudo como para merecer una lectura atenta.

El artículo

"Hacia un uso de herramientas verificablemente seguro para agentes de LLM" (arXiv:2601.08012) de Aarya Doshi, Yining Hong, Congying Xu, Eunsuk Kang, Alexandros Kapravelos y Christian Kästner propone una metodología para derivar y aplicar especificaciones de seguridad sobre el uso de herramientas por parte de agentes de LLM. La observación central es que los riesgos en los sistemas de agentes surgen principalmente de la composición de herramientas — no de fallos individuales en las herramientas — por lo que las salvaguardas a nivel de componente no pueden detectarlos. Un agente que resuelve un conflicto de calendario podría consultar correctamente un registro de salud privado y enviar correctamente un correo electrónico, pero aun así hacer algo catastrófico: filtrar el contenido de ese registro a los colegas de un paciente.

La solución propuesta consta de dos partes. En primer lugar, los autores aplican el Análisis de Procesos Sistémico-Teóricos (STPA), un método de ingeniería de seguridad de los sistemas de aviación y nucleares, para identificar peligros a nivel de agente, derivar requisitos de seguridad y formalizarlos como especificaciones sobre flujos de datos y secuencias de herramientas. En segundo lugar, introducen un marco del Protocolo de Contexto de Modelo (MCP) mejorado con capacidades, donde cada herramienta debe declarar metadatos estructurados: nivel de capacidad (solo lectura, solo escritura, lectura-escritura, ejecución), clasificación de confidencialidad y nivel de confianza. La aplicación de la seguridad se estructura en cuatro niveles: lista de bloqueo automática para flujos probadamente inseguros, lista de obligaciones para secuencias requeridas, lista de permitidos para operaciones preaprobadas y escalamiento de confirmación para casos ambiguos.

El paso de verificación formal utiliza Alloy, una herramienta de lógica relacional de primer orden, para modelar el espacio de ejecución y comprobar exhaustivamente que, bajo las políticas establecidas, no pueden ocurrir violaciones de seguridad mientras las trazas seguras sigan siendo alcanzables. Este es el principal "resultado" del artículo; no hay cifras de precisión de referencia, lo cual es de esperar en un artículo corto de NIER.

Ideas clave

• El STPA replantea la seguridad de los agentes como un problema de ingeniería de sistemas: identificar pérdidas, rastrear a través de interacciones peligrosas, derivar requisitos — antes de escribir cualquier código de aplicación.
• Las especificaciones se dividen en dos tipos: restricciones de flujo de información ("los correos electrónicos de eventos no deben incluir datos privados que no pertenezcan al destinatario") y restricciones de lógica temporal ("cada update_event debe ir seguido de un send_email a cada asistente").
• La aplicación de cuatro niveles (lista de bloqueo / lista de obligaciones / lista de permitidos / confirmación) está diseñada para reducir la fatiga de seguridad — la mayoría de los flujos seguros están preaprobados, por lo que el agente no está pidiendo permiso constantemente.
• El análisis de trazas exhaustivo de Alloy confirmó la ausencia de flujos inseguros en el caso de estudio del calendario, preservando al mismo tiempo la funcionalidad de la tarea.
• Todo el enfoque se limita explícitamente a agentes específicos de tareas, no a asistentes de propósito general; los autores reconocen que los agentes especializados son más factibles de asegurar.

Qué se sostiene — y qué no

El movimiento intelectual es sólido: tomar prestado el STPA de la ingeniería de seguridad crítica es el instinto correcto. A diferencia de las barandillas probabilísticas, este enfoque convierte los requisitos en predicados sobre las trazas del sistema, que pueden ser verificados en lugar de estimados. La jerarquía de aplicación de cuatro niveles está diseñada con criterio; la distinción entre lista de bloqueo y confirmación es especialmente importante, porque las solicitudes de confirmación permanentes erosionan la confianza del usuario y acaban siendo ignoradas.

Dicho esto, las limitaciones del artículo son significativas y, en su mayoría, no se abordan. El problema de la "confianza en los metadatos" se reconoce pero no se resuelve: todo el marco depende de que los desarrolladores de herramientas etiqueten sus herramientas con precisión. En un mercado de MCP abierto donde las herramientas de terceros son comunes, no existe un mecanismo de aplicación para la corrección de las etiquetas. La verificación formal también se realiza sobre un modelo de juguete de Alloy creado a mano; demuestra la viabilidad del enfoque, no que el enfoque pueda aplicarse a sistemas reales a escala.

Tampoco veo un argumento convincente de por qué el STPA es el método de análisis de peligros adecuado frente a, por ejemplo, el modelado de amenazas o HAZOP. El caso de estudio del calendario es ilustrativo pero trivialmente pequeño. Y no hay discusión sobre proveedores de herramientas adversarios que etiqueten mal deliberadamente las capacidades, lo cual es una superficie de ataque real que examina en detalle la literatura de seguridad de MCP relacionada (arXiv:2601.17549).

El planteamiento honesto es que se trata de una propuesta de diseño con un modelo formal de prueba de concepto. El arduo trabajo de ingeniería — construir el motor de políticas, probar la cobertura de las etiquetas en diversas herramientas, medir empíricamente el equilibrio entre autonomía y seguridad — se declara como trabajo futuro.

Por qué esto es importante para la IA en finanzas

Los agentes de escritura en Beancount se enfrentan exactamente al patrón de peligro para el que está diseñado este artículo: la composición de herramientas que crea riesgos emergentes. Un agente que lee una entrada de cuenta sensible y luego publica un resumen en un libro mayor compartido podría estar haciendo algo perfectamente razonable en cada paso individual, mientras viola una restricción de confidencialidad que solo es visible a nivel de sistema. El enfoque del STPA de partir de las pérdidas de las partes interesadas e invertirlas en requisitos se ajusta perfectamente al dominio financiero, donde las pérdidas son violaciones regulatorias, divulgaciones no autorizadas y mutaciones irreversibles del libro mayor.

La extensión de MCP es directamente relevante porque las herramientas de Beancount se están envolviendo cada vez más como servidores MCP. Si esas herramientas pueden declarar su nivel de capacidad y clase de confidencialidad de una manera estructurada y legible por máquina, se vuelve posible aplicar políticas de flujo de datos en el límite del protocolo en lugar de esperar que el agente se autocontrole. Las restricciones de lógica temporal — exigir que cada post_transaction sea precedido por un balance_check exitoso — son exactamente el tipo de invariante que un agente financiero necesita garantizar antes de confirmar escrituras.

La pieza que falta, por ahora, es que nada de esto ha sido construido y probado. Pero como vocabulario de diseño para pensar en la seguridad de los agentes de libros contables, STPA + IFC es el marco más fundamentado que he visto en esta literatura.

Qué leer a continuación

• "Securing AI Agents with Information-Flow Control" — arXiv:2505.23643, Microsoft Research; implementa un sistema IFC concreto (Fides) con rastreo de contaminación (taint tracking), evaluado en AgentDojo; el complemento empírico a este artículo.
• "Breaking the Protocol: Security Analysis of the Model Context Protocol Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents" — arXiv:2601.17549; analiza directamente la superficie de ataque de MCP que el marco de este artículo pretende defender.
• "Systematic Hazard Analysis for Frontier AI using STPA" — arXiv:2506.01782; una aplicación más reciente de la metodología STPA a los sistemas de IA en general, útil para comprender cómo escala la técnica.