Una de las asunciones más peligrosas en el desarrollo de agentes IA es que las instrucciones explícitas en el prompt bastan para controlar su comportamiento. La realidad demostrada en múltiples evaluaciones adversariales es diferente: los modelos de lenguaje seleccionan herramientas no autorizadas incluso cuando el prompt indica claramente cuáles están prohibidas.

Este problema no es teórico. En pruebas documentadas con agentes que invocan herramientas externas mediante protocolos como el Model Context Protocol (MCP), los LLMs han ignorado restricciones textuales cuando las herramientas prohibidas aparecían listadas en el contexto disponible. La visibilidad de una herramienta en el context window se convierte, de facto, en una invitación a utilizarla — independientemente de las instrucciones.

¿Por qué fallan las instrucciones de prompt en escenarios adversariales?

La causa raíz tiene dos componentes estructurales:

Visibilidad sin control de acceso. Los sistemas actuales exponen el catálogo completo de herramientas disponibles en el prompt del modelo. Aunque el desarrollador agregue instrucciones como "nunca invoques la herramienta X", el modelo ve X en su lista de opciones. En contextos adversariales — donde un usuario intenta extraer información sensible o ejecutar acciones no autorizadas mediante jailbreaking — esta visibilidad es suficiente para que el modelo seleccione la herramienta prohibida.

Limitaciones inherentes del seguimiento de instrucciones. Investigaciones como las publicadas en arXiv sobre robustez de instrucciones en LLMs demuestran que los modelos priorizan la coherencia contextual sobre restricciones textuales cuando enfrentan prompts diseñados para confundir o contradecir las reglas iniciales. Si un usuario formula una pregunta que semánticamente "encaja" mejor con la herramienta prohibida que con las autorizadas, el modelo puede elegir la primera ignorando la restricción.

¿Cómo resolver el problema? Proxy MCP con control de acceso basado en atributos (ABAC)

La solución propuesta en el sector de seguridad de agentes es implementar un proxy intermedio entre el modelo y el servidor de herramientas MCP, con control de acceso basado en atributos (ABAC) operando en dos capas:

Capa de descubrimiento (discovery)

Cuando el agente solicita el catálogo de herramientas disponibles — la operación tools/list en MCP — el proxy filtra la respuesta según los atributos del usuario, el contexto de la sesión y las políticas de seguridad configuradas. Solo las herramientas autorizadas para ese agente específico aparecen en su contexto.

Por ejemplo: un agente con rol read-only nunca vería herramientas de escritura en base de datos en su lista disponible, eliminando la tentación desde el origen. Esta capa implementa políticas ABAC evaluando atributos como user.role, session.trust_level, tool.sensitivity, antes de devolver el catálogo filtrado.

Capa de invocación (invocation)

Incluso si una herramienta ha pasado el filtro de descubrimiento, cada invocación real — cuando el modelo llama a tools/call — atraviesa una segunda evaluación de políticas. Esto protege contra ataques de prompt injection que intenten forzar al modelo a invocar herramientas fuera de su alcance o en contextos no autorizados.

La capa de invocación puede validar parámetros, verificar tokens de sesión, aplicar rate limiting por tipo de herramienta o incluso requerir aprobación humana para operaciones críticas. Proyectos de referencia como Anthropic's MCP security guidelines recomiendan este enfoque de doble validación para entornos de producción.

Brecha crítica identificada: visibilidad compromete seguridad

El hallazgo clave de este análisis es simple pero crítico: si una herramienta es visible en el contexto del modelo, el modelo puede elegirla. Las restricciones puramente textuales en el prompt no son un mecanismo de seguridad fiable.

Esto implica que los desarrolladores deben tratar el catálogo de herramientas expuesto al agente como una superficie de ataque. Reducir esa superficie mediante filtrado en proxy — no mediante instrucciones en lenguaje natural — es la única defensa efectiva documentada hasta ahora.

Implementaciones de referencia del patrón proxy ABAC para MCP están comenzando a aparecer en repositorios especializados en Hugging Face Agents y en discusiones de la comunidad de desarrolladores MCP. Estos ejemplos muestran cómo integrar librerías de control de acceso como Open Policy Agent (OPA) con servidores MCP en Python o TypeScript.

Recomendaciones para desarrolladores de agentes

Para quienes operan agentes IA con acceso a herramientas externas:

  • Nunca confíes en el prompt como única capa de seguridad. Usa control de acceso programático antes de exponer herramientas al modelo.
  • Implementa filtrado de catálogo por sesión. Cada agente debe ver solo las herramientas que está autorizado a usar según su rol y contexto.
  • Valida en dos capas. Descubrimiento y ejecución deben tener políticas de acceso independientes.
  • Audita invocaciones. Registra qué herramientas se invocan, por qué agente y bajo qué contexto, para detectar patrones anómalos.

La arquitectura de agentes seguros requiere tratar al modelo como un componente no confiable desde la perspectiva de seguridad — capaz de producir valor pero incapaz de auto-gobernarse mediante instrucciones textuales cuando enfrenta adversarios. El control debe estar en las capas externas al LLM, no dentro de su prompt.