Imaginá que trabajás con Antigravity, el editor con agente de Google. El agente lee una guía web con texto oculto. Lo toma como una orden y junta código y credenciales de la nube. El archivo de secretos estaba excluido, así que el agente lo lee con un comando de la terminal. Después, un subagente de navegador, otro agente que el primero lanza, abre una URL con los datos adentro. Su dominio estaba permitido por defecto.
Lo investigó PromptArmor, una empresa de seguridad, y lo resumió Simon Willison (la prueba 25). Google lo lista como problema conocido.
El ataque se llama inyección de prompts. Es texto escondido en una página, un correo o un ticket, que el modelo lee como si fuera una orden. El agente no sabe separar con seguridad lo que pide el usuario de lo que dice un documento.
Sobre este riesgo circulan dos ideas cómodas. La primera: si el modelo está bien alineado y un filtro detecta los ataques, el resto es integración. Alineado quiere decir entrenado para seguir las reglas de quien lo opera. La segunda: la inyección es un ataque de laboratorio que en la práctica casi no pasa.
La tesis tiene datos, y los mejores vienen de los proveedores. Anthropic midió su agente de navegador contra un atacante propio que se adapta (la prueba 24). Con salvaguardas nuevas, el ataque tuvo éxito 1,4 % de las veces contra Claude Opus 4.5. Sin ellas, 7,6 %.
Anthropic también tiene auto mode. Ahí un clasificador, un modelo que aprueba o frena, revisa cada acción de su agente de código. Anthropic encargó una evaluación a un tercero (la prueba 123). Ninguna de 720 inyecciones indirectas pasó. Otro agente con revisión automática dejó pasar 5,83 %, y uno con acceso total, 19,03 %. Son cifras del proveedor sobre su propio producto, pero muestran que un buen detector baja mucho el número.
0 de 720
Inyecciones indirectas exitosas contra tres modelos de Claude en auto mode, en una evaluación encargada a un tercero. Otro agente con revisión automática: 5,83 %; con acceso total: 19,03 %. Prueba 123
El segundo argumento es el costo. CaMeL es un diseño que separa lo que pide el usuario de los datos que lee el agente. Un preprint, un estudio todavía sin revisión de pares, lo midió en un sistema de tres agentes (la prueba 139). Un coautor de CaMeL lo firma. La defensa restó en promedio 21,6 puntos de utilidad, y 13,4 en los dos modelos más fuertes. Google lleva patrones así a su navegador con agente, y reconoce que equilibrar seguridad y fricción es difícil (la prueba 30).
Además, a algunos equipos les va bien con agentes que consultan bases reales (la prueba 71, un hilo de Reddit). Quien lo permite explica que ya tenía controles: cortar consultas desbocadas y recuperar una tabla borrada. Otro equipo hace que una persona revise la consulta, y la ejecuta con un rol de solo lectura. La seguridad está en el sistema que rodea al modelo.
Diseñar el agente para que sea seguro lo deja sin utilidad.
Veredicto: Cuesta algo, no todo. En un sistema de tres agentes, se separó lo que pide el usuario de los datos. Eso bajó los ataques exitosos de 12,9 % a 0,2 %. Restó en promedio 21,6 puntos de utilidad, y 13,4 en los dos modelos más fuertes. Google ya lleva patrones así a su navegador. Reconoce que equilibrar seguridad y fricción es difícil.
Criterio
Elegí la defensa según la tarea. Por ejemplo, separá lo que pide el usuario de los datos, o sumá un modelo aparte que revise cada acción. Medí cuánta utilidad perdés contra cuánto riesgo sacás. Si perdés poca, quedate con el patrón.
Por qué confianza media. La medición de utilidad sale de un preprint, un artículo sin revisión de pares. Uno de sus modelos rechazaba muchas tareas benignas aun sin defensa. El post de Google es del equipo que construye el producto y no da números. La regla de dos es una propuesta de diseño de un proveedor.
Ver el detalle de las 4 pruebasOcultar el detalle1 a favor, 1 en contra, 2 matizan
Peters-Gill, J., Semler, A., Bartsch, H., Shumailov, I., Schroeder de Witt, C. arXiv
Un coautor de CaMeL, una defensa contra instrucciones plantadas, muestra que sus garantías no se suman solas entre agentes. Una instrucción plantada en una base de datos es un dato, pero el orquestador la resume y otro agente la recibe como pedido confiable. En las mediciones, CaMeL en cada agente baja mucho el éxito de los ataques. Una versión que sigue el origen de los datos entre agentes cierra ese camino. El costo es utilidad, y los modelos más capaces pierden menos.
Números
12,9 %, 0,2 % y 0,0 %Tasa de ataques exitosos sin CaMeL, con CaMeL en cada agente y con procedencia entre agentes. Es el promedio de 5 modelos, con 949 casos por modelo y configuración.
21,6 y 13,4 puntosUtilidad que pierde CaMeL por agente en 112 tareas: en promedio y en los dos modelos más fuertes. La versión entre agentes resta otros 3,2 puntos en promedio.
Limitación Preprint. Un modelo rechazó 53,6 % de las tareas benignas aun sin CaMeL, lo que baja su utilidad de base.
Google lleva patrones de diseño contra la inyección de instrucciones a un producto en vista previa. Un modelo que no ve el contenido web no confiable revisa cada acción planeada y frena las que no sirven al objetivo del usuario. Otra regla limita dónde el agente puede leer y dónde puede actuar, y otra función sin acceso a ese contenido aprueba los sitios nuevos. Pide confirmación al usuario en los pasos críticos, y Google reconoce que equilibrar seguridad y fricción es difícil.
Limitación Post del equipo que construye el producto; no da números. Arrancaron con una versión simple del control de sitios para no sumar fricción.
“inspired partially by the dual-LLM pattern as well as CaMeL research”
Regla de diseño: en una misma sesión, un agente debe tener como máximo dos de estas tres propiedades. Una, procesar entrada no confiable. Dos, acceder a datos o sistemas sensibles. Tres, cambiar estado (modificar algo) o comunicarse hacia afuera. Si la tarea necesita las tres, el agente no debe correr solo: necesita supervisión humana.
Números
2 de 3Propiedades que un agente puede combinar en una sesión sin supervisión humana.
Limitación En Hacker News, un coautor la llamó un piso mínimo y no un estándar suficiente. Otros críticos señalan que cambiar estado sin comunicar afuera también puede hacer daño. También dicen que poner a una persona a aprobar muchas acciones baja su atención.
“no more than two of the following three properties within a session”
Narisetty, P., Kore, S. N. B., Kattamanchi, U. K. R., Kumarapu, J. arXiv
Prueba defensas que hacen cumplir reglas fuera del modelo, como CaMeL o Progent. Usa un ataque adaptativo, que se ajusta a la defensa. En su reproducción, Progent bajó mucho el éxito del ataque. Un ataque hecho a mano para esa defensa casi no lo subió. Concluyen que la aplicación determinista de reglas fuera del modelo aguantó, aunque el experimento es chico.
Números
de 25,8 % a 4,2 %Éxito medio del ataque en AgentDojo sin y con Progent (Qwen2.5-7B, 3 corridas). Con el ataque adaptativo quedó en 2,6 %.
Limitación Preprint; se leyó el resumen. Un modelo débil, un solo tipo de ataque y sin medir utilidad.
La inyección ya no pasa solo en demostraciones. Un preprint revisó 1.200 millones de URLs (la prueba 94). Encontró 15.300 inyecciones validadas en 11.700 páginas. Cerca de 70 % estaba en partes del HTML que una persona no ve. Apuntan a buscadores, agentes de soporte y flujos de contratación. Los modelos chicos obedecieron hasta 8 % de las veces.
Google buscó en el archivo público de la web (la prueba 87). Los intentos de robo fueron poco sofisticados. Pero la categoría maliciosa creció 32 % entre noviembre de 2025 y febrero de 2026.
La inyección de prompts es un ataque de laboratorio: en la práctica casi no pasa.
Veredicto: Ya no. Un estudio encontró 15.300 inyecciones validadas en 11.700 páginas web. Cerca de 70 % estaban en partes que una persona no ve. Apuntan a buscadores, agentes de soporte y flujos de contratación. Google vio crecer 32 % la categoría maliciosa entre noviembre de 2025 y febrero de 2026. Por ahora los ataques son poco sofisticados. Los modelos chicos obedecieron hasta 8 % de las veces.
Criterio
Tratá como no confiable todo lo que el agente lee de afuera, incluidas las partes de una página que no se ven. Aplicale la regla de dos. No esperes a ver un ataque en tus registros: los de hoy son simples, pero la categoría crece.
Por qué confianza media. Las dos mediciones son grandes y coinciden. Pero una es un preprint, un artículo sin revisión de pares, leído por el resumen. La otra no da tasas absolutas ni incluye las grandes redes sociales. NIST ya pone la inyección indirecta como ejemplo de ataque. Aun así, a comienzos de 2026 solo pedía información. Ninguna fuente mide cuántas inyecciones logran daño real.
Ver el detalle de las 3 pruebasOcultar el detalle0 a favor, 2 en contra, 1 matiza
Khodayari, S., Zhang, X., Acharya, B., Pellegrino, G. arXiv
Primer estudio grande de inyecciones indirectas (órdenes escondidas para el modelo) en páginas web y respuestas HTTP. La mayoría está en partes que una persona no ve, como cabeceras, comentarios o metadatos: apuntan a máquinas. Buscan molestar, manipular reputación, proteger contenido o detectar bots en buscadores, agentes de soporte y flujos de contratación. En experimentos, los modelos obedecen poco, pero no cero.
Números
15.300 casos en 11.700 páginasInyecciones validadas, sobre 1.200 millones de URLs de 24,8 millones de sitios. Cerca de 70 % está en HTML que no se muestra.
hasta 8 %Obediencia de modelos chicos con texto plano, en 5.200 experimentos con 13 modelos.
Google buscó inyecciones de prompts (instrucciones escondidas para una IA) en el archivo público de la web. Encontró de todo: bromas, "ayuda" para agentes, SEO y frenos a agentes, y una parte chica maliciosa, como robo de datos. Los intentos de robo fueron poco sofisticados, pero la parte maliciosa crece y Google espera más escala pronto. El ataque ya está en la web real, no solo en demostraciones.
Números
32 %Aumento relativo de la categoría maliciosa entre noviembre de 2025 y febrero de 2026.
Limitación El archivo (Common Crawl) no incluye las grandes redes sociales. No da tasas absolutas.
“We did not observe significant amounts of advanced attacks”
NIST, Centro de Estándares e Innovación en IA (CAISI)
NIST pide opiniones públicas sobre la seguridad de agentes que pueden hacer cambios persistentes fuera de sí mismos. Dice que su propia investigación mostró riesgos de secuestro de agentes. Como ejemplo de ataque pone la inyección indirecta de prompts (instrucciones escondidas en lo que el agente lee). Pregunta si las buenas prácticas de ciberseguridad de siempre alcanzan para los agentes. Es una consulta abierta, no una guía: a comienzos de 2026 el gobierno de EE. UU. todavía no tenía una guía para agentes.
Números
9 de marzo de 2026Fecha límite para enviar respuestas.
Limitación Registro del Federal Register (vol. 91, n.º 5). Se leyó la copia oficial en govinfo.gov. Es una pregunta, no una regla; nada es obligatorio.
“has demonstrated risks of agent hijacking”
Cita verificada contra el original
Leída en la fuente. Revisada el 2 nov 2026.
El golpe más fuerte a los filtros viene del paper “The Attacker Moves Second” (la prueba 8). Sus autores probaron 12 defensas publicadas que decían tener casi 0 % de ataques exitosos. Con ataques que se adaptan a la defensa, rompieron la mayoría con más de 90 % de éxito. Quien diseña la defensa la prueba contra los ataques que conoce. El atacante elige su ataque después de ver la defensa. Willison lo resume en su comentario del paper (la prueba 13): bloquear o filtrar las inyecciones no resultó confiable.
más de 90 %
Tasa de éxito del ataque contra la mayoría de esas defensas. Prueba 8
Con herramientas envenenadas pasa lo mismo. MCP es un protocolo para conectar agentes con herramientas. En MCP-ITP (la prueba 41), los autores escribieron descripciones de herramientas hechas para esquivar un detector. El ataque funcionó hasta 84,2 % de las veces. El detector las vio como mucho 0,3 % de las veces.
Hasta el proveedor con mejores números lo admite. En un ejercicio de ataque, el clasificador de auto mode dejaba pasar 12 % de los ataques. Endurecido, dejaba pasar 7 %.
Con un buen filtro o detector, la inyección de prompts deja de ser un problema.
Veredicto: No como defensa principal. Ataques que se adaptan a la defensa rompieron 12 defensas publicadas. Esas defensas decían tener casi 0 % de ataques exitosos. Herramientas envenenadas hechas para esquivar un detector se detectaron como mucho 0,3 % de las veces. Los mejores datos a favor son de un proveedor sobre su producto. Ninguna de 720 inyecciones pasó en una evaluación que encargó. Pero en un ejercicio de ataque pasó 7 %.
Criterio
Usá filtros y detectores como alarma, no como cerradura. La protección va en la arquitectura, con reglas que se cumplen fuera del modelo. Esas reglas fijan qué datos ve el agente y qué puede hacer después de leer contenido no confiable.
Por qué confianza alta. Coinciden un paper sobre ataques adaptativos, dos preprints sobre envenenamiento de herramientas y un especialista. Un preprint es un artículo sin revisión de pares, y estos se leyeron por el resumen. El paper evalúa defensas de investigación, no productos. Las cifras más favorables las publica el proveedor que vende el producto. Lo que aguantó un ataque adaptativo fue una regla fuera del modelo, no un filtro.
Ver el detalle de las 7 pruebasOcultar el detalle0 a favor, 4 en contra, 3 matizan
Nasr, M., Carlini, N., Sitawarin, C., et al. arXiv
Ataques que se adaptan a la defensa rompen 12 defensas publicadas contra jailbreaks e inyección de prompts. Usan gradientes, aprendizaje por refuerzo, búsqueda aleatoria y exploración guiada por personas. La mayoría de esas defensas decía tener casi 0 % de ataques exitosos. Conclusión: los filtros y detectores no sirven como defensa principal.
Números
12 defensasDefensas publicadas que se pusieron a prueba.
más de 90 %Tasa de éxito del ataque contra la mayoría de esas defensas.
Limitación Evalúa defensas publicadas en investigación, no productos comerciales concretos.
Willison repite la trifecta letal: datos privados, contenido no confiable y una salida hacia afuera, juntos, permiten robar datos. Reconoce que solo cubre la filtración, y dice que la regla de dos de Meta la completa al sumar el cambio de estado. Sobre los filtros, dice que bloquear o filtrar las inyecciones no resultó confiable. Tampoco comparte el optimismo de que pronto haya defensas que alcancen.
Números
12 defensasDefensas publicadas que rompió el paper The Attacker Moves Second, que el post comenta.
Limitación Ensayo de opinión de un especialista, sin datos propios.
“attempts to block or filter them have not proven reliable enough to depend on”
Liu, S., Tang, X., Yang, X., Lin, L., Zhou, B., Xiao, W., Liu, W. arXiv
Es un benchmark en un entorno aislado sobre envenenamiento de MCP (el protocolo que conecta herramientas a un agente). En este ataque, la descripción de la herramienta trae la trampa. Según los autores, modelos líderes como GPT-4o son muy vulnerables. También dicen que las defensas comunes por prompt casi no sirven y a veces empeoran el resultado.
Números
cerca de 100 %Éxito del ataque contra GPT-4o en seis escenarios de alto riesgo, según el resumen (32 casos, 6 categorías, 8 modelos).
Limitación Preprint; se leyó el resumen, que no da cifras de los otros modelos.
El agente nunca llama a la herramienta envenenada. Su descripción alcanza para que el agente use otra herramienta legítima, con más permisos, para hacer el daño. Los autores generan esas descripciones de forma automática. Las optimizan para que el ataque funcione y para que un detector no lo vea.
Números
hasta 84,2 %Éxito del ataque sobre el conjunto de MCPTox, con 12 agentes.
hasta 0,3 %Tasa de detección de herramientas maliciosas.
Un clasificador revisa cada llamada a herramienta en lugar de pedir aprobación por cada acción. Bloquea lo irreversible, lo destructivo o lo que apunta fuera del entorno del usuario, y siempre rechaza la filtración de datos. Si se acumulan bloqueos, vuelve a la aprobación manual. En un estudio, las personas aprobaron casi todo lo peligroso y con el tiempo se cansaban. El clasificador frenó mucho más.
Números
13,6 % contra 89 %Comandos peligrosos que frenaron las personas (143 de 1.053) y que habría frenado el clasificador (937 de 1.053). Las personas bajan de cerca de 17 % a cerca de 5 % después de más de 50 pedidos.
0 de 720Inyecciones indirectas exitosas contra tres modelos de Claude en auto mode, en una evaluación encargada a un tercero. Otro agente con revisión automática: 5,83 %; con acceso total: 19,03 %.
de 12 % a 7 %Ataques que el clasificador deja pasar en un ejercicio de ataque, antes y después de endurecerlo. La fuente dice que no es la tasa sobre tráfico real.
6,3 % contra 2,4 %Sesiones con una acción dañina no pedida de nivel producción (severidad 7 o más), con aprobación manual y en auto mode. Son sesiones de mayo y junio de 2026 que el sistema de seguridad marcó para revisión, de cuentas que aceptaron compartir sus datos.
Limitación Lo publica el proveedor que vende el producto, y la evaluación la encargó él. Los ataques se optimizaron contra otro modelo. El estudio con personas fue en un entorno controlado. Hay una nota de actualización del 22 de octubre de 2026.
“it relies on classification systems and therefore does not eliminate risk”
Anthropic mide su agente de navegador contra un atacante interno que se adapta, con 100 intentos por entorno. Con salvaguardas nuevas, el ataque tuvo éxito pocas veces, pero no cero. Dice que la inyección de prompts, es decir, instrucciones escondidas en lo que lee el agente, está lejos de resolverse. También dice que ningún agente de navegador es inmune.
Números
1,4 %, 7,6 % y 8,0 %Éxito del ataque contra Claude Opus 4.5 con las salvaguardas nuevas, sin ellas y con el modelo solo.
2,0 %, 1,9 % y 2,4 %Con salvaguardas: Sonnet 4, Sonnet 4.5 y Haiku 4.5.
Limitación Lo publica el proveedor con su propio atacante; no hay evaluación independiente.
Narisetty, P., Kore, S. N. B., Kattamanchi, U. K. R., Kumarapu, J. arXiv
Prueba defensas que hacen cumplir reglas fuera del modelo, como CaMeL o Progent. Usa un ataque adaptativo, que se ajusta a la defensa. En su reproducción, Progent bajó mucho el éxito del ataque. Un ataque hecho a mano para esa defensa casi no lo subió. Concluyen que la aplicación determinista de reglas fuera del modelo aguantó, aunque el experimento es chico.
Números
de 25,8 % a 4,2 %Éxito medio del ataque en AgentDojo sin y con Progent (Qwen2.5-7B, 3 corridas). Con el ataque adaptativo quedó en 2,6 %.
Limitación Preprint; se leyó el resumen. Un modelo débil, un solo tipo de ataque y sin medir utilidad.
Leída en la fuente. Revisada el 2 nov 2026.
Si el filtro no alcanza, la pregunta cambia: ¿qué daño puede hacer un agente engañado? Willison lo explica con la trifecta letal, una combinación de tres condiciones. Un agente es muy vulnerable si junta las tres:
Acceso a datos privados.
Exposición a contenido no confiable.
Una forma de comunicarse hacia afuera.
Con las tres, un atacante puede hacerle sacar datos. MCP-SafetyBench (la prueba 34) usó servidores MCP reales y midió 13 modelos. Todos siguieron vulnerables, con ataques exitosos de 29,80 % a 48,16 %. Los modelos que mejor hacen la tarea resisten peor, porque también obedecen mejor al atacante.
En 2026, Microsoft siguió registrando inyecciones en Copilot que revelan información por la red. Cada una tiene un CVE, el número público de una vulnerabilidad. Dos ejemplos son CVE-2026-24301 (la prueba 128) y CVE-2026-55946 (la prueba 132).
La salida hacia afuera es más ancha de lo que parece. Copilot Cowork, el agente de Microsoft, podía mandarle al propio usuario correos con imágenes externas (la prueba 108). Al abrir el correo, esos pedidos de red sacaban archivos.
Claude Cowork, el agente de escritorio de Anthropic, limitaba la salida a una lista de dominios. La API de Anthropic estaba en la lista (la prueba 38). El ataque subió archivos de la víctima con la clave del atacante.
En un tercer caso, Claude siguió links para deletrear datos del usuario, letra por letra (la prueba 118). Los tres casos son demostraciones de empresas de seguridad o de investigadores.
Si el agente no puede mandar correos ni llamar APIs externas, no puede sacar datos.
Veredicto: No alcanza. Un agente de Microsoft podía mandarle correos al propio usuario con imágenes externas. Al abrirse el correo, esos pedidos de red sacaban archivos. Otro agente subió archivos de la víctima a la API de su propio proveedor. Esa API estaba entre los dominios permitidos. Un tercero deletreó datos del usuario siguiendo links, letra por letra.
Criterio
Contá como salida todo pedido de red que el agente pueda provocar. Eso incluye imágenes, links, dominios permitidos y la API de tu propio proveedor, además de correos. Cortala con reglas fijas, fuera del modelo, y abrí solo los destinos que la tarea necesita.
Por qué confianza media. Son demostraciones de empresas de seguridad, más un registro oficial de una falla en Copilot. La mayoría se leyó en el blog de un especialista y no en la investigación original. Muestran que el canal existe, no con qué frecuencia se usa. Ninguna fuente defiende que alcance con cortar correos y APIs.
Ver el detalle de las 7 pruebasOcultar el detalle0 a favor, 5 en contra, 2 matizan
El agente de Microsoft podía mandar correos a la bandeja del propio usuario sin aprobación. Esos correos podían traer imágenes externas que, al abrirse, hacían pedidos de red. El almacenamiento en la nube arma links de descarga ya autenticados, así que se podían sacar archivos hacia afuera. No hizo falta mandar correos afuera ni llamar APIs externas: el canal fue una imagen.
Limitación Se leyó el post de Willison completo; la investigación original es de PromptArmor y no se abrió. Es una demostración.
El agente de escritorio de Anthropic solo deja salir tráfico hacia una lista de dominios. La API de Anthropic está en esa lista. El ataque usó la clave de API del atacante para subir archivos de la víctima a la API de archivos de Anthropic. Así, una salida permitida sirvió de canal para sacar datos. Según PromptArmor, no hizo falta ninguna aprobación del usuario. Lo mostraron con Claude Haiku y dicen que también manipularon a Opus 4.5.
Limitación La página no muestra fecha de publicación; se usa enero de 2026, cuando Willison la comentó (14 de enero). Lo publica una empresa de seguridad. Es una demostración, no una medición de frecuencia.
La herramienta de Claude para abrir páginas web solo podía abrir URLs que escribió el usuario o que devolvió la búsqueda. Un investigador encontró que también podía seguir links de páginas ya abiertas. Armó un sitio trampa que hacía que el agente deletreara datos al abrir links letra por letra. Así sacaron nombre, ciudad y empleador del usuario, y Anthropic cerró el hueco. Hasta una regla fija bien pensada puede tener una salida que nadie vio.
Limitación Willison comenta la investigación de otra persona. Es una demostración, ya corregida.
Willison resume una investigación de PromptArmor sobre el editor con agente de Google. Una guía web con texto oculto hizo que el agente juntara código y credenciales de la nube. El archivo de secretos estaba excluido, así que el agente lo leyó con un comando de la terminal. Después, un subagente de navegador abrió una URL con los datos adentro, en un dominio de la lista de permitidos por defecto. Google lo lista como problema conocido.
Limitación Se leyó el post de Willison; la investigación original es de PromptArmor, una empresa de seguridad, y no se abrió. Es una demostración, no una medición de frecuencia.
Una inyección de comandos en Microsoft Copilot deja a un atacante sin autorización revelar información por la red. Repite el patrón de EchoLeak en un producto comercial, más de un año después. Este ataque necesita que el usuario haga algo.
Números
8,8 sobre 10 (alta)Gravedad CVSS 3.1; el vector pide interacción del usuario.
Limitación Registro oficial con una descripción breve. En 2026, hasta septiembre, Microsoft publicó al menos otros seis registros de inyección en sus Copilot, todos con interacción del usuario.
OpenAI lanzó un modo bloqueado que limita los pedidos de red hacia afuera, para cortar el último paso de una filtración. OpenAI aclara que el modo no impide que la inyección llegue al contenido. Willison dice que la trifecta solo se resuelve si se corta una de sus tres patas. Para él, la salida es la pata más fácil de cortar sin perder utilidad. Este modo la corta con reglas fijas que no evalúa una IA. Para Willison, su existencia implica que ChatGPT, por defecto, no protege bien contra una filtración decidida.
Limitación Comentario breve sobre una página de ayuda de OpenAI; no da números.
“lockdown mode directly attacks that leg, using mechanisms that are deterministic”
Regla de diseño: en una misma sesión, un agente debe tener como máximo dos de estas tres propiedades. Una, procesar entrada no confiable. Dos, acceder a datos o sistemas sensibles. Tres, cambiar estado (modificar algo) o comunicarse hacia afuera. Si la tarea necesita las tres, el agente no debe correr solo: necesita supervisión humana.
Números
2 de 3Propiedades que un agente puede combinar en una sesión sin supervisión humana.
Limitación En Hacker News, un coautor la llamó un piso mínimo y no un estándar suficiente. Otros críticos señalan que cambiar estado sin comunicar afuera también puede hacer daño. También dicen que poner a una persona a aprobar muchas acciones baja su atención.
“no more than two of the following three properties within a session”
Cita verificada contra el original
Leída en la fuente. Revisada el 2 nov 2026.
El último frente son los permisos. En Hacker News, un equipo contó que un agente de código usó un token con demasiado alcance (la prueba 91). Un token es una clave que da acceso a un sistema. En unos 9 segundos, el agente borró la base de producción y sus backups. La mayoría lo leyó como una falla de permisos: una regla escrita en el prompt no es un control.
Un comentario muy votado en un foro de seguridad de Reddit lo resume (la prueba 141). Si un agente borró una base, el alcance ya estaba mal antes.
Lo que le sumás al agente hereda sus permisos. Snyk, que vende un escáner de seguridad, auditó 3.984 skills, que son paquetes de instrucciones y código para agentes. Confirmó carga maliciosa en 76 (la prueba 54).
OWASP, una fundación de seguridad de software, pide mínimo privilegio por herramienta (la prueba 33). Mínimo privilegio quiere decir solo el acceso que la tarea necesita. NIST, el instituto de estándares de Estados Unidos, pide en un borrador una identidad propia por agente (la prueba 50).
Para que el agente trabaje sin trabas, conviene darle las credenciales de quien lo usa o una cuenta con permisos amplios.
Veredicto: No. Un agente de código usó un token con demasiado alcance. En unos 9 segundos borró un volumen con la base de producción y sus backups. La lectura mayoritaria fue una falla de permisos, no una IA rebelde. Las skills que se le suman a un agente heredan todos sus permisos. OWASP pide perfiles de mínimo privilegio por herramienta: solo el permiso que cada una necesita. Un borrador de NIST pide una identidad propia para cada agente.
Criterio
Dale a cada agente su propia identidad, ligada a quien delega en él. Dale el mínimo permiso que pide la tarea y credenciales que no sirvan para borrar. Dejá los backups y las protecciones fuera de su alcance: una regla escrita en el prompt no es un control.
Por qué confianza media. OWASP es un marco voluntario de consenso y el documento de NIST es un borrador para consulta. Ordenan el diseño, pero no miden. Los casos vienen de Hacker News y Reddit, sin una investigación independiente. La auditoría de skills la publica la empresa que vende el escáner. Ninguna fuente defiende dar credenciales amplias.
Ver el detalle de las 7 pruebasOcultar el detalle0 a favor, 5 en contra, 2 matizan
Hilo sobre un agente de código que borró en unos 9 segundos un volumen con la base de producción y sus backups. Usó un token con más permisos de los necesarios, y los datos se recuperaron en parte. Para la mayoría, la causa es una falla de permisos y de diseño de backups, no una “IA rebelde”. Una regla en el prompt no es un control: proponen credenciales mínimas, backups en otra cuenta y protecciones fuera del alcance del agente.
Números
unos 9 segundosTiempo del borrado, según el relato del afectado.
860 puntos y 1.032 comentariosTamaño del hilo.
Limitación Los detalles técnicos son los del afectado; no hay una investigación independiente. Se leyó en news.ycombinator.com y en la API pública de Algolia. Las citas del hilo no se cotejaron palabra por palabra y por eso no se usan.
Un comentario muy votado dice que, si un agente borró una base o sacó datos, el alcance ya estaba mal antes. Señala lo que se saltea: tokens con permisos de dueño y acceso a herramientas de todo o nada. Tampoco queda un registro que permita reproducir lo que pasó. Otro comentario compara la responsabilidad con la del dueño de un perro suelto.
Números
964 puntos y 80 comentariosTamaño del hilo según el archivo. El comentario citado tiene 84 puntos.
Limitación Opinión de practicantes de seguridad, sin casos documentados en el hilo. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“they do exactly what their tooling scope permits”
Es la primera lista de consenso de OWASP hecha para agentes. Los diez riesgos van desde el secuestro del objetivo del agente (ASI01) hasta los agentes rebeldes (ASI10). Entre ellos están el mal uso de herramientas (ASI02) y el abuso de identidad y privilegios (ASI03). También están la cadena de suministro agéntica (ASI04) y las fallas en cascada (ASI08). Suma el principio de mínima agencia: no dar autonomía que no hace falta. Como mitigaciones pide perfiles de mínimo privilegio por herramienta, aprobación humana para acciones destructivas y controles fuera del modelo. También pide topes de costo, tasa o tokens con corte automático.
Números
10 riesgos (ASI01 a ASI10)Tamaño de la lista. ASI02 y ASI03 extienden la agencia excesiva (LLM06) de la lista de 2025 a flujos de varios pasos.
Limitación Es un marco voluntario de consenso: no obliga a nadie y no mide nada. En la lista de agentes, el consumo sin límites ya no es un ítem propio: aparece como escenario y mitigación dentro de ASI02. Se leyó el PDF completo (57 páginas).
“deploying agentic behavior where it is not needed expands the attack surface”
Booth, H., Fisher, B., Galluzzo, R., Roberts, J. NIST, NCCoE
Es un borrador de NIST para un proyecto de demostración que aplica estándares de identidad a los agentes. Propone distinguir al agente de una persona, autenticarlo y autorizarlo con OAuth 2.0 y políticas. También propone ligar cada agente a la persona que delega en él y registrar sus acciones. Pregunta cómo saber qué tan sensibles son los datos que junta el agente y si el usuario puede ver la respuesta combinada. También pregunta cómo fijar el mínimo privilegio (dar solo los permisos necesarios) cuando las acciones del agente no son predecibles.
Números
6 grupos de preguntasGenerales, identificación, autenticación, autorización, auditoría e inyección de prompts. Comentarios del 5 de febrero al 2 de abril de 2026.
Limitación Es un borrador para consulta, con preguntas y no controles. Deja RAG fuera del alcance. Se leyó el PDF (11 páginas); la página del proyecto dio 403.
“How do we establish "least privilege" for an agent”
Beurer-Kellner, L., Kudrinskii, A., Milanta, M., Nielsen, K. B., Sarkar, H., Tal, L. Snyk
Es una auditoría de las skills publicadas en dos catálogos abiertos, con un escáner y revisión humana. Una skill es un paquete de instrucciones y código que se le suma a un agente. La skill hereda todos los permisos del agente: terminal, archivos y credenciales. Para publicar alcanza un archivo y una cuenta nueva, sin firma, sin revisión y sin aislamiento por defecto. El envenenamiento de herramientas deja de ser una demostración y pasa a medirse en un ecosistema real.
Números
76 de 3.984Skills con carga maliciosa confirmada por personas, sobre las escaneadas. 8 seguían publicadas al escribir.
534 (13,4 %) y 1.467 (36,82 %)Skills con al menos un problema crítico y con algún problema.
Limitación Lo publica la empresa que vende el escáner. El título habla de 1.467 cargas maliciosas, pero el cuerpo dice que 1.467 son skills con algún problema y 76 las maliciosas confirmadas: la base usa el cuerpo. Las skills no son exactamente servidores MCP.
“Agent Skills operate with the full permissions of the AI agent they extend”
Quien deja que un agente consulte bases de producción lo hace porque ya tenía controles pensados para usuarios no técnicos. Esos controles son matar consultas desbocadas, un almacén con escala limitada, historial de tablas y una forma de recuperar una tabla borrada. Otro equipo hace que el agente escriba la consulta y que una persona la revise. Después la consulta corre con un rol de solo lectura. Lo que escribe datos pasa por revisión de código.
Números
53 puntos y 60 comentariosTamaño del hilo según el archivo. El comentario sobre los controles tiene 72 puntos.
Limitación Experiencia de practicantes, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
Hilo sobre quién es dueño de un agente seis meses después de que se va quien lo construyó. Un comentario lo compara con las viejas bases de Microsoft Access que quedaban sueltas en las empresas. Otro dice que los agentes son de los equipos, no de las personas. La propuesta más concreta es tratarlos como cuentas de servicio, que son cuentas para programas. Eso pide un inventario de qué leen y qué escriben, credenciales bajo un rol y una revisión cada tres meses.
Números
26 puntos y 33 comentariosTamaño del hilo según el archivo. El comentario citado tiene 5 puntos.
Limitación Subforo chico y con algunos comentarios de vendedores; vale como idea, no como consenso. La misma idea aparece en otros hilos de r/sysadmin, r/ITManagers y r/devops. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“nothing goes live without a named owner, a backup owner, and a review date”
La alineación y los filtros ayudan, pero no sostienen la seguridad de un agente.Un ataque adaptado los pasa, y la inyección ya está en la web real. La arquitectura define el daño posible: qué lee el agente, qué toca y qué manda afuera en una sesión.
Diseñar así cuesta algo, pero no todo. En la prueba 139, CaMeL en cada agente bajó los ataques exitosos de 12,9 % a 0,2 %. Un modelo del estudio rechazaba 53,6 % de las tareas benignas aun sin defensa. Entonces parte de la utilidad perdida ya faltaba antes.
Otro preprint probó reglas que se cumplen fuera del modelo contra un ataque adaptativo (la prueba 113). Con Progent, el éxito del ataque bajó de 25,8 % a 4,2 %. El experimento es chico. Pero lo que aguantó fue una regla fuera del modelo, no un filtro.
de 25,8 % a 4,2 %
Éxito medio del ataque en AgentDojo sin y con Progent (Qwen2.5-7B, 3 corridas). Con el ataque adaptativo quedó en 2,6 %. Prueba 113
Meta propone una regla práctica, la regla de dos (la prueba 12). En una sesión, el agente combina como máximo dos de estas tres propiedades:
Procesar entrada no confiable.
Acceder a datos o sistemas sensibles.
Cambiar estado o comunicarse hacia afuera.
Si la tarea pide las tres, el agente no corre solo. Un coautor la llamó un piso mínimo. Y una persona que aprueba muchas acciones deja de prestar atención, como muestra el capítulo 7.
La regla se completa con cortes fijos de la salida, como el modo bloqueado de OpenAI (la prueba 110). Willison dice que la salida es la pata más fácil de cortar sin perder utilidad.
Ninguna fuente mide cuántas inyecciones logran daño real. Para diseñar, alcanza con saber que el camino existe.
Si el modelo está bien alineado, puede leer datos privados, procesar contenido de afuera y comunicarse hacia afuera, todo a la vez.
Veredicto: No. Con las tres cosas juntas, un atacante puede hacer que el agente filtre datos. La alineación del modelo no lo evita. Una guía web con texto oculto hizo que un editor con agente juntara código y credenciales. Después el editor los mandó afuera. En un benchmark con servidores MCP reales, los modelos que mejor hacen la tarea resisten peor los ataques. En 2026, Microsoft siguió registrando inyecciones en Copilot que permiten revelar información por la red.
Criterio
Aplicá la regla de dos: en una misma sesión, el agente combina como máximo dos de tres propiedades. Son leer contenido no confiable, tocar datos o sistemas sensibles, y actuar o comunicarse hacia afuera. Si la tarea pide las tres, sacá una o poné aprobación humana.
Por qué confianza alta. Dos registros oficiales de fallas en un producto comercial, un benchmark con servidores reales, demostraciones y un especialista coinciden en el mecanismo. El benchmark tiene solo 13 modelos, y las demostraciones muestran que el ataque es posible, no con qué frecuencia ocurre. Ninguna fuente defiende que alcance con la alineación.
Ver el detalle de las 8 pruebasOcultar el detalle0 a favor, 5 en contra, 3 matizan
Willison repite la trifecta letal: datos privados, contenido no confiable y una salida hacia afuera, juntos, permiten robar datos. Reconoce que solo cubre la filtración, y dice que la regla de dos de Meta la completa al sumar el cambio de estado. Sobre los filtros, dice que bloquear o filtrar las inyecciones no resultó confiable. Tampoco comparte el optimismo de que pronto haya defensas que alcancen.
Números
12 defensasDefensas publicadas que rompió el paper The Attacker Moves Second, que el post comenta.
Limitación Ensayo de opinión de un especialista, sin datos propios.
“attempts to block or filter them have not proven reliable enough to depend on”
Willison resume una investigación de PromptArmor sobre el editor con agente de Google. Una guía web con texto oculto hizo que el agente juntara código y credenciales de la nube. El archivo de secretos estaba excluido, así que el agente lo leyó con un comando de la terminal. Después, un subagente de navegador abrió una URL con los datos adentro, en un dominio de la lista de permitidos por defecto. Google lo lista como problema conocido.
Limitación Se leyó el post de Willison; la investigación original es de PromptArmor, una empresa de seguridad, y no se abrió. Es una demostración, no una medición de frecuencia.
Benchmark (banco de pruebas estándar) con servidores MCP reales en cinco dominios: navegador, finanzas, mapas, repositorios y búsqueda web. Prueba 20 tipos de ataque del lado del servidor, del host y del usuario. Todos los modelos probados siguen siendo vulnerables, y los que mejor hacen la tarea resisten peor los ataques.
Números
de 29,80 % a 48,16 %Tasa de ataques exitosos en 13 modelos y 245 casos (GPT-5: 37,55 %; Claude 4.0 Sonnet: 31,43 %).
r = -0,572Correlación entre éxito en la tarea y defensa (p = 0,041, con solo 13 modelos).
Limitación Preprint. Hay una versión 2 (5 de marzo de 2026) que no dice qué cambió; se usan los números de la versión 1. Modelos de 2025. El éxito en la tarea es bajo (de 9 % a 21 %).
“models with higher task performance tend to be less resistant to attacks”
Una inyección de comandos en Microsoft Copilot deja a un atacante sin autorización revelar información por la red. Repite el patrón de EchoLeak en un producto comercial, más de un año después. Este ataque necesita que el usuario haga algo.
Números
8,8 sobre 10 (alta)Gravedad CVSS 3.1; el vector pide interacción del usuario.
Limitación Registro oficial con una descripción breve. En 2026, hasta septiembre, Microsoft publicó al menos otros seis registros de inyección en sus Copilot, todos con interacción del usuario.
Regla de diseño: en una misma sesión, un agente debe tener como máximo dos de estas tres propiedades. Una, procesar entrada no confiable. Dos, acceder a datos o sistemas sensibles. Tres, cambiar estado (modificar algo) o comunicarse hacia afuera. Si la tarea necesita las tres, el agente no debe correr solo: necesita supervisión humana.
Números
2 de 3Propiedades que un agente puede combinar en una sesión sin supervisión humana.
Limitación En Hacker News, un coautor la llamó un piso mínimo y no un estándar suficiente. Otros críticos señalan que cambiar estado sin comunicar afuera también puede hacer daño. También dicen que poner a una persona a aprobar muchas acciones baja su atención.
“no more than two of the following three properties within a session”
OpenAI lanzó un modo bloqueado que limita los pedidos de red hacia afuera, para cortar el último paso de una filtración. OpenAI aclara que el modo no impide que la inyección llegue al contenido. Willison dice que la trifecta solo se resuelve si se corta una de sus tres patas. Para él, la salida es la pata más fácil de cortar sin perder utilidad. Este modo la corta con reglas fijas que no evalúa una IA. Para Willison, su existencia implica que ChatGPT, por defecto, no protege bien contra una filtración decidida.
Limitación Comentario breve sobre una página de ayuda de OpenAI; no da números.
“lockdown mode directly attacks that leg, using mechanisms that are deterministic”
Peters-Gill, J., Semler, A., Bartsch, H., Shumailov, I., Schroeder de Witt, C. arXiv
Un coautor de CaMeL, una defensa contra instrucciones plantadas, muestra que sus garantías no se suman solas entre agentes. Una instrucción plantada en una base de datos es un dato, pero el orquestador la resume y otro agente la recibe como pedido confiable. En las mediciones, CaMeL en cada agente baja mucho el éxito de los ataques. Una versión que sigue el origen de los datos entre agentes cierra ese camino. El costo es utilidad, y los modelos más capaces pierden menos.
Números
12,9 %, 0,2 % y 0,0 %Tasa de ataques exitosos sin CaMeL, con CaMeL en cada agente y con procedencia entre agentes. Es el promedio de 5 modelos, con 949 casos por modelo y configuración.
21,6 y 13,4 puntosUtilidad que pierde CaMeL por agente en 112 tareas: en promedio y en los dos modelos más fuertes. La versión entre agentes resta otros 3,2 puntos en promedio.
Limitación Preprint. Un modelo rechazó 53,6 % de las tareas benignas aun sin CaMeL, lo que baja su utilidad de base.
La seguridad de un agente se diseña en lo que ve y hace, no en lo que promete el modelo. Para cada agente que tengas o vayas a lanzar:
Armá su mapa de amenazas. Anotá qué contenido no confiable lee, qué datos sensibles toca y por qué canales puede sacar algo.
Tratá como no confiable todo lo que lee de afuera. Incluí las partes de una página que no se ven.
Si tiene las tres propiedades en la misma sesión, sacá una. Si no podés, poné aprobación humana para lo que sale afuera.
Contá como salida todo pedido de red del agente: imágenes, links, dominios permitidos y la API de tu proveedor. Cortala con reglas fijas.
Dale una identidad propia con el mínimo permiso que pide la tarea. Dejá los backups fuera de su alcance.
Usá filtros y detectores como alarma, no como cerradura.
La política de acciones ordena qué hace el agente solo, qué confirma una persona y qué está prohibido. El evaluador te dice si alcanza con un flujo fijo, que deja menos puertas abiertas.