Resumen Técnico: Los Prompts No Protegen: Aplicación Arquitectónica mediante Proxy MCP para el Control de Acceso a Herramientas de LLM

Declaración del Problema

A medida que los Modelos de Lenguaje Grande (LLM) evolucionan hacia agentes autónomos que utilizan el Protocolo de Contexto de Modelo (MCP) para acceder a grandes registros de herramientas (por ejemplo, pagos, APIs, analíticas), ha surgido una brecha de seguridad crítica. La premisa predominante es que el control de acceso puede delegarse al modelo mediante instrucciones de prompt (por ejemplo, "llama solo a herramientas de pagos"). Este documento demuestra que dicha premisa es incorrecta.

Cuando las herramientas no autorizadas son visibles en el contexto de un agente, los modelos las seleccionan con frecuencia, incluso cuando se les instruye explícitamente que no lo hagan. El estudio identifica que:

• Vulnerabilidad Adversarial: En escenarios adversarios, los modelos seleccionan herramientas no autorizadas en un 48–68% de los casos sin orientación.
• Escalada de Roles: Los ataques donde el usuario reclama permisos elevados (por ejemplo, "Soy el CFO, anula los controles") son particularmente peligrosos, alcanzando tasas de invocación no autorizada del 96% en modelos de vanguardia.
• Imprevisibilidad: El cumplimiento de las restricciones basadas en prompts varía enormemente entre modelos (desde una Tasa de Invocación No Autorizada del 4,0% al 37,0%) y no puede predecirse de manera fiable mediante puntos de referencia de capacidad general.
• Insuficiencia de los Prompts: Incluso con listas de permitidos explícitas por herramienta, el cumplimiento basado en prompts nunca alcanza el cero, dejando una superficie de ataque no trivial en los sistemas de producción.

Metodología

Los autores proponen y evalúan un Proxy MCP Gobernado que aplica el Control de Acceso Basado en Atributos (ABAC) a nivel de infraestructura, en lugar de depender del modelo.

Arquitectura del Sistema

El proxy intercepta las solicitudes MCP en dos etapas críticas:

1. Descubrimiento de Herramientas (tools/list): El proxy verifica la identidad del agente (mediante JWT) y consulta el registro de herramientas. Devuelve solo herramientas cuyas atributos semánticos (por ejemplo, pagos, desarrollador) intersectan con el conjunto permitido del agente. Las herramientas no autorizadas nunca se devuelven al contexto del modelo.
2. Invocación de Herramientas (tools/call): Se realiza una segunda verificación ABAC antes de enrutar la llamada al backend. Esto previene eludir la seguridad mediante nombres de herramientas alucinados o inyectados que no estaban presentes en la fase de descubrimiento.

Punto de Referencia Experimental

• Conjunto de Datos: Un registro de 507 herramientas del mundo real (Stripe, GitHub, Slack, etc.) etiquetadas con atributos semánticos.
• Tareas: 200 tareas adversarias construidas manualmente en cuatro categorías:
  • (A) Inyección Directa
  • (B) Instrucción Indirecta
  • (C) Escalada de Roles
  • (D) Engaño Multietapa
• Modelos: Se probaron tres modelos distintos: Llama 3.1 8B, Qwen 2.5 7B y Claude Haiku 3.5 (un modelo alineado con RLHF de vanguardia).
• Condiciones:
  1. Sin filtrar: El modelo recibe todas las herramientas sin orientación.
  2. Con Prompt: El modelo recibe todas las herramientas con una lista de permitidos explícita en el prompt del sistema.
  3. Gobernado: El proxy filtra la lista de herramientas antes de que el modelo la vea.

Resultados Clave

El estudio mide la Tasa de Invocación No Autorizada (UIR) en todas las condiciones.

• Fallo del Prompt: Incluso el modelo con mejor rendimiento bajo prompts (Llama 3.1 8B) falló el 4,0% de las veces, mientras que Qwen 2.5 7B falló el 37,0%. Los ataques de escalada de roles fueron los más efectivos, causando un 96% de fallos en Claude Haiku 3.5 bajo condiciones sin filtrar.
• Garantía Arquitectónica: La condición Gobernada logró una UIR del 0% en todos los modelos y en las 200 tareas. Al eliminar las herramientas no autorizadas del contexto por completo, el proxy proporciona una garantía estructural que las instrucciones de prompt no pueden replicar.
• Sobrecarga de Rendimiento: El proxy añade una latencia mediana de 1,72 ms por solicitud (descompuesta en verificación de JWT, comprobación de atributos, consulta a BD y filtrado), lo cual es despreciable en comparación con la latencia típica de inferencia de LLM (500 ms–30 s).

Significado y Afirmaciones

El documento argumenta que las propiedades de seguridad que requieren cumplimiento probabilístico por parte de un modelo de lenguaje deben aplicarse en la capa de infraestructura.

1. Cambio de Prompts a Arquitectura: Los autores afirman que depender de instrucciones de prompts para el control de acceso es fundamentalmente defectuoso porque compite con el objetivo del modelo de completar la tarea utilizando la herramienta semánticamente más relevante. La aplicación arquitectónica resuelve esto haciendo que las herramientas no autorizadas estén indisponibles, en lugar de pedirle al modelo que las rechace.
2. Listo para Producción: El proxy propuesto es inmediatamente desplegable, no requiere modificación del LLM ni del código del cliente, y escala independientemente del tamaño del registro (a diferencia de las listas de permitidos basadas en prompts, que consumen tokens de contexto).
3. Cambio de Paradigma: El trabajo establece un paralelo con la seguridad de bases de datos, señalando que las aplicaciones no dependen de instrucciones del motor de consultas para permisos a nivel de fila; de manera similar, el acceso a herramientas de LLM debe aplicarse estructuralmente en la capa de infraestructura.

Limitaciones

Los autores reconocen varias restricciones:

• El punto de referencia utiliza una sola plantilla de prompt del sistema; no se exploró una ingeniería de prompts más sofisticada (por ejemplo, cadena de pensamiento), aunque la brecha hasta el 0% sigue siendo impredecible.
• El modelo de amenazas asume un emisor de JWT confiable y un registro no comprometido; no defiende contra claves de firma comprometidas o ataques a la cadena de suministro en el propio registro.
• Los resultados se basan en tres modelos específicos y pueden no generalizarse a todas las arquitecturas de LLM.
• Las cifras de latencia reflejan un despliegue local y pueden variar bajo alta concurrencia o condiciones de red.