El Hackeo a McKinsey No Fue un Problema de IA
CyberSec

🔐 El Hackeo a McKinsey No Fue un Problema de IA

Un bug de 25 años. Un blast radius que no existía antes.

El 9 de marzo de 2026, la startup de seguridad CodeWall publicó un informe que sacudió al mundo tech y de consultoría: su agente autónomo de IA había comprometido Lilli - la plataforma interna de IA de McKinsey & Company - en apenas dos horas, obteniendo acceso de lectura y escritura a una base de datos de producción con decenas de millones de registros.

Los titulares se escribieron solos. “Un agente de IA hackea McKinsey.” “IA vs. IA.”

Pero si le quitas el hype, la historia es mucho menos futurista - y mucho más preocupante por razones diferentes.

¿Qué Ocurrió Realmente?

Lilli es la plataforma de IA generativa de McKinsey, lanzada en 2023 y adoptada por más del 70% de sus 43,000+ empleados. Procesa más de 500,000 prompts al mes. Es, por cualquier métrica, un objetivo de alto valor.

El agente de CodeWall - sin credenciales, sin conocimiento interno, sin guía humana - mapeó la superficie de ataque de Lilli y descubrió que más de 200 endpoints API estaban públicamente documentados, y 22 de ellos no requerían autenticación.

Uno de esos endpoints tenía un fallo: aunque los valores en los payloads JSON estaban parametrizados contra SQL injection, los nombres de campo (keys) se concatenaban directamente en las consultas SQL. Eso fue todo. Esa fue la puerta.

El incidente comenzó con 15 iteraciones de blind SQL injection, facilitadas por mensajes de error demasiado descriptivos que revelaban claves de forma literal. Una vez obtenido acceso a datos de producción, el atacante explotó además una vulnerabilidad IDOR para acceder a historiales de búsqueda de usuarios concretos.

El resultado fue devastador:

Y porque el acceso era también de escritura, un atacante podría haber reescrito silenciosamente los system prompts de Lilli - las instrucciones que controlan cómo se comporta la IA para cada consultor de la firma - sin dejar rastro.

Esto No Fue una Vulnerabilidad de IA

SQL injection lleva en el OWASP Top 10 desde que esa lista existe. Es una de las clases de vulnerabilidad más antiguas, documentadas y prevenibles de la seguridad informática. Todo desarrollador junior aprende sobre ella. Todo escáner de seguridad dice detectarla.

No hubo ningún exploit novedoso de IA. No hubo machine learning adversarial. No hubo prompt injection ni jailbreak. La plataforma fue comprometida no porque fuera IA - fue comprometida porque faltaba sanitización básica de inputs en un endpoint público.

El agente que encontró la vulnerabilidad era impulsado por IA, sí. Pero automatizó lo que cualquier pentester competente habría hecho manualmente. Solo lo hizo más rápido y sin pausas para el café.

¿Por Qué Se Siente Diferente?

Porque la IA cambia el blast radius, no el vector de ataque.

Las aplicaciones tradicionales almacenan datos transaccionales - órdenes, cuentas, tokens de sesión. Una plataforma de IA como Lilli almacena todo: las preguntas que hace la gente, los documentos que analiza, las estrategias que discute, el razonamiento en el que se apoya. Es una concentración de output intelectual a una escala que no existía antes.

Cuando comprometes un CRM, obtienes registros de clientes. Cuando comprometes una plataforma empresarial de IA, obtienes la forma en que piensa una organización entera.

Eso es lo que hace significativa esta historia - no porque la IA fuera la vulnerabilidad, sino porque la IA fue el amplificador. El mismo bug de siempre, detrás de una puerta que ahora abre a un vault mil veces más grande que cualquier cosa que habíamos visto.

La Pregunta de la Negligencia

McKinsey no es una startup con tres ingenieros y una cuenta gratuita en la nube. Es una firma con equipos tecnológicos de primer nivel, inversión significativa en seguridad, y los recursos para hacer las cosas bien. Asesora a empresas Fortune 500 en temas que incluyen - sí - ciberseguridad y riesgo de IA.

Los hechos son incómodos:

Esto no fue un exploit sofisticado de zero-day. Fue un fallo de higiene básica de seguridad en una organización que tiene tanto la obligación como los recursos para hacerlo bien.

La Lección Real

La narrativa que la industria quiere contar es: “La IA es tan nueva y tan compleja que estas cosas son inevitables.”

La narrativa que la evidencia realmente soporta es: Las organizaciones están desplegando plataformas de IA sin aplicar el mismo rigor de seguridad que aplicarían a cualquier otro sistema de producción.

Según The Register, las plataformas de IA no son mágicas. Debajo del capó, son aplicaciones web con APIs, bases de datos, capas de autenticación y manejo de inputs - los mismos componentes que llevamos décadas aprendiendo a asegurar. La diferencia es que estas plataformas se están lanzando a velocidad de startup dentro de organizaciones enterprise, frecuentemente por equipos más enfocados en el rendimiento del modelo que en los fundamentos de seguridad.

El incidente McKinsey expone un patrón que se repetirá:

Qué Debe Cambiar

Para organizaciones que despliegan plataformas de IA

Trata tu plataforma de IA como cualquier otro sistema de producción. Pentesting, validación de inputs, autenticación en cada endpoint, cifrado en reposo - nada de esto es opcional solo porque el label diga “IA”. El OWASP Top 10 existe precisamente para esto.

Protege la capa de prompts. Los system prompts necesitan controles de acceso, historial de versiones, monitoreo de integridad y detección de cambios. Controlan lo que tu IA le dice a tu gente. Protégelos en consecuencia.

Audita tu blast radius. Entiende exactamente cuántos datos fluyen por tu plataforma de IA y qué expondría una brecha. Si la respuesta te incomoda, tu postura de seguridad necesita estar a la altura de esa incomodidad.

Para la industria

Deja de enmarcar cada incidente de seguridad de IA como un “problema de IA”. Cuando la causa raíz es una vulnerabilidad web clásica, dilo. Mistificar el problema retrasa la solución.

Reconoce que la IA es un amplificador. El threat model no ha cambiado fundamentalmente. Las consecuencias del fallo, sí.

Reflexión Final

Vulnerabilidad antigua. Blast radius nuevo. La IA es el amplificador, no la causa.

El hackeo a McKinsey es un llamado de atención - no porque la IA sea únicamente peligrosa, sino porque somos únicamente descuidados con la infraestructura que construimos a su alrededor. Sabemos cómo prevenir SQL injection. Lo hemos sabido por un cuarto de siglo. La pregunta es si aplicaremos lo que ya sabemos a los sistemas que ahora más importan.

McKinsey parcheó los endpoints en dos días tras recibir el disclosure. Tiempo de respuesta encomiable. Pero la pregunta real no es qué tan rápido parcheas - es por qué el parche fue necesario en primer lugar.


Lectura relacionada: Para entender cómo estas vulnerabilidades afectan el día a día corporativo, consulta IA y Ciberseguridad en la Oficina - una perspectiva de protección para profesionales no técnicos.


Fuentes: Financial Times, CodeWall research disclosure (9 de marzo de 2026), The Register, Inc. Magazine.


Por: Cesar Rosa Polanco - Basado en un caso real, con apoyo editorial de inteligencia artificial.

¿Primera vez aquí?

Conoce los temas y artículos clave del blog.

Empieza Aquí →
← Volver a artículos Disponible en inglés →