El 5 de abril de 2026, Google DeepMind publicó el mayor estudio empírico sobre manipulación de agentes de IA jamás realizado: 502 participantes reales en 8 países, 23 tipos de ataque distintos y modelos de frontera como GPT-4o, Claude y Gemini. La única frase que extraje del estudio y fijé en mis notas de ingeniería a la mañana siguiente es la única que importa para quienes despliegan un chatbot empresarial en 2026: si su agente de IA lee texto controlado por un atacante y luego ejecuta acciones con privilegios de usuario, ha construido una vulnerabilidad de exfiltración de datos. Por eso webvise no construirá, para ningún cliente ni a ningún precio, un agente de IA que navegue por la web abierta.
Qué midió realmente DeepMind
La mayor parte de la cobertura periodística del estudio destacó el número titular, 23 tipos de ataque, y no fue más allá. Las cifras que subyacen son las que importan para cualquiera que opere una función de IA en producción:
- 502 participantes en condiciones reales, no en entornos de laboratorio simulados
- 8 países, de modo que los ataques no estaban optimizados para un único contexto cultural o lingüístico
- 23 tipos de ataque en 10 categorías, incluidas inyección directa de instrucciones, inyección indirecta a través de contenido web, inyección de píxeles multimodal, inyección de documentos, manipulación del entorno, inserción de jailbreaks, envenenamiento de memoria, secuestro de objetivos, exfiltración e inyección entre agentes
- Las cuatro familias de defensa (saneamiento de entrada, guardas a nivel de instrucción, sandboxing y supervisión humana) se calificaron como insuficientes a escala
La categoría a la que vuelvo una y otra vez es la octava, *el secuestro de objetivos mediante deriva gradual de instrucciones a lo largo de interacciones.* Cualquier demostración de un sistema de agentes que haya visto sobrevive a un único prompt adversarial. Ninguna sobrevive a cien prompts cuidadosamente espaciados.
El hallazgo en cascada que la mayoría de la cobertura pasó por alto
Enterrado en el estudio se encuentra el hallazgo que determina si los productos multiagente son seguros para desplegar. En cualquier pipeline donde el agente A recupera contenido, el agente B lo procesa y el agente C ejecuta una acción, una única inyección en el flujo de datos del agente A se propaga a través de todos los agentes posteriores. El agente B confía en la salida de A. El agente C confía en la salida de B. El atacante no necesitó comprometer el modelo, solo los datos que el modelo consumía, una sola vez.
Gestiono una configuración multiagente personal con Hermes, un agente de NousResearch en Telegram que gestiona 14 cron jobs relativos a noticias diarias, resúmenes de directrices médicas y logística personal. Cada uno de esos 14 trabajos lee de una fuente explícitamente confiable y curada a mano. Ninguno sigue enlaces. Ninguno ejecuta instrucciones externas. Tras la publicación del artículo de DeepMind, audité cada cron y la regla se mantuvo. Se mantuvo porque fue redactada hace dos años y jamás se relajó. La mayoría de los stacks de agentes en producción que veo en los proyectos de clientes no tienen esta regla, y los ingenieros que los construyen nunca han tenido que plasmarla por escrito.
Qué significa «leer la web abierta» en un proyecto de cliente
La misma solicitud aparece en tres variantes, cada mes:
- «Que el chatbot responda preguntas navegando por el sitio web de mi competidor.» En la práctica, esto concedería a cualquier atacante que controle una página web visitada por el agente un canal de escritura directo en la sesión del cliente.
- «Permite que los usuarios peguen cualquier URL y que el agente la resuma.» En la práctica, cualquier usuario podría pegar una URL cuyo HTML contiene instrucciones ocultas que exfiltran los mensajes siguientes de la conversación.
- «Añade RAG sobre la documentación de un proveedor externo que no alojamos.» En la práctica, esto delega los permisos de llamada de herramientas del agente a quien edite una página de documentación en el sitio del proveedor.
Cada una de ellas conecta un canal de texto controlado por un atacante directamente con un sistema que tiene datos de usuario, llamadas a herramientas y acceso de red saliente en el mismo lado del perímetro de confianza. Ninguna es maliciosa por parte del cliente. Todas son ideas de producto defendibles. Y todas, después del 5 de abril de 2026, son indesplazables.
Todas las defensas disponibles fallan
DeepMind evaluó las cuatro familias de defensa más obvias. Su valoración, con mi comentario sobre cada una:
| Defensa | Veredicto de DeepMind | Por qué falla en la práctica |
|---|---|---|
| Saneamiento de entrada | Insuficiente | No es posible sanear píxeles de imagen, metadatos de documentos o notas del ponente dentro de un PDF en tiempo de inferencia. La superficie de ataque es el texto y cualquier otra modalidad que ingiere el agente. |
| Guardas a nivel de instrucción | Insuficiente | El contenido inyectado está diseñado para parecer una parte legítima de la página. Para cuando el modelo lo ve, la guarda ya ha confiado en él. |
| Sandboxing | Reduce el radio de explosión, no previene la inyección | El sandboxing ayuda si el resultado del ataque queda contenido. No ayuda cuando el objetivo del ataque es leer datos de usuario y escribirlos de vuelta a través de una llamada a la API de apariencia legítima. |
| Supervisión humana | Insuficiente a escala | Un operador que gestiona un agente sobre 50 fuentes no puede revisar cada página en busca de instrucciones ocultas. El punto de tener un agente era precisamente que el humano salía del bucle. |
Si se toma la tabla en serio, no existe una forma responsable de desplegar un agente que lea texto controlado por un atacante y también ejecute acciones con privilegios de usuario. El único movimiento disponible es eliminar una de esas dos propiedades.
Qué despliego en su lugar
webvise ha desplegado funciones de IA en producción para clientes, incluida una landing page de construcción cuyas llamadas al modelo se enrutan a través de Vercel AI Gateway para la selección de proveedor y la observabilidad. Las cinco reglas siguientes son las que hicieron ese despliegue defendible, y son ahora precondiciones irrenunciables para cualquier proyecto de IA:
- Solo agentes de entrada cerrada. El agente lee de un conjunto finito de fuentes curadas a mano y bajo control directo. Sin web abierta. Sin URLs pegadas por el usuario. Sin RAG externo sobre documentación no controlada.
- Solo lectura por defecto. Si el agente debe leer algo que no es completamente confiable, no puede llamar a herramientas, enviar correo, escribir en una base de datos ni generar solicitudes de red salientes en la misma sesión. Se elige una capacidad u otra, nunca ambas a la vez.
- Aislamiento entre agentes. Cuando la salida del agente A fluye hacia el agente B, B trata esa salida como entrada de usuario, no como instrucciones del sistema. Es una línea de código en el prompt y constituye la defensa completa contra el ataque en cascada.
- Presupuestos de capacidad por agente. Cada agente tiene una lista fija de herramientas y un límite de tokens suficientemente reducido para que incluso una inyección exitosa no pueda exfiltrar más de un mensaje corto.
- Aislamiento de proveedores a través de un gateway. Todas las llamadas al modelo se enrutan a través de Vercel AI Gateway para poder cambiar de proveedor, registrar cada prompt y cada respuesta, y revocar una clave en segundos. Si algo parece anómalo en los registros, es posible detener el daño el mismo minuto en que se detecta.
Nada de esto es exótico. Cuesta unas pocas horas de diseño, antes de escribir una sola línea de código. Si la mayoría de los productos con agentes en 2026 no lo tienen, es porque el equipo nunca asignó a nadie la tarea de trazar el perímetro de confianza.
Por qué declino ciertos proyectos
Sería fácil leer este artículo como si un estudio dijera que es demasiado cauteloso para aceptar su dinero. Lo contrario es cierto. El artículo de DeepMind otorga a cualquier equipo que haya construido credibilidad de ingeniería antes del auge de los agentes una ventaja clara: la capacidad de declinar solicitudes de funcionalidades específicas con una justificación técnica sólida, algo que los clientes generalmente agradecen a posteriori. Los proveedores que construyen agentes sin estas restricciones asumen un riesgo de exfiltración significativo, cada vez más visible en los informes de incidentes.
La misma oportunidad que existe ahora en el marketing de contenidos existe en la ingeniería de agentes. El mercado está viendo el despliegue acelerado de chatbots sin defensas contra inyección de instrucciones, similar al reciente auge de contenido de baja calidad generado por LLMs. La prima irá a los equipos que puedan demostrar, de antemano, que el suyo está construido con un estándar más alto.
Dónde trazo la línea
La versión más breve de la regla, la que ahora escribo en cada documento de inicio de proyecto, es esta: un agente puede leer contenido no confiable, o puede actuar con privilegios de usuario, pero no en la misma sesión. Todo lo demás se deriva de ahí. Si una solicitud de funcionalidad cruza esa línea, no se construye. Si puede reformularse para mantenerse en un solo lado, se reformula junto con el cliente y se despliega la versión reformulada. El artículo de DeepMind no inventó esta disciplina, solo eliminó cualquier excusa para no tenerla.
webvise construye funciones de IA para empresas donde el coste de un único mensaje de cliente filtrado es mayor que el coste de rechazar una solicitud de funcionalidad. Si eso describe su proyecto, póngase en contacto: el primer paso es trazar juntos el perímetro de confianza, antes de escribir ningún código.
Las prácticas de webvise están alineadas con las normas ISO 27001 e ISO 42001.