Cuatro fallos. Cuatro capas. La arquitectura en sí es la vulnerabilidad.

Un episodio reciente del 10 de abril de 2026 del podcast Hard Fork de The New York Times examinó las implicaciones de seguridad cibernética de los sistemas de inteligencia artificial avanzados y planteó una pregunta que la industria ha estado evitando: ¿qué pasa si la seguridad cibernética no está funcionando mal, sino que está fundamentalmente mal enfocada?

El episodio se emitió semanas después de una secuencia de incidentes que hicieron que la respuesta fuera difícil de ignorar. En un solo mes, un agente autónomo de inteligencia artificial violó la plataforma de inteligencia artificial interna de McKinsey en dos horas. Un ataque a la cadena de suministro de una biblioteca de inteligencia artificial de código abierto ampliamente utilizada se extendió a empresas downstream. Los investigadores mostraron que el hardware destinado a ser la última línea de defensa puede ser roto con piezas de repuesto que cuestan menos de mil dólares. Y Anthropic reveló que un modelo de vanguardia había encontrado autonomamente miles de vulnerabilidades de día cero en código que la industria consideraba estable.

Cuatro incidentes. Cuatro capas de la pila de inteligencia artificial: aplicación, orquestación, hardware y sistema operativo. Cada uno reveló limitaciones significativas en los controles diseñados para protegerlos.

El fin del pensamiento de perímetro

La seguridad cibernética tradicional se basa en un solo supuesto: con suficientes controles, monitoreo y inversión, los sistemas pueden ser seguros. Ese supuesto ha dado forma a décadas de arquitectura, incluyendo firewalls, gestión de identidad, seguridad de puntos finales y plataformas SIEM, todas construidas sobre la idea de que la visibilidad y la gestión estricta equivalen a seguridad.

El cambio de la industria hacia la arquitectura de confianza cero refleja el creciente reconocimiento de que los límites de red tradicionales ya no pueden considerarse confiables. Sin embargo, incluso a medida que los modelos de confianza evolucionan, los sistemas de inteligencia artificial introducen un desafío diferente: los datos sensibles se agregan, procesan y comparten rutinariamente a través de múltiples capas de infraestructura.

Ese enfoque tenía sentido cuando los sistemas eran relativamente centralizados y los datos permanecían dentro de límites claramente definidos. Se vuelve mucho menos efectivo cuando los datos se mueven continuamente a través de nubes, API, proveedores de terceros y tuberías de inteligencia artificial, mientras que los usuarios y los recursos de cómputo están distribuidos globalmente. El perímetro ya no es un límite. Es una superficie en constante cambio, y todavía estamos aplicando un pensamiento basado en controles a sistemas que no pueden realista y controlarse.

Fallo de la capa de aplicación: Lilli de McKinsey

El 9 de marzo de 2026, la startup de seguridad CodeWall publicó una divulgación que destacó los riesgos que enfrentan las organizaciones que despliegan inteligencia artificial internamente. .

El agente ofensivo autónomo de CodeWall, sin credenciales, sin conocimiento interno y sin orientación humana, logró acceso de lectura y escritura a la base de datos de producción detrás de Lilli, la plataforma de inteligencia artificial interna de McKinsey, en menos de dos horas. Lilli se utiliza para más de 40,000 empleados para trabajo de estrategia, investigación de clientes y análisis de documentos, generando cientos de miles de solicitudes por mes.

El punto de entrada no fue sofisticado. El agente encontró documentación de API expuesta públicamente que enumeraba más de 200 puntos finales, 22 de los cuales no requerían autenticación. Las vulnerabilidades involucradas se reflejan en los riesgos resaltados en la OWASP Top 10 para aplicaciones de LLM, particularmente alrededor de interfaces expuestas, integraciones inseguras y exceso de confianza en sistemas conectados.

Uno de esos puntos finales contenía una vulnerabilidad de inyección de SQL oculta en nombres de campos JSON en lugar de valores de entrada, donde la mayoría de los escáneres automatizados buscan. A partir de ahí, el agente iteró a través de la inyección de SQL ciega hasta que los datos de producción se volvieron accesibles.

Lo que accedió: decenas de millones de mensajes de chat en texto plano, cientos de miles de archivos, decenas de miles de cuentas de usuario y millones de fragmentos de documentos RAG que representan años de investigación exclusiva. También identificó las solicitudes del sistema que gobernaban cómo Lilli se comportaba para cada usuario.

El hallazgo más alarmante no fue el volumen. Fue que las solicitudes del sistema eran legibles. Un atacante podría haber reescrito silenciosamente las instrucciones que gobernaban las salidas de Lilli, envenenando el asesoramiento estratégico, incorporando datos confidenciales en las respuestas o eliminando las barreras de seguridad por completo, con una sola actualización de la base de datos. Sin implementación. Sin cambio de código. Sin rastro en los registros de la aplicación.

En una declaración pública, McKinsey dijo que remedió el problema en cuestión de horas y, tras una investigación de una empresa de forensia de terceros, no encontró evidencia de que se hubiera accedido a datos confidenciales de clientes. Esa respuesta importa. Pero no cambia la lección estructural: una clase de vulnerabilidad de décadas de antigüedad expuso la memoria operativa de un sistema de inteligencia artificial moderno porque los datos detrás de él existían en forma legible.

Fallo de la capa de orquestación: El ataque LiteLLM

Tres semanas después, el mismo patrón apareció desde un ángulo diferente y a través de una capa diferente.

LiteLLM es una puerta de enlace de inteligencia artificial de código abierto utilizada por miles de empresas para enrutar solicitudes a través de proveedores de inteligencia artificial. Su posición en la pila es crítica: se encuentra en la capa de orquestación, manteniendo claves de API para cada proveedor al que se conecta. Cualquier compromiso en esta capa expone credenciales en cada servicio integrado.

Según un informe de incidente de PyPI, el grupo de actores amenazantes TeamPCP explotó credenciales vinculadas a una dependencia en la tubería de CI/CD de LiteLLM y utilizó el acceso de mantenimiento para publicar dos versiones comprometidas del paquete LiteLLM directamente en PyPI. Las versiones dañadas estuvieron disponibles durante menos de una hora antes de ser eliminadas. La operación se descubrió solo porque el malware contenía un error que hizo que se estrellara la máquina de un investigador.

La cadena de suministro fue el vector. La capa de orquestación fue el objetivo. Al comprometer una sola dependencia upstream, los atacantes llegaron a la capa donde vivían las claves de proveedor de cada empresa downstream.

El equipo de LiteLLM detalló más tarde el incidente y los esfuerzos de mitigación en una divulgación pública en GitHub.

El radio de explosión se volvió visible casi de inmediato. TechCrunch, Fortune y The Register informaron que Mercor, una startup de contratación de inteligencia artificial de 10 mil millones de dólares que trabaja con empresas como OpenAI, Anthropic, Meta y Google, fue una de las organizaciones afectadas. Los atacantes afirmaron haber obtenido grandes cantidades de datos, incluyendo perfiles de candidatos, información de identificación personal, entrevistas de video de contratistas, código fuente y claves de API. Meta pausó el trabajo con Mercor pendiente de investigación. Informes posteriores indicaron patrones de malware similares que aparecían en otras herramientas y paquetes de desarrolladores, lo que sugiere que la operación puede haberse extendido más allá de un solo proyecto.

El incidente de LiteLLM no fue una anomalía. Fue el sistema comportándose como se diseñó. Cada componente en una tubería de inteligencia artificial requiere acceso a datos utilizables para funcionar, lo que significa que cada componente también es un posible punto de extracción. Fijar dependencias y rotar credenciales son respuestas necesarias, pero abordan el incidente, no la arquitectura.

Fallo de la capa de hardware: TEE.fail

Si la violación de McKinsey demostró que la capa de aplicación no se puede confiar, y el ataque de LiteLLM demostró que la cadena de suministro no se puede confiar, la investigación de TEE.fail demostró que el hardware destinado a compensar ambos no se puede confiar completamente.

El 28 de octubre de 2025, investigadores de Georgia Tech, Purdue University y Synkhronix publicaron TEE.fail, un ataque de canal lateral que extrae claves criptográficas de entornos de ejecución de confianza utilizando interposición de autobús de memoria física en servidores DDR5. El ataque afecta a Intel SGX, Intel TDX y AMD SEV-SNP, incluidos sistemas completamente parcheados con estado de confianza y AMD con Ciphertext Hiding habilitado. Estas son las tecnologías ampliamente promocionadas como la base de la computación confidencial.

Los investigadores extrajeron claves de autenticación: el material criptográfico utilizado para verificar que las cargas de trabajo se ejecutan dentro de entornos seguros. Con esas claves, un sistema comprometido puede presentarse como de confianza mientras opera completamente fuera de las protecciones esperadas. Los investigadores demostraron esto directamente: forjaron autenticaciones de TDX en BuilderNet de Ethereum para acceder a datos de transacciones confidenciales, y falsificaron autenticaciones de Intel y NVIDIA para ejecutar cargas de trabajo fuera de cualquier TEE mientras parecían legítimas.

La implicación de NVIDIA es importante para la inteligencia artificial en particular. Dado que la autenticación de la GPU depende de la autenticación de la CPU, una cadena de confianza de CPU comprometida puede socavar las garantías proporcionadas por entornos de inferencia de inteligencia artificial confidenciales. La base de hardware de la inferencia de inteligencia artificial confidencial es, en este modelo de amenaza, condicional a una TEE de CPU que ha sido demostrablemente rota.

Los proveedores de hardware respondieron con asesorías formales. AMD declaró que los ataques de acceso físico caen fuera de su modelo de amenaza estándar e indicó que no emitiría actualizaciones de firmware. Intel y NVIDIA reconocieron los hallazgos y indicaron que estaban trabajando en la mitigación. Estas respuestas son razonables dentro de sus modelos de amenaza. También resaltan un límite importante: las garantías de seguridad basadas en hardware dependen de suposiciones, incluido el control físico, que los despliegues soberanos, regulados y enfrentados a adversarios no pueden hacer siempre.

TEE.fail no hace que el aislamiento de hardware sea irrelevante. Demuestra que es condicional.

Fallo de la capa del sistema operativo: La revelación de Mythos

Si los primeros tres incidentes cuestionaron la capa de aplicación, la capa de orquestación y la capa de hardware, una cuarta divulgación en abril de 2026 cuestionó la capa debajo de todas ellas: los sistemas operativos y bibliotecas básicas en las que se ejecuta cada capa.

El 7 de abril de 2026, Anthropic anunció Claude Mythos Preview, un modelo de vanguardia que se negó a lanzar públicamente debido a sus capacidades de seguridad ofensiva, y lanzó simultáneamente Project Glasswing, un consorcio con AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, la Fundación Linux, Microsoft, NVIDIA y Palo Alto Networks. Anthropic informó que, en cuestión de semanas, Mythos había identificado autonomamente miles de vulnerabilidades desconocidas previamente en sistemas operativos y navegadores web importantes y era capaz de producir exploits funcionales para muchos de ellos.

Los hallazgos específicos son más difíciles de descartar de lo que sugiere cualquier resumen. Un error de 27 años en OpenBSD. Un error de ejecución de código remoto de 17 años en el servidor NFS de FreeBSD, ahora rastreado como CVE-2026-4747, que otorga acceso de root a un atacante no autenticado. Una vulnerabilidad de 16 años en FFmpeg, una de las bibliotecas de medios más ampliamente implementadas en Internet. En un caso, un ingeniero de Anthropic sin capacitación formal en seguridad le pidió al modelo que buscara fallos de ejecución de código remoto durante la noche y se despertó con un exploit completo funcionando.

Estos son hallazgos a nivel de sistema operativo. OpenBSD y FreeBSD son núcleos. NFS es un subsistema de red de núcleo. FFmpeg es una biblioteca de sistema que se envía con la mayoría de las distribuciones de Linux y subyace a las tuberías de medios en Internet. La capa del sistema operativo se asumió segura no porque se hubiera demostrado segura, sino porque encontrar fallos profundos en ella requería experiencia humana escasa y costosa. Ese supuesto fue la mejor heurística disponible. Nunca fue una garantía.

Esa restricción se ha relajado ahora. Anthropic enmarcó esto como un cambio de doble uso: las mismas capacidades que permiten a un modelo de vanguardia encontrar y parchear vulnerabilidades a escala también permiten, en las manos equivocadas, encontrar y explotarlas a escala. La decisión de Anthropic de restringir el acceso a través de Project Glasswing refleja esa realidad. No la resuelve. Capacidades similares, según la propia evaluación de la empresa, proliferarán. El costo de auditar código heredado se ha derrumbado, y con él la defensa implícita de que dicho código era demasiado oscuro, demasiado antiguo o demasiado ampliamente revisado para seguir conteniendo fallos críticos.

Esto es donde los cuatro incidentes se combinan. Los tres incidentes anteriores describen cómo se están violando los sistemas de inteligencia artificial hoy en día. Mythos describe la velocidad a la que todo lo que está debajo de ellos, incluidos los sistemas operativos, módulos del núcleo y bibliotecas del sistema, está a punto de ser reexaminado por máquinas. La violación de McKinsey explotó una clase de vulnerabilidad de inyección de SQL que ha existido durante más de dos décadas. Las vulnerabilidades de ese tipo son precisamente las que los modelos de la clase de Mythos son capaces de encontrar a escala industrial.

Los tres incidentes anteriores describen cómo se están violando los sistemas de inteligencia artificial hoy en día. Mythos describe la tasa a la que todo lo que está debajo de ellos, incluidos los sistemas operativos, módulos del núcleo y bibliotecas del sistema, está a punto de ser reexaminado por máquinas. La violación de McKinsey explotó una clase de vulnerabilidad de inyección de SQL que ha existido durante más de dos décadas. Las vulnerabilidades de ese tipo son precisamente las que los modelos de la clase de Mythos son capaces de encontrar a escala industrial.

El patrón

En cada caso, los datos estaban en texto plano en el momento en que importaba.

La capa de aplicación los procesó en claro. La capa de orquestación los enrutió en claro. La capa de hardware, a pesar de sus protecciones, requirió eventualmente la decodificación en el punto de ejecución. La capa del sistema operativo debajo de las tres operó en claro por definición. Cuatro capas, cuatro fallos, y en cada capa la misma condición se mantuvo: cuando se produjo la violación, los datos eran legibles.

Esto no es una colección de fallos aislados. Es la arquitectura en sí.

Los sistemas de inteligencia artificial modernos están diseñados para operar en datos legibles. Cada capa, incluida la recuperación, el enrutamiento, la inferencia y la ejecución de herramientas, requiere acceso en texto plano para funcionar. Esa elección de diseño significa que cualquier violación en cualquier capa expone los datos detrás de ella.

La pregunta no es si se comprometerá una capa. Es qué encuentra el atacante cuando lo hace.

De violación asumida a exposición cero

La industria ya ha comenzado a cambiar de “prevenir la violación” a “asumir la violación”. Pero la mayoría de las arquitecturas no han seguido las implicaciones.

Si la violación es inevitable, entonces la verdadera pregunta no es cómo mantener a los atacantes fuera. Es qué sucede cuando entran. Ahora, la respuesta es simple: obtienen los datos. Debido a que, a pesar de todas las inversiones en infraestructura de seguridad, los datos todavía están expuestos en el momento exacto en que se vuelven valiosos, cuando se están utilizando.

La respuesta de la industria ha sido predecible: más monitoreo, detección más rápida, capas adicionales de computación confidencial. Estas son mejoras. Pero no resuelven el problema central. Todavía asumen que alguna capa, ya sea de software, hardware u operativa, puede confiarse para mantener los datos en texto plano a salvo.

La alternativa es eliminar completamente los datos en texto plano. No para asegurar las capas alrededor de los datos, sino para hacer que los datos en sí sean inaccesibles para cualquiera que los alcance. La computación en datos cifrados, donde las solicitudes, los pesos del modelo y las salidas permanecen cifrados en toda la tubería, aborda la exposición que cada uno de estos incidentes explotó.

Los avances en criptografía homomórfica completa y otras técnicas de computación de preservación de la privacidad están comenzando a hacer que las arquitecturas que minimizan o eliminan la exposición de texto plano sean cada vez más prácticas para cargas de trabajo de inteligencia artificial del mundo real. Si bien siguen siendo importantes desafíos de rendimiento, escalabilidad e implementación, el objetivo es fundamentalmente diferente de los controles de seguridad tradicionales: reducir el valor de una violación exitosa en lugar de simplemente hacer que la violación sea menos probable.

El cambio no es de una herramienta de seguridad a otra. Es de asegurar sistemas a reducir la exposición. De infraestructura de confianza a datos de confianza cero. De gestionar el riesgo a minimizar la superficie de ataque en sí.

Qué viene a continuación

La discusión de Hard Fork planteó la pregunta de si la seguridad cibernética está fundamentalmente mal enfocada. La evidencia de las últimas semanas sugiere que la respuesta es sí, al menos para la inteligencia artificial.

El modelo antiguo asumió que los sistemas pueden ser seguros, las violaciones pueden contenerse y la exposición puede gestionarse. La realidad emergente es que las violaciones deben asumirse y la exposición minimizarse. Los incidentes descritos aquí sugieren que asegurar los sistemas de inteligencia artificial puede depender cada vez más de reducir la cantidad de datos sensibles disponibles cuando los controles fallen.

Las vulnerabilidades expuestas a través de estos cuatro incidentes no se limitan a una sola capa. Son sistémicas. Abordarlas requerirá más que mejoras incrementales. Requerirá un cambio de asegurar sistemas a reducir la exposición, de defender el perímetro alrededor de los datos a eliminar el texto plano que el perímetro fue construido para proteger.

La seguridad de la inteligencia artificial ya no se trata de mantener a los atacantes fuera. Se trata de asegurarse de que cuando entren, y lo harán, no haya nada legible para que lo encuentren.