Por qué no publicamos agentes de IA que lean la web abierta
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, 8 países, 23 tipos de ataque, y todas las defensas disponibles calificadas como insuficientes. Esta es la posición de ingeniería que Webvise adoptó a la mañana siguiente.
Temas
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, modelos frontier como GPT-4o, Claude y Gemini. La única frase que extrajimos y fijamos en nuestro canal de ingeniería a la mañana siguiente es la única que importa para cualquiera que esté desplegando un chatbot empresarial en 2026: si su agente de IA lee texto controlado por un atacante y luego realiza cualquier acción con privilegios de usuario, ya ha desplegado una vulnerabilidad de exfiltración de datos. Por eso webvise no construirá, para ningún cliente a ningún precio, un agente de IA que navegue por la web abierta.
Qué midió realmente DeepMind
La mayoría de la cobertura de prensa del estudio reportó el número titular, 23 tipos de ataque, y siguió adelante. Los datos subyacentes son los que importan para cualquiera que opere una funcionalidad de IA en producción:
- 502 participantes en condiciones reales, no en ejecuciones de laboratorio simuladas
- 8 países, por lo que los ataques no estaban optimizados para un contexto cultural o lingüístico concreto
- 23 tipos de ataque en 10 categorías, incluyendo prompt injection directo, 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 jailbreak, envenenamiento de memoria, secuestro de objetivos, exfiltración e inyección entre agentes
- Las cuatro clases de defensa (sanitización de entradas, guardias a nivel de prompt, sandboxing y supervisión humana) calificadas como insuficientes a escala
La categoría a la que seguimos volviendo es la octava, *secuestro de objetivos mediante deriva gradual de instrucciones a lo largo de las interacciones.* Cada demo de un sistema de agentes que usted haya visto sobrevive a un único prompt adversarial. Ninguna sobrevive a cien cuidadosamente espaciados.
El hallazgo en cascada que la mayoría de la cobertura ignoró
Enterrado en el estudio está el hallazgo que determina si los productos multiagente son seguros de 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 feed de datos del agente A se propaga a través de todos los agentes posteriores. El agente B confía en el output del agente A. El agente C confía en el output del agente B. El atacante no necesitó comprometer el modelo. Solo necesitó comprometer los datos que el modelo consumía, una sola vez.
Operamos un sistema multiagente interno llamado Hermes, un agente NousResearch en Telegram que gestiona 14 cron jobs para noticias diarias, resúmenes de guías médicas y logística personal. Cada uno de esos 14 trabajos lee de una fuente que confiamos explícitamente y hemos curado a mano. Ninguno sigue enlaces. Ninguno ejecuta instrucciones externas. Después de que el paper de DeepMind salió auditamos cada cron y la regla se mantuvo. Se mantuvo porque la escribimos hace dos años y nos negamos a relajarla. La mayoría de los sistemas de agentes en producción que vemos en los briefs de clientes no tienen esta regla, y los ingenieros que los construyen nunca han tenido que escribirla.
Qué significa 'leer la web abierta' en un brief de cliente
Vemos tres variantes de la misma solicitud cada mes:
- 'Haga que el chatbot responda preguntas navegando por el sitio de mi competidor.' Traducción: por favor, déle a un atacante que controla una entrada de blog de la competencia un canal de escritura hacia la sesión de nuestro cliente.
- 'Permita que los usuarios peguen cualquier URL y el agente la resuma.' Traducción: por favor, permita que cualquier usuario, en cualquier lugar, pegue una URL cuyo HTML contenga instrucciones ocultas que exfiltren los próximos diez mensajes de la conversación.
- 'Añada RAG sobre la documentación de un proveedor externo que no alojamos nosotros.' Traducción: por favor, otorgue los permisos de llamada a herramientas de nuestro agente a cualquier becario de marketing del proveedor que edite una página de documentación.
Cada una conecta directamente un canal de texto controlado por un atacante con un sistema que tiene datos de usuario, llamadas a herramientas y acceso de red saliente en el mismo lado del límite de confianza. Ninguna es maliciosa por parte del cliente. Todas son ideas de producto defendibles. También todas son, después del 5 de abril de 2026, imposibles de desplegar.
Todas las defensas disponibles fallan
DeepMind probó las cuatro familias de defensa obvias. Esta es su evaluación, con nuestro comentario sobre cada una:
| Defensa | Veredicto de DeepMind | Por qué falla en la práctica |
|---|---|---|
| Sanitización de entradas | Insuficiente | No es posible sanitizar píxeles de imágenes, metadatos de documentos o notas del presentador dentro de un PDF en tiempo de inferencia. La superficie de ataque es el texto y cualquier otra modalidad que el agente ingiere. |
| Guardias a nivel de prompt | Insuficiente | El contenido inyectado está diseñado para parecer una parte legítima de la página. Cuando el modelo lo ve, la guardia ya lo ha confiado. |
| Sandboxing | Reduce el radio de daño, 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 API de apariencia legítima. |
| Supervisión humana | Insuficiente a escala | Un operador que ejecuta un agente sobre 50 fuentes no puede revisar cada página en busca de instrucciones ocultas. El objetivo del agente era precisamente que el humano saliera del bucle. |
Si usted toma la tabla en serio, no existe una forma responsable de desplegar un agente que lea texto controlado por un atacante y también realice acciones con privilegios de usuario. El único movimiento disponible es eliminar una de esas dos propiedades.
Qué desplegamos en su lugar
Webvise ha desplegado funcionalidades de IA en producción para clientes, incluyendo la landing page de construcción de MP Bau, que enruta sus llamadas a modelos a través del Vercel AI Gateway para la selección de proveedores y la observabilidad. Las cinco reglas siguientes son las que hicieron ese proyecto defendible, y ahora son condiciones previas obligatorias para cualquier trabajo de IA que asumamos:
- Agentes solo de entrada cerrada. El agente lee de un conjunto finito y curado a mano de fuentes que controlamos. Sin web abierta. Sin URLs pegadas por usuarios. Sin RAG externo sobre documentación no controlada.
- Solo lectura por defecto. Si el agente debe leer algo en lo que no confiamos plenamente, tampoco puede llamar herramientas, enviar correos, escribir en una base de datos o generar solicitudes de red salientes en la misma sesión. Se elige una opción o la otra, nunca ambas a la vez.
- Aislamiento entre agentes. Cuando el output del agente A fluye hacia el agente B, B trata el output de A como entrada de usuario, no como instrucciones del sistema. Esto es una línea de código en el prompt y es 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. El límite es lo suficientemente pequeño 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. Enrutamos cada llamada a modelos a través del Vercel AI Gateway para poder cambiar de proveedor, registrar cada prompt y completado, y revocar una clave en segundos. Si algo parece incorrecto en los registros podemos detener el daño en el mismo minuto en que lo detectamos.
Nada de esto es exótico. Cuesta unas pocas horas de trabajo de diseño, antes de escribir cualquier código. La razón por la que la mayoría de los productos de agentes en 2026 no lo tienen es que nadie en el equipo fue contratado para trazar el límite de confianza.
Esta es una posición comercial, no una demostración de humildad
Sería fácil leer este artículo como una agencia diciendo *somos demasiado cautelosos para aceptar su dinero.* Lo contrario es cierto. El paper de DeepMind le otorga a cualquier equipo que construyó credibilidad de ingeniería antes del boom de agentes una ventaja injusta: podemos decir *no* a solicitudes de funcionalidades específicas, por escrito, con una cita, y que el cliente nos lo agradezca. Las agencias que no dicen no son las que estarán en las noticias a finales de 2026 cuando la primera fuga de datos de un chatbot empresarial reciba un nombre.
La misma oportunidad que existe ahora mismo en el marketing de contenidos existe en la ingeniería de agentes. El mercado está a punto de inundarse de chatbots secuestrables, igual que se está inundando de slop SEO generado por LLM. La prima irá a los equipos que puedan demostrar, de antemano, que el suyo no es uno de ellos.
Dónde trazamos la línea
La versión más corta de la regla, la que ahora escribimos 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 eso. Si una solicitud de funcionalidad cruza la línea, no se construye. Si puede reformularse para mantenerse en un solo lado, la reformulamos junto con el cliente y desplegamos la versión reformulada. El paper de DeepMind no inventó esta disciplina. Solo eliminó todas las excusas para no tenerla.
En webvise construimos funcionalidades 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 y trazaremos el límite de confianza juntos antes de escribir cualquier código.