El ataque que nadie esperaba: una IA hackeando a otra IA
En marzo de 2026, la firma de seguridad ofensiva CodeWall encendió todas las alarmas del mundo corporativo: su agente de inteligencia artificial autónomo logró infiltrar Lilli, la plataforma interna de IA de McKinsey & Company, en apenas dos horas y con un costo de solo 20 dólares en tokens. El resultado: acceso de lectura y escritura a la base de datos de producción, sin credenciales previas ni intervención humana.
No fue un ataque de ciencia ficción. Fue una cadena de vulnerabilidades clásicas, mal gestionadas en un entorno donde la velocidad de adopción de IA superó por mucho a la madurez en seguridad. Un recordatorio brutal para cualquier empresa, desde startups hasta grandes corporaciones, que está desplegando plataformas de IA sin los controles adecuados.
Lilli: la plataforma de IA que usaban más de 43.000 empleados
Lilli es el asistente de IA interno de McKinsey, diseñado para centralizar el conocimiento de la consultora y potenciar el trabajo de sus más de 43.000 empleados a nivel global. Una herramienta que concentra décadas de investigación propietaria, metodologías exclusivas, datos de clientes y conversaciones estratégicas.
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidadEse mismo nivel de centralización la convirtió en un objetivo de altísimo valor, y en un punto de fallo catastrófico cuando la seguridad no estuvo a la altura.
Cómo operó el agente autónomo: la cadena del ataque
El agente de CodeWall no siguió un manual de instrucciones preestablecido. Actuó con autonomía: exploró, identificó patrones, encadenó fallos y escaló privilegios a velocidad de máquina. Así se desarrolló el ataque paso a paso:
1. Documentación de API expuesta públicamente
El agente detectó que la documentación de la API de Lilli era accesible sin autenticación. Eso reveló la existencia de más de 200 endpoints internos del sistema. De estos, 22 endpoints no requerían credenciales para ser accedidos.
2. Inyección SQL por concatenación insegura de claves JSON
Uno de esos endpoints construía consultas de búsqueda de usuarios concatenando directamente claves JSON en SQL sin ningún tipo de sanitización. El agente detectó que los errores de la base de datos reflejaban esas claves verbatim, lo que confirmó la vulnerabilidad. Ejecutó 15 iteraciones ciegas, extrayendo progresivamente información sobre la estructura de las consultas, hasta que los datos de producción comenzaron a fluir libremente.
3. Escalada con IDOR (Insecure Direct Object Reference)
La inyección SQL fue encadenada con una vulnerabilidad de IDOR, que permitió acceder al historial de búsquedas de empleados individuales, revelando en qué proyectos y temas estaba trabajando cada persona.
4. Acceso total: lectura y escritura
El resultado final fue acceso completo de lectura y escritura sobre la base de datos de producción. No solo ver los datos, sino también poder modificarlos en silencio.
El inventario del desastre: qué quedó expuesto
La magnitud de los datos comprometidos es difícil de dimensionar. Según el reporte de CodeWall:
- 46,5 millones de mensajes de chat en texto plano: estrategias empresariales, fusiones y adquisiciones, trabajo con clientes, planificación financiera e investigación interna.
- 728.000 archivos confidenciales de clientes.
- 57.000 cuentas de usuario.
- 95 system prompts que controlan el comportamiento de Lilli, todos con acceso de escritura habilitado.
- 1,1 millones de archivos y 217.000 mensajes de agentes fluyendo a través de APIs externas de IA, incluyendo más de 266.000 almacenes de vectores de OpenAI.
- La base de conocimiento completa de la plataforma, con rutas S3 y metadatos internos que describen décadas de investigación propietaria.
McKinsey confirmó que corrigió todos los problemas en cuestión de horas tras ser notificada, y una investigación forense de terceros no encontró evidencia de que datos de clientes hubieran sido accedidos de forma maliciosa. Pero el daño en términos de reputación y confianza ya estaba hecho.
El riesgo más silencioso: los system prompts como vector de ataque
Más allá del volumen de datos expuesto, el hallazgo que generó mayor alarma entre expertos en seguridad fue la accesibilidad de los system prompts con permisos de escritura.
Un atacante con acceso de escritura podría haber reescrito silenciosamente las instrucciones que gobiernan el comportamiento de Lilli con una simple sentencia UPDATE en una llamada HTTP. Las consecuencias potenciales van mucho más allá de un robo de datos: modelos financieros envenenados, recomendaciones estratégicas manipuladas, exfiltración silenciosa de información a través de las propias respuestas de la IA, sin dejar rastros en logs tradicionales.
Este escenario redefine la noción de qué es un activo crítico en una empresa que opera con IA: los prompts del sistema son tan valiosos, y tan vulnerables, como cualquier base de datos de producción.
La divulgación responsable y la respuesta de McKinsey
El proceso siguió los estándares de la industria. CodeWall identificó la vulnerabilidad de inyección SQL a finales de febrero de 2026 y realizó la divulgación completa de la cadena de ataque el 1 de marzo a través de HackerOne. McKinsey parcheó los endpoints vulnerables al día siguiente, desconectó el entorno de desarrollo expuesto y bloqueó la documentación pública de la API.
El propio agente de IA de CodeWall fue quien sugirió a McKinsey como objetivo tras escanear información disponible públicamente, incluyendo la política de divulgación responsable de la empresa y actualizaciones recientes sobre Lilli. La ironía es significativa: una IA encontró el camino por sí misma.
No es un problema de IA: es un problema de seguridad básica mal aplicada
Un análisis técnico publicado por Promptfoo fue categórico: el incidente de Lilli es fundamentalmente un fallo de seguridad de aplicaciones que afecta a un sistema de IA, no un jailbreak ni una vulnerabilidad del modelo de lenguaje. Las causas raíz fueron completamente predecibles: APIs expuestas, construcción SQL insegura, autorización rota a nivel de objetos y ausencia de autenticación en endpoints críticos.
Lo que cambió con la IA autónoma es la velocidad y escala con que se descubren y encadenan esas vulnerabilidades. Un auditor humano podría haberse tardado semanas en mapear los 200 endpoints. El agente de CodeWall lo hizo en minutos.
Qué debe hacer cualquier empresa que despliega IA hoy
Este incidente no es un caso aislado de una consultora de élite. Es una señal de alerta para cualquier startup o empresa que esté construyendo o adoptando plataformas de IA a escala. Las acciones concretas que los equipos técnicos deben priorizar:
Autenticación y control de acceso
- Autenticación obligatoria en todos los endpoints, sin excepciones ni entornos de desarrollo expuestos.
- Validar control de acceso a nivel de objeto (IDOR) para garantizar que cada usuario solo acceda a sus propios datos.
- Auditar regularmente la documentación pública de API para eliminar detalles internos de implementación.
Protección de system prompts
- Almacenar los prompts del sistema en almacenes de secretos dedicados (como HashiCorp Vault o AWS Secrets Manager), completamente separados de las bases de datos operacionales.
- Implementar control de acceso granular con auditoría completa de cambios y versionado inmutable.
Seguridad de base de datos
- Usar prepared statements y consultas parametrizadas en lugar de concatenación directa. Sin excepciones.
- Aplicar el principio de menor privilegio en credenciales de base de datos usadas por la capa de IA.
Red teaming continuo
- Implementar pruebas de penetración específicamente diseñadas para plataformas de IA, enfocadas en manipulación de prompts y ataques en cadena.
- Considerar programas de bug bounty con alcance explícito sobre la infraestructura de IA.
Conclusión
El hackeo a McKinsey no es solo una historia sobre una consultora global que sufrió una brecha. Es una fotografía del momento que vivimos: empresas de cualquier tamaño desplegando plataformas de IA a gran velocidad, sin que la madurez en seguridad haya crecido al mismo ritmo.
Para los founders que están construyendo productos con IA hoy, el mensaje es claro: los system prompts, los endpoints de tu API y los stores de vectores son activos críticos que necesitan protección con el mismo rigor que una base de datos financiera. La velocidad de adopción de IA no puede ser excusa para ignorar fundamentos de seguridad que llevan décadas documentados.
Si McKinsey lo sufrió con un equipo de ingeniería de primer nivel, cualquier plataforma puede ser el próximo objetivo. El costo de un agente de IA atacante hoy es de 20 dólares. El costo de no prepararse puede ser infinitamente mayor.
Descubre cómo otros founders protegen sus plataformas de IA y escalan con seguridad en nuestra comunidad.
Fuentes
- https://www.infobae.com/tecno/2026/03/13/un-agente-de-ia-hackeo-en-dos-horas-la-base-de-datos-central-de-mckinsey-y-expuso-secretos-globales-como-lo-hizo/ (fuente original)
- https://www.theregister.com/2026/03/09/mckinsey_ai_chatbot_hacked/ (fuente adicional)
- https://the-decoder.com/an-ai-agent-hacked-mckinseys-internal-ai-platform-in-two-hours-using-a-decades-old-technique/ (fuente adicional)
- https://www.thestack.technology/mckinsey-ai-agent-hacked-lilli/ (fuente adicional)
- https://www.promptfoo.dev/blog/mckinsey-lilli-appsec-vs-ai-jailbreak/ (fuente adicional)
- https://es.marketscreener.com/noticias/mckinsey-se-apresura-a-corregir-sus-sistemas-de-ia-tras-las-vulnerabilidades-expuestas-por-un-hacker-ce7e5fddd08af023 (fuente adicional)
- https://timesofindia.indiatimes.com/technology/tech-news/mckinsey-realises-the-risk-of-rapid-adoption-of-ai-after-hackers-gain-access-to-46-5-million-employee-chat-messages-728000-sensitive-files-and-/articleshow/129553395.cms (fuente adicional)
