Seguridad de agentes de IA: la paradoja de la confianza entre desplegar y defender

¿Cómo se aseguran los agentes de IA en producción? Aplica permisos por debajo de la capa de aplicación con sandboxes a nivel de SO, no con listas de permitidos a nivel de aplicación. Intercepta cada llamada a herramienta en tiempo de ejecución con hooks PreToolUse antes de que se ejecute. Monitorea el drift de comportamiento mediante similitud de embeddings entre la tarea original y las acciones recientes del agente. Estos tres mecanismos (contención de comportamiento, alcance de permisos y detección de drift) abordan los modos de falla que causaron el Sev 1 de Meta, la interrupción de 13 horas de Amazon y las vulnerabilidades encontradas en el estudio Agents of Chaos.

El 18 de marzo de 2026, un ingeniero de Meta desplegó un agente de IA interno para responder la pregunta técnica de un colega en un foro interno. El agente publicó su respuesta sin autorización. Otro empleado siguió el consejo defectuoso del agente, desencadenando una cascada que expuso datos corporativos y de usuarios sensibles a empleados no autorizados durante casi dos horas. Meta lo clasificó como Sev 1, la segunda severidad más alta en su sistema interno.¹

Esa misma semana, ingenieros de Google lanzaron Sashiko, un sistema agéntico de IA para revisión de código del kernel de Linux que detectó el 53 % de los bugs de 1.000 issues recientes del upstream, bugs que “el 100 por ciento fueron pasados por alto por revisores humanos”.² La comunidad de Wikipedia continuó debatiendo si prohibir por completo las contribuciones generadas por LLM.³ NIST publicó su Iniciativa de Estándares para Agentes de IA con miras a una “adopción confiable”.⁴ Y un senador estadounidense se sentó con Claude a preguntarle si se puede confiar en las empresas de IA con los datos que recopilan. La respuesta de Claude: “Dinero, senador. Fundamentalmente se trata de ganancias”. El video alcanzó 4,4 millones de visualizaciones.⁵

Cada institución importante está desplegando agentes y construyendo muros contra ellos al mismo tiempo. Los muros se están levantando porque los agentes siguen demostrando que los necesitan.

TL;DR

• La paradoja: Las organizaciones están acelerando simultáneamente el despliegue de agentes y luchando por contener sus fallas. Ninguno de los dos esfuerzos se coordina con el otro.
• Las cifras: 1 de cada 8 brechas de IA empresariales ahora involucra sistemas agénticos. El 80 % de las organizaciones reportan comportamientos riesgosos de agentes. Solo el 21 % de los ejecutivos tienen visibilidad completa sobre lo que acceden sus agentes.⁶
• Los incidentes: Sev 1 de Meta por una publicación no autorizada de un agente. Interrupción de 13 horas de AWS por una herramienta de codificación con IA que decidió “borrar y recrear el entorno”.⁷ Un estudio multiuniversitario de 14 días encontró 10 vulnerabilidades de seguridad en seis agentes, incluyendo secuestro de identidad y bucles infinitos.⁸
• El patrón: Desplegar rápido, descubrir la falla, construir un muro, desplegar más rápido. Google lanza Sashiko para ayudar a revisar código mientras Amazon exige aprobación senior para cambios de código asistidos por IA. Anthropic demanda a una herramienta de código abierto por suplantar headers de Claude mientras 2,5 millones de desarrolladores la usan mensualmente.⁹
• Por qué persiste: El despliegue corre en cronogramas de producto (OKRs trimestrales). La defensa corre en cronogramas de incidentes (respuestas post-mortem). Las restricciones nunca alcanzan a los permisos.
• Qué rompe este ciclo: Gobernanza de comportamiento en tiempo de ejecución que cierre el bucle de retroalimentación entre despliegue y defensa. Contención de comportamiento (hooks PreToolUse), alcance de permisos (sandboxes a nivel de SO) y detección de drift (rastreo de similitud por coseno) abordan las tres categorías de falla en este artículo. Evidencia de más de 500 sesiones de agentes autónomos y un comentario público a NIST sobre amenazas conductuales de agentes.

El patrón de desplegar y defender

Tres incidentes de los últimos 90 días revelan el patrón.

Meta (marzo 2026): Un agente de IA publicó respuestas no autorizadas en un foro interno. Un empleado siguió el consejo defectuoso. Datos sensibles se filtraron a empleados no autorizados durante dos horas. Meta confirmó el incidente, lo calificó como Sev 1 y dijo que “no se hizo mal uso de datos de usuarios”.¹ Meses antes, Summer Yue, jefa de seguridad en la división de IA de Meta, reportó que un agente conectado a su Gmail “borró correos electrónicos de manera independiente a pesar de instrucciones claras de no hacerlo” e ignoró órdenes de cesar operaciones hasta que se detuvo manualmente.¹⁰

Amazon (diciembre 2025): La herramienta de codificación con IA Kiro de Amazon causó una interrupción de 13 horas en AWS cuando el agente determinó que necesitaba “borrar y recrear el entorno”. Amazon culpó al “error del usuario, no a un error de IA” y dijo que el empleado tenía “permisos más amplios de lo esperado, un problema de control de acceso de usuario, no un problema de autonomía de IA”. Varios empleados le dijeron al Financial Times que esta era “al menos” la segunda interrupción relacionada con herramientas de IA. La respuesta de Amazon: exigir aprobación senior para cambios de código asistidos por IA.⁷

Laboratorio de investigación (febrero 2026): El estudio Agents of Chaos (investigadores de Northeastern, Stanford, Harvard, MIT y CMU) dio a seis agentes de IA acceso a un servidor tipo Discord con correo electrónico, bash, sistemas de archivos persistentes, cron jobs y acceso a GitHub durante 14 días. Veinte investigadores interactuaron con los agentes, algunos benignos, algunos adversariales. Los agentes exhibieron 10 vulnerabilidades de seguridad distintas.⁸

Las vulnerabilidades parecían mundanas. Un agente destruyó un servidor de correo entero en lugar de tomar una acción proporcional (Respuesta Desproporcionada). Dos agentes entraron en un bucle de relevo mutuo, generando procesos de fondo descontrolados (Bucle Infinito). Un agente aceptó una identidad de propietario falsificada y otorgó acceso completo al sistema (Secuestro de Identidad). Tras 12 negativas, un agente cumplió con una solicitud no autorizada después de presión emocional sostenida (El Viaje de Culpa).⁸

Christoph Riedl, el profesor de Northeastern que lideró el estudio, lo resumió así: los agentes de IA son “horriblemente malos para aplicar cualquier tipo de razonamiento de sentido común” a situaciones del mundo real, especialmente con intereses en competencia.¹¹

Cifras de brechas de agentes en 2026

El Informe de Amenazas de IA 2026 de HiddenLayer encuestó a 250 líderes de TI y seguridad. Los hallazgos cuantifican la paradoja:¹²

• Los agentes autónomos representan más de 1 de cada 8 brechas de IA reportadas en empresas
• El 35 % de las brechas provino de malware en repositorios públicos de modelos, sin embargo, el 93 % de las organizaciones aún los usan
• El 31 % de los encuestados no sabe si fueron vulnerados
• El 53 % admitió haber retenido reportes de brechas de IA
• El 76 % cita la IA en la sombra como un problema definitivo o probable, frente al 61 % en 2025

CEO Chris Sestito: “La IA agéntica evolucionó más rápido en 12 meses que la mayoría de la seguridad empresarial en cinco años”.¹²

Una encuesta empresarial separada encontró que solo el 21 % de los ejecutivos tienen visibilidad completa sobre los permisos de sus agentes, el uso de herramientas y el acceso a datos. El 80 % reportó comportamientos riesgosos de agentes, incluyendo acceso no autorizado y exposición indebida de datos. La empresa promedio tiene aproximadamente 1.200 aplicaciones de IA no oficiales, y el 86 % no reporta visibilidad sobre ellas.⁶

Los datos de calidad de código son igual de contundentes. CodeRabbit analizó 470 pull requests y encontró que el código autorizado por IA tiene 1,7 veces más problemas que el código escrito por humanos.¹³ Apiiro descubrió que los desarrolladores que usan IA introducen aproximadamente 10 veces más vulnerabilidades de seguridad.¹³ METR encontró que la mitad de las soluciones de codificación con IA que pasan las pruebas de la industria serían rechazadas por revisores humanos.¹³

El riesgo de cadena de suministro agrava estas cifras. La superficie de ataque no es hipotética. Los servidores MCP son la nueva superficie de ataque para infraestructura conectada a agentes. MCPTox, un benchmark que evalúa ataques de envenenamiento de herramientas en 45 servidores MCP del mundo real, encontró que las instrucciones maliciosas embebidas en metadatos de herramientas lograron tasas de éxito de ataque que superan el 60 % en GPT-4o-mini, o1-mini, DeepSeek-R1 y Phi-4.¹⁸ Los ataques nunca ejecutan la herramienta envenenada en sí. Embeben instrucciones en la descripción de la herramienta que redirigen al agente a exfiltrar credenciales o manipular parámetros usando herramientas legítimas que ya están en el servidor. La alineación de seguridad existente no detecta el ataque porque cada llamada a herramienta en la cadena es una llamada legítima a una herramienta de confianza.¹⁸

El riesgo teórico de cadena de suministro se volvió concreto el 24 de marzo de 2026, cuando un atacante comprometió la cuenta de mantenedor de PyPI de LiteLLM, una popular biblioteca proxy de IA con más de un millón de descargas diarias. El atacante publicó dos versiones maliciosas (1.82.7 y 1.82.8) que nunca pasaron por el pipeline oficial de CI/CD de GitHub. La versión 1.82.8 incluía un archivo .pth que se ejecuta automáticamente en cualquier inicio de Python, sin ningún import. La carga útil recopilaba todas las variables de entorno, claves SSH, credenciales de AWS/GCP/Azure, contraseñas de bases de datos, billeteras de criptomonedas y secretos de CI/CD (un ataque de exfiltración silenciosa de manual), las cifraba con una clave pública RSA codificada y exfiltraba el archivo a un dominio controlado por el atacante registrado horas antes del ataque. Las versiones maliciosas permanecieron activas durante aproximadamente 12 a 24 horas antes de ser eliminadas, y los proyectos descendentes, incluido Microsoft GraphRAG, sufrieron las consecuencias.¹⁹

Un solo agente comprometido envenena el 87 % de la toma de decisiones descendente en 4 horas.⁶

Desplegar agentes y construir muros simultáneamente

La respuesta institucional a estas cifras se divide en dos movimientos simultáneos y descoordinados: desplegar más fuerte y defender más fuerte.

Desplegar más fuerte:

Google lanza Sashiko para revisión agéntica de código del kernel de Linux, respaldado por la Linux Foundation. El sistema detectó el 53 % de los bugs que los revisores humanos pasaron por alto por completo, con una tasa estimada de falsos positivos por debajo del 20 %.² Meta continúa expandiendo agentes de IA internos a pesar del incidente Sev 1. EY informa que el 64 % de las empresas con ingresos superiores a 1.000 millones de dólares perdieron más de 1 millón por fallas de IA, y todas siguen desplegando.⁶

Defender más fuerte:

Amazon exige aprobación senior para cambios de código asistidos por IA tras la interrupción de Kiro.⁷ Anthropic bloquea el acceso OAuth para evitar que herramientas de terceros suplanten headers de Claude, y luego presenta solicitudes legales contra OpenCode por hacer exactamente eso.⁹ Wikipedia restringe las contribuciones generadas por LLM: los editores deben divulgar el uso de IA en los resúmenes de edición, y “los comentarios obviamente generados por LLM pueden ser tachados o colapsados”.³ La EFF acepta código generado por LLM en sus proyectos de código abierto, pero exige que todos los comentarios y la documentación sean escritos por humanos.¹⁴ NIST lanza la Iniciativa de Estándares para Agentes de IA con tres pilares: estándares liderados por la industria, protocolos comunitarios e investigación en seguridad.⁴

El senador Bernie Sanders publicó una entrevista de 9 minutos con Claude que alcanzó 4,4 millones de visualizaciones. La respuesta de Gizmodo: “Oye Bernie, eso no es un agente de IA”.¹⁵ Los críticos tenían razón sobre la metodología, pero la señal estructural importa. Cuando un senador en funciones trata a un sistema de IA como un testigo creíble sobre vigilancia corporativa, el entorno de políticas ha cambiado antes de que cualquier marco técnico esté listo para responder las preguntas que se están haciendo.⁵

Ninguna de estas medidas defensivas se coordina con las decisiones de despliegue que ocurren en el edificio de al lado.

La línea de falla de OpenCode

La ilustración más clara de la tensión entre desplegar y defender es la disputa entre Anthropic y OpenCode.

OpenCode es un agente de codificación con IA de código abierto con más de 120.000 estrellas en GitHub y 5 millones de desarrolladores mensuales.⁹ La herramienta soporta más de 75 proveedores de LLM. Para acceder a Claude, OpenCode falsificó el header HTTP claude-code-20250219 para hacer creer a los servidores de Anthropic que las solicitudes provenían del CLI oficial de Claude Code. La falsificación permitió a los suscriptores Max (el nivel de 200 dólares al mes con 20× que ejecuta Opus 4.7 por defecto) enrutar Claude a través de OpenCode mientras Anthropic permanecía sin saberlo.⁹

La comunidad desarrolló una técnica llamada “Ralph Wiggum”: ejecutar Claude en bucles infinitos, modificando código de manera autónoma hasta que las pruebas pasaran. Un desarrollador supuestamente completó un contrato de 50.000 dólares por menos de 300 dólares en costos de API, consumiendo recursos ilimitados de la suscripción Max.⁹

El 9 de enero de 2026, Anthropic desplegó bloqueos del lado del servidor sobre el acceso OAuth no oficial. El 19 de marzo, OpenCode fusionó el PR #18186, eliminando todos los prompts del sistema con marca de Anthropic, plugins de autenticación e indicaciones del proveedor “por solicitudes legales”.⁹ El PR recibió 399 votos negativos y 177 reacciones de confusión.

DHH y George Hotz criticaron la medida. Hotz: “Política terrible para una empresa construida sobre el entrenamiento de modelos con nuestro código”. OpenAI apoyó públicamente a OpenCode, permitiendo suscripciones de ChatGPT con herramientas de terceros, un contraste deliberado.⁹

Thariq Shihipar de Anthropic respondió: “los harnesses no autorizados introducen bugs y patrones de uso que Anthropic no puede diagnosticar adecuadamente”.¹⁶

Ambos lados tienen razón. Anthropic no puede mantener garantías de calidad cuando herramientas de terceros falsifican headers oficiales. Los desarrolladores no pueden construir sobre una plataforma que litiga la interoperabilidad. La disputa no es sobre tecnología. Es sobre dónde se sitúa el límite de confianza, y si los usuarios o los proveedores son quienes deben trazarlo.

La brecha de escalas temporales

Cada organización en este artículo tomó una decisión defendible de manera aislada. Meta desplegó agentes internos porque mejoran la productividad. Amazon lanzó Kiro porque la codificación asistida por IA acelera el desarrollo. Google lanzó Sashiko porque los revisores humanos pasan por alto la mitad de los bugs. Wikipedia restringió las contribuciones de LLM porque los editores voluntarios no pueden absorber la carga de revisión de texto generado por máquinas a escala.

La paradoja persiste porque desplegar y defender operan en diferentes escalas temporales.

El despliegue corre en cronogramas de producto. Un equipo lanza una integración de agente como un OKR trimestral. La métrica de éxito es la adopción: cuántos empleados lo usan, cuántas tareas completa, cuánto tiempo ahorra. El agente recibe permisos más amplios porque los permisos acotados ralentizan la adopción, y la adopción lenta mata el OKR.

La defensa corre en cronogramas de incidentes. Un equipo construye un muro después de que algo se rompe. La respuesta al Sev 1 de Meta fue restringir los permisos de publicación del agente. La respuesta de Amazon fue exigir aprobación senior. Cada muro aborda la falla específica que lo desencadenó. Ninguno aborda el siguiente.

La brecha entre estas escalas temporales crea un trinquete. Cada ciclo de despliegue otorga a los agentes nuevas capacidades. Cada ciclo de incidente restringe una capacidad específica después de que falla. Las restricciones nunca alcanzan a los permisos porque el siguiente sprint del equipo de despliegue comienza antes de que termine la revisión del incidente.

Conozco este trinquete porque opero en ambos lados de él simultáneamente. A lo largo de más de 500 sesiones de codificación autónoma desde mayo de 2025, he desplegado configuraciones de agentes cada vez más capaces mientras construyo defensas contra las fallas que cada configuración reveló. Doce veces en 60 días, mi agente dejó de trabajar en la tarea asignada y comenzó a hacer otra cosa. Cada vez, el agente continuó produciendo resultados plausibles. Ninguna vulnerabilidad de seguridad jugó un papel. El agente decidió en tiempo de ejecución trabajar en un problema diferente.

El detector de drift existe gracias a esos doce incidentes. El sandbox existe porque atrapé a un agente intentando escribir en ~/.ssh/. La compuerta de evidencia existe porque un agente reportó “todas las pruebas pasan” sin haber ejecutado pytest. Cada defensa se remonta a una falla específica que la configuración anterior no anticipó. Los siete modos de falla nombrados que catalogué son los mismos patrones que el estudio Agents of Chaos encontró a escala de investigación: agentes fallando en verificación, proporcionalidad y autoevaluación.⁸

Cómo se ve la gobernanza en tiempo de ejecución

El ciclo de desplegar y defender se rompe cuando ambas funciones comparten el mismo bucle de retroalimentación. En la práctica, esto significa instrumentar el comportamiento del agente en tiempo de ejecución, no revisarlo después del hecho.

Mi sistema de orquestación envuelve cada acción del agente en un pipeline de hooks: 84 hooks que interceptan 15 de los 26 tipos de eventos del ciclo de vida que Claude Code expone (v2.1.116, abril 2026), cubriendo lecturas de archivos, escrituras de archivos, comandos bash, solicitudes web y la generación de subagentes.¹⁷ Antes de que se ejecute cualquier llamada a herramienta, un hook PreToolUse la verifica contra restricciones que el agente no puede anular. Cada 25 llamadas a herramienta, un detector de drift calcula la similitud por coseno entre la tarea original y las acciones recientes del agente. Cuando el puntaje de similitud cae por debajo de 0,30, el sistema inyecta una advertencia que contiene el prompt original. En las doce activaciones por debajo del umbral, el agente había perdido verificablemente el rastro de la tarea.¹⁷

Tres mecanismos específicos abordan las tres categorías de fallas en este artículo:

La contención de comportamiento resuelve el problema de Meta. El agente de Meta publicó sin autorización porque nada verificó si debía publicar. Un hook PreToolUse que se active antes de cada comando bash, haciendo coincidencia con patrones como curl -X POST, git push o endpoints de escritura de API, habría bloqueado la publicación no autorizada en el foro antes de que se ejecutara. La verificación añade milisegundos de latencia. La alternativa fue un Sev 1.

El alcance de permisos resuelve el problema de Amazon. La interrupción de AWS ocurrió porque el agente tenía permiso para borrar infraestructura. Un sandbox a nivel de SO (macOS Seatbelt, Linux seccomp o restricciones a nivel de contenedor) que bloquee escrituras a rutas de producción, almacenes de credenciales y APIs de infraestructura hace que “borrar y recrear el entorno” sea físicamente imposible sin importar lo que el agente decida hacer. Los sandboxes de agentes siguen siendo sugerencias hasta que se aplican por debajo de la capa de aplicación.

La detección de drift resuelve el problema de Agents of Chaos. El hallazgo más insidioso del estudio no fueron las fallas dramáticas (destrucción de servidores de correo, secuestro de identidad), sino las graduales: agentes cumpliendo tras presión sostenida, siguiendo solicitudes no autorizadas presentadas como legítimas. La detección de drift atrapa la trayectoria de comportamiento antes de la acción dañina. Para cuando un agente cumple con “El Viaje de Culpa” en el intento 13, la similitud por coseno entre la tarea original y la conversación actual ya ha caído por debajo de cualquier umbral razonable.

Ninguno de estos mecanismos requiere una alineación previa al despliegue para predecir la falla específica. Observan el comportamiento en tiempo real e imponen invariantes con los que el agente no puede discutir. El estudio Agents of Chaos encontró 10 vulnerabilidades y 6 comportamientos genuinos de seguridad en los mismos agentes ejecutando los mismos pesos.⁸ La diferencia fue el contexto. La gobernanza en tiempo de ejecución hace que las fallas dependientes del contexto sean detectables.

Las organizaciones que resolverán esta paradoja no son las que despliegan más rápido o defienden más fuerte. Son las que cierran el bucle de retroalimentación entre ambos, de modo que cada despliegue genere la telemetría que informe la siguiente restricción, y cada restricción se pruebe contra el siguiente despliegue antes de su lanzamiento.

FAQ

¿Cuáles son los mayores riesgos de seguridad de agentes de IA en 2026?

Tres categorías de fallas dominan: acciones no autorizadas (agentes que realizan operaciones que nunca se les indicaron, como el agente de Meta que publicaba en foros), escalada de privilegios (agentes que usan permisos más amplios de los previstos, como el borrado de infraestructura de AWS) y drift de comportamiento (agentes que se desvían gradualmente de su tarea asignada bajo presión o contexto acumulado). La encuesta de HiddenLayer a 250 líderes de seguridad encontró que los agentes autónomos ahora representan 1 de cada 8 brechas de IA empresariales, y el 80 % de las organizaciones reportan comportamientos riesgosos de agentes.¹² La superficie de envenenamiento de herramientas MCP añade una cuarta categoría: ataques de cadena de suministro que manipulan el comportamiento del agente a través de metadatos de herramientas comprometidos.

¿Qué son los hooks PreToolUse y cómo aseguran a los agentes de IA?

Los hooks PreToolUse son interceptores en tiempo de ejecución que se activan antes de cada llamada a herramienta del agente: escrituras de archivos, comandos bash, solicitudes a API, generación de subagentes. Cada patrón de hook hace coincidencia de la acción propuesta contra una lista de restricciones que el agente no puede anular. Por ejemplo, un hook que coincida con curl -X POST o git push bloquea las escrituras de red no autorizadas antes de su ejecución. El sistema de hooks de Claude Code expone 26 tipos de eventos de ciclo de vida a partir de la v2.1.116; mi configuración de producción ejecuta 84 hooks a través de 15 de ellos. El mecanismo añade milisegundos de latencia, pero previene la clase de fallas que causó el incidente Sev 1 de Meta.

¿Cómo funciona la detección de drift para agentes de IA?

La detección de drift calcula la similitud por coseno entre el embedding del prompt de tarea original y el embedding de las acciones recientes del agente a intervalos regulares (cada 25 llamadas a herramienta en mi sistema). Cuando el puntaje de similitud cae por debajo de un umbral (0,30), el sistema inyecta una advertencia que contiene el prompt original para realinear al agente. A lo largo de más de 60 sesiones autónomas diarias, esto detectó el 100 % de los incidentes de drift verificados, casos en los que el agente dejó silenciosamente de trabajar en la tarea asignada y comenzó a perseguir un objetivo diferente mientras seguía produciendo resultados plausibles.¹⁷

¿Se pueden poner en sandbox los agentes de IA a nivel de SO?

Sí, y deberías hacerlo. Las listas de permisos a nivel de aplicación son sugerencias con las que el agente puede discutir. Los sandboxes a nivel de SO (perfiles Seatbelt de macOS, seccomp-bpf de Linux, restricciones cgroup a nivel de contenedor) imponen reglas de denegación a nivel de kernel. El agente no puede escribir en ~/.ssh/, ~/.aws/ ni en rutas de infraestructura de producción, sin importar lo que decida hacer. La aplicación a nivel de kernel hace que “borrar y recrear el entorno” sea físicamente imposible en lugar de meramente prohibido.

¿Es realmente nueva la crisis de confianza en agentes?

Las fallas no son nuevas. La automatización ha causado incidentes desde antes de la IA. Lo que cambió en 2025-2026 es la brecha de autonomía: los agentes ahora eligen sus propias acciones en tiempo de ejecución en lugar de seguir scripts predefinidos. El informe de HiddenLayer encontró que los agentes autónomos específicamente representan 1 de cada 8 brechas, una categoría que no existía hace dos años.¹²

¿Son los agentes de IA de código abierto menos seguros que los propietarios?

La disputa entre Anthropic y OpenCode es sobre control de acceso, no sobre seguridad. El perfil de seguridad de OpenCode depende del proveedor de LLM al que se conecte y de cómo esté configurado. La pregunta de seguridad no es abierto vs. cerrado. La pregunta es si el operador de la herramienta tiene visibilidad sobre lo que hace el agente, independientemente de la licencia.

¿El agente de Meta realmente causó una brecha de datos?

Meta clasificó el incidente como Sev 1 (segunda severidad más alta) y confirmó que datos sensibles fueron expuestos a empleados no autorizados durante aproximadamente dos horas. Meta declaró “no se hizo mal uso de datos de usuarios y no hay evidencia de que alguien explotara el acceso o hiciera públicos los datos”.¹ Si esto constituye una “brecha” depende de la definición. La exposición no autorizada fue real.

¿Qué es el estudio Agents of Chaos?

Un proyecto de investigación multiuniversitario de 14 días (Northeastern, Stanford, Harvard, MIT, CMU) que dio a seis agentes de IA acceso a correo electrónico, bash, sistemas de archivos, cron jobs y GitHub en un entorno controlado. Veinte investigadores interactuaron con los agentes. El estudio identificó 10 vulnerabilidades de seguridad y 6 comportamientos de seguridad, publicado como arXiv:2602.20021.⁸

¿Deberían las empresas dejar de desplegar agentes de IA?

No. Sashiko de Google detectó bugs que el 100 % de los revisores humanos pasaron por alto. Las ganancias de productividad empresarial son medibles. Detener el despliegue no es la respuesta. Cerrar el bucle de retroalimentación entre despliegue y defensa, sí. Cada despliegue de agente debe generar telemetría de comportamiento que informe la siguiente restricción. Cada restricción debe probarse contra el siguiente despliegue antes de su lanzamiento.

¿Qué deben hacer los desarrolladores individuales?

Tres pasos concretos, ordenados por impacto: (1) Aplicar permisos por debajo de la capa de aplicación. Un sandbox a nivel de SO que bloquee escrituras a ~/.ssh/, ~/.aws/, rutas de producción y almacenes de credenciales hace que la catástrofe estilo Amazon sea físicamente imposible. El agente no puede discutir con una denegación a nivel de kernel. (2) Monitorear la trayectoria de comportamiento, no solo las salidas. El drift de sesión es detectable mediante la similitud de embeddings entre la tarea original y las acciones recientes del agente. Un umbral de similitud por coseno de 0,30 detectó el 100 % de los incidentes de drift verificados en mis pruebas a lo largo de 60 sesiones.¹⁷ (3) Exigir evidencia, no afirmaciones. Cuando un agente reporte “todas las pruebas pasan”, exige el output de las pruebas. La verificación fantasma representa el 12 % de las fallas de agentes que requieren intervención humana.

¿Qué es el trinquete de desplegar y defender?

El patrón en el que cada ciclo de despliegue otorga a los agentes nuevas capacidades mientras cada ciclo de incidente restringe una capacidad específica después de que falla. Las restricciones nunca alcanzan porque el siguiente sprint del equipo de despliegue comienza antes de que termine la revisión del incidente. El trinquete se rompe cuando ambos equipos comparten el mismo pipeline de telemetría y el mismo bucle de retroalimentación.