Prompt injection y agentes de IA: el problema es arquitectónico, qué propone CaMeL
Hay una diferencia sutil, a menudo pasada por alto en las presentaciones pulidas de los productos de IA, entre un modelo que responde y un agente que actúa. El primero procesa texto y devuelve texto; el segundo lee el correo, abre documentos, navega por páginas web, llama a API de pago, escribe código en el repositorio corporativo. Este salto, de "generador de frases" a "ejecutor de tareas", es la razón por la que en 2026 la seguridad de los agentes de IA se ha convertido en un tema de sala de juntas.
Gartner lo puso negro sobre blanco el pasado 9 de junio, colocando la prompt injection en primer lugar entre las amenazas de IA por segundo año consecutivo. El motivo es casi banal de enunciar, complejo de resolver: los agentes multiplican los puntos en los que un texto puede transformarse en un comando. Un correo electrónico, un PDF adjunto, una reseña en un sitio de viajes, incluso un archivo README en GitHub se convierten en vehículos potenciales de instrucciones que el usuario nunca ha escrito, ni aprobado.
La idea clave, antes de los detalles técnicos, es esta: cuanto más operativo se vuelve un sistema de IA, más se necesitan las mismas precauciones que el software crítico aplica desde hace décadas: separación de privilegios, verificación de inputs, trazabilidad de las acciones. Es la misma lección que la informática aprendió con las bases de datos (la inyección SQL) y con la web (el cross-site scripting), aplicada a un dominio nuevo donde el atacante no escribe código, escribe frases en lenguaje natural.
El riesgo oculto en los datos
La definición técnica, según el Top 10 de OWASP para aplicaciones basadas en LLM, distingue dos variantes principales. La inyección directa es el intento explícito, el usuario que escribe "ignora las instrucciones anteriores y haz X": un ataque fácil de imaginar, relativamente sencillo de filtrar. La inyección indirecta es más insidiosa, porque el texto malicioso no llega del usuario, llega de un contenido externo que el agente procesa en el desarrollo normal de su trabajo: un documento compartido, una página web, el campo de notas de un ticket.
El punto, explican los investigadores del paper CaMeL que analizaremos en breve, es que el problema no concierne solo al modelo de lenguaje, concierne a todo el sistema que lo rodea: el contexto que recibe, las herramientas a las que puede acceder, los privilegios con los que opera, los outputs que produce. Un modelo, por muy bien alineado que esté, recibe en su entrada una secuencia de tokens indistinguibles por su procedencia, como ha reconstruido ICT Security Magazine analizando el caso EchoLeak: al modelo no le importa si ese texto llega del prompt de sistema del desarrollador o de un correo recibido una hora antes, todo acaba en la misma ventana de contexto, con el mismo nivel de confianza implícita.
Un ejemplo sencillo ayuda a fijar la idea. Un agente que debe resumir un correo electrónico podría tropezar con un texto oculto, tal vez escrito con caracteres invisibles o formateado para parecer parte del contenido legítimo, que lo instruye a reenviar información confidencial a una dirección externa. El usuario solo pidió un resumen, el agente ejecuta también el comando oculto, porque para él no existe ninguna diferencia semántica entre "lo que el usuario quiere" y "lo que el documento dice que haga".
Por qué los agentes cambian las reglas
Los chatbots tradicionales, los que se limitan a conversar, contienen el daño potencial dentro de los límites de la propia conversación: en el peor de los casos devuelven una respuesta embarazante o falsa. Los agentes no. Tienen acceso a herramientas reales, a menudo con privilegios amplios, y esto cambia la naturaleza del riesgo de "output incorrecto" a "acción dañosa e irreversible". IBM lo describe bien: la combinación entre proceso de toma de decisiones automatizado y capacidad de llamar a herramientas externas crea una superficie de ataque en dos frentes; los agresores pueden manipular el comportamiento del agente induciéndolo a un uso impropio de las herramientas, o golpear directamente la herramienta con vectores más clásicos como la inyección SQL.
A esto se suma un problema de observabilidad. Un modelo de lenguaje, por su naturaleza, produce inferencias probabilísticas, no un algoritmo determinista e ispeccionable línea por línea. Esto hace impredecible, al menos en parte, qué hará el agente ante un input nunca visto antes, complicando enormemente el trabajo de los equipos que deben monitorizar y responder a los incidentes.
El riesgo crece en proporción a tres factores que se combinan, no individualmente: el acceso a datos privados, la exposición a contenidos no confiables y la disponibilidad de un canal hacia el exterior para filtrar información. Cuando un agente posee los tres juntos —lee datos sensibles, procesa texto que no controla, puede contactar con sistemas externos— la superficie se vuelve estructuralmente vulnerable, independientemente de lo sofisticado que sea el prompt de sistema que lo instruye a comportarse bien. Por ello, la seguridad debe diseñarse como arquitectura del sistema, no confiarse a un filtro aplicado al prompt.
El caso más citado de 2025 ilustra perfectamente la dinámica. Microsoft corrigió en silencio, en el Patch Tuesday de junio, una vulnerabilidad crítica en Microsoft 365 Copilot, conocida como EchoLeak (CVE-2025-32711, puntuación CVSS 9.3), que permitía la exfiltración de datos sin ningún clic por parte de la víctima: bastaba con un correo formateado con arte, procesado meses después por Copilot durante una petición de trabajo totalmente ordinaria, para desencadenar la fuga de información hacia un dominio externo enmascarado como endpoint confiable. Sin malware, sin clics en enlaces, solo texto interpretado de manera equivocada.
Qué propone CaMeL
En junio de 2025, un grupo de investigadores de Google DeepMind y de la Escuela Politécnica Federal de Zúrich (ETH) publicó un paper, titulado "Defeating Prompt Injections by Design", que propone un enfoque diferente respecto a los intentos anteriores de hacer que el modelo mismo fuera más robusto. CaMeL, acrónimo de CApabilities for MachinE Learning, no modifica el modelo; construye una capa protectora de sistema a su alrededor, inspirándose en conceptos ya consolidados en la seguridad informática tradicional, como la integridad del flujo de control y el control de accesos.
La intuición de partida retoma una idea propuesta en 2023 por el desarrollador Simon Willison, el patrón "Dual LLM": un modelo Privilegiado, que solo ve la petición original del usuario y planifica las acciones, y un modelo Cuarentenado, desprovisto de capacidades de llamar a herramientas, que procesa los contenidos no confiables (correos, documentos, páginas web). La idea, elegante sobre el papel, muestra sin embargo un límite: incluso aislando la planificación de los datos sucios, un agresor puede de todos modos manipular los argumentos pasados a las herramientas, desviando el flujo de datos sin tocar la secuencia de las acciones planificadas; el equivalente agéntico de una inyección SQL, que no altera la estructura de la consulta, sino que solo corrompe sus parámetros.
CaMeL supera este límite extrayendo explícitamente, de la petición del usuario (que se asume confiable), tanto el flujo de control como el flujo de datos, en forma de código Python generado por el modelo Privilegiado y ejecutado por un intérprete personalizado. De este modo, los datos recuperados de fuentes no confiables no pueden influir nunca en la ruta lógica de la ejecución, solo en su contenido, y solo dentro de los límites impuestos por reglas explícitas.
Capability, policy, flujos controlados
El corazón técnico del sistema se basa en un concepto tomado de la seguridad de los sistemas operativos, el de capability: una etiqueta de metadatos asociada a cada valor que atraviesa el programa, capaz de registrar su procedencia y los destinatarios autorizados. Cuando el agente recupera un archivo de un almacenamiento en la nube, ese archivo lleva consigo la información sobre quién lo ha compartido y quién puede leerlo, un poco como un paquete que llega con su propio albarán de entrega adjunto. Si más adelante el código generado por el modelo intenta enviar ese archivo a una dirección de correo no autorizada, el intérprete bloquea la operación antes de que se ejecute, solicitando eventualmente confirmación explícita al usuario.
Junto a las capabilities operan las security policies, funciones escritas en Python que definen qué está permitido hacer con determinados datos, controladas en cada llamada de una herramienta. En el paper se muestra un ejemplo relativo a la creación de eventos en el calendario: título, descripción, lugar y horario deben ser legibles por todos los participantes, a menos que estos últimos provengan directamente de una instrucción confiable del usuario. La granularidad es tal que permite lógicas tan complejas como sea necesario, evitando tanto el exceso de restricción (que degrada la utilidad del agente) como el exceso de permisividad (que vuelve a abrir la puerta a los ataques).
Las cifras de la evaluación, realizada en el benchmark AgentDojo, son instructivas. Con Claude 4 Sonnet y modelos comparables, CaMeL reduce los ataques exitosos prácticamente a cero, frente a cientos de éxitos obtenidos contra la misma suite de modelos usados con las API de tool-calling nativas, pagando un coste en términos de utilidad (el porcentaje de tareas legítimas completadas con éxito) que varía según el dominio, marcado sobre todo en las tareas más ambiguas o menos documentadas, contenido en otras partes. El precio computacional ronda un factor de 2,8 veces más tokens, tanto en entrada como en salida, en comparación con el tool-calling nativo: un coste real, sostenible según los autores considerando las garantías obtenidas.
Nota técnica: CaMeL también aborda el tema de los side-channels, por ejemplo la posibilidad de inferir un dato privado observando indirectamente cuántas veces se ejecuta una determinada llamada condicionada por su valor. Un problema que el paper reconoce como irresoluto, comparándolo con las técnicas de return-oriented programming que aún hoy eluden parcialmente el Control Flow Integrity en los sistemas tradicionales.
Gobernanza: la confianza no basta
Para quienes os ocupáis de cumplimiento, seguridad empresarial o administración pública, el discurso técnico se traduce en una pregunta más sencilla: cómo hacer que un agente sea no solo preciso, sino también controlable, verificable y auditable. Microsoft, en su guía arquitectónica para agentes, identifica tres pilares fundamentales para un desarrollo responsable: la idoneidad para el propósito, la operatividad confiable a lo largo del tiempo y un tercer pilar que resume la esencia del problema: confianza, trazabilidad y transparencia; es decir, la posibilidad concreta para usuarios y administradores de saber dónde residen los datos, cómo se utilizan y verificar la procedencia de cada información mostrada por el sistema.
Aquí entra en juego un detalle que hace a CaMeL interesante más allá del perímetro de la seguridad pura: el grafo de los flujos de datos que el intérprete construye durante la ejecución puede ser reutilizado en la interfaz de usuario para mostrar el origen de un contenido, permitiendo a quien lee darse cuenta, por ejemplo, de que un presunto mensaje "de Google" proviene en realidad de una fuente no verificada. Trazabilidad, por tanto, no como un trámite burocrático, sino como una herramienta real de defensa contra el phishing transmitido por el propio agente.
El marco normativo se está moviendo rápidamente. El AI Act europeo, en su artículo 15, impone a los sistemas de alto riesgo (bancos, sanidad, infraestructuras críticas) demostrar robustez frente a los intentos de alteración por parte de terceros no autorizados, con sanciones de hasta el 7% de la facturación global, con vigencia a partir de agosto de 2026. En Italia se añaden la directiva NIS2, vigente desde enero, y las directrices de la ACN de febrero, con una evaluación específica sobre la prompt injection para la administración pública: tres regímenes superpuestos que transforman cada incidente en un problema legal antes incluso que técnico.
Dónde funciona y dónde no
Los puntos fuertes de CaMeL, releídos a la luz de los datos del paper, son concretos: reduce drásticamente la confianza ciega depositada en el texto externo, introduce una barrera arquitectónica verificable en lugar de una enésima instrucción en el prompt y aborda el problema de raíz en lugar de filtrar sus síntomas. En comparación con otras defensas disponibles en AgentDojo (filtros de herramientas, spotlighting, prompt sandwiching), CaMeL prácticamente reduce a cero los ataques exitosos, mientras que las alternativas dejan pasar de cinco a veinticuatro de cada 949 intentos probados.
Los límites, igualmente concretos, merecen el mismo peso. El coste de implementación es alto: construir un sistema basado en capabilities requiere un cambio de paradigma, no un plugin que instalar, y funciona bien solo si todo el ecosistema de herramientas colabora, una restricción que se complica en cuanto el agente debe interactuar con servicios de terceros fuera del control directo de los desarrolladores. Existe además el riesgo, bien conocido por quienes trabajan con sistemas de permisos granulares, de la "fatiga de autorización": si las solicitudes de confirmación se multiplican, el usuario corre el riesgo de aprobar mecánicamente incluso acciones peligrosas, anulando parte del beneficio.
Los mismos autores son explícitos en un punto que merece ser repetido sin rodeos: la prompt injection no está "resuelta". CaMeL no protege, por admisión explícita, contra ataques que solo alteran el texto mostrado al usuario sin tocar el flujo de datos —como un resumen distorsionado de un correo que no causa exfiltración—, ni contra el phishing inducido cuando este permanece confinado al nivel del lenguaje. Queda además abierto el frente de los side-channels, canales laterales difíciles de cerrar por completo incluso en el software tradicional.
El estado del arte en 2026
El caso CaMeL se inserta en un panorama de incidentes reales que confirman su urgencia. Además de EchoLeak, 2025 vio una vulnerabilidad de remote code execution en GitHub Copilot y Visual Studio Code (CVE-2025-53773), capaz de propagarse entre repositorios como un gusano explotando archivos README aparentemente inofensivos, y un ataque en ServiceNow Now Assist donde un usuario con pocos privilegios inducía, mediante un campo de ticket, a un agente con privilegios más altos a realizar acciones no autorizadas, explotando la confianza implícita entre agentes de la misma plataforma.
El caso más grave, reconstruido por Anthropic en un informe público y recogido por la prensa especializada, describe una campaña de espionaje atribuida a un grupo patrocinado por un estado, que comprometió una configuración agéntica descomponiendo el ataque en una secuencia de peticiones pequeñas y aparentemente legítimas, convenciendo al modelo de estar ejecutando un penetration test autorizado. Un fragmento que recuerda de cerca la lógica del "snow crash" imaginado por Neal Stephenson en su novela de 1992: un virus que se propaga explotando no un error en el código, sino la disposición del sistema a ejecutar ciegamente lo que se le muestra.
La OWASP, en la revisión dedicada a las aplicaciones agénticas de diciembre de 2025, añadió subcategorías específicas, como la inyección mediante abuso de las herramientas y la inyección de manera persistente en la memoria del agente: categorías impensables en la era de los chatbots aislados, centrales ahora que el LLM actúa como orquestador de sistemas interconectados. Cisco estima que el 83% de las organizaciones planea adoptar sistemas agénticos, mientras que solo el 29% se declara preparado para protegerlos adecuadamente, una brecha que recuerda, para quienes tenéis familiaridad con ciertos juegos de survival horror, a la sensación de avanzar por un pasillo oscuro con más munición que cerraduras.
Construir el entorno, no solo el modelo
El problema, resumido sin tecnicismos, no es "defender el prompt", es diseñar sistemas capaces de distinguir con claridad instrucciones, datos y acciones, un poco como un buen juego de verificación burocrática enseña a distinguir el documento auténtico del falsificado, no confiando nunca en la apariencia superficial. CaMeL, con todos sus límites declarados, sigue siendo útil como caso de estudio precisamente porque señala una dirección más madura para el sector: seguridad incorporada en el diseño del sistema, no delegada a la esperanza de que el modelo se comporte bien.
Para el público que no implementa directamente estos sistemas, sino que los adopta, los financia o los regula, la traducción práctica es esta: no basta con enseñar al modelo a comportarse bien, hay que construir el entorno en el que opera, con privilegios mínimos, trazabilidad completa y confirmación humana para las acciones irreversibles. Una lección tan vieja como la propia informática, redescubierta cada vez que una nueva tecnología promete simplificarlo todo y acaba proponiendo los mismos problemas con un vocabulario diferente.