Lilli, de McKinsey, se hizo pública el 9 de marzo. El historial no conlleva ningún daño.

El 9 de marzo de 2026, la startup de seguridad CodeWall publicó su relato de cómo un agente autónomo que desarrolló alcanzó acceso completo de lectura y escritura a la base de datos de producción que respalda a Lilli, el asistente de IA de McKinsey & Company para toda la firma, en aproximadamente dos horas y sin una sola credencial. La intrusión en sí ocurrió el 28 de febrero; lo que registra esta entrada del archivo de incidentes de IA es el día en que se hizo pública. Según CodeWall, la base de datos a la que llegó contenía 46,5 millones de mensajes de chat en texto plano, 728.000 archivos, 57.000 cuentas de usuario y los 95 prompts del sistema que determinan cómo responde Lilli, y esos prompts estaban en la misma base de datos en la que el agente podía escribir. Las personas en los datos eran el propio personal de McKinsey: la firma afirma que el 72 por ciento de sus empleados, más de 40.000 personas, usan Lilli, que gestiona más de 500.000 prompts al mes. La entrada completa, con sus calificaciones de gravedad y confianza y los registros vecinos entre los que se encuentra, está en el Orca AI Incident Archive.

Ese comienzo es una condensación de dos tipos muy distintos de afirmación, y la entrada del archivo es cuidadosa con la diferencia. Clasifica el registro como un incidente, confianza A, no disputado, gravedad alta, región EE. UU., tipo INFRA —infraestructura, no un fallo del modelo. También registra que no hubo ningún daño real. Ese último campo es el que merece leerse dos veces, porque no significa que la exposición fuera inofensiva. Significa que no se estableció ningún daño en el registro, y el artículo que aparece a continuación separa aquello en lo que coinciden las dos partes de lo que se sustenta en la versión de una sola empresa sobre su propia investigación.

Por qué la divulgación es su propio evento fechado

El {{1}}resumen del archivo{{/1}} para esta entrada se remonta al {{2}}28 de febrero de 2026{{/2}}, el día en que el agente de {{3}}CodeWall{{/3}} encontró el fallo, y el archivo conserva esa fecha anterior como un registro separado. La división no es burocrática. Antes del {{4}}9 de marzo{{/4}}, las únicas partes que sabían lo que había ocurrido dentro de {{5}}Lilli{{/5}} eran {{6}}McKinsey{{/6}} y el investigador que se lo había contado. Después del {{7}}9 de marzo{{/7}}, la forma del fallo, la respuesta de la empresa y la afirmación sobre lo que había en la base de datos quedaron todos en el registro público, donde otros investigadores de seguridad podían discutirlos.

Lilli no es un proyecto secundario. The Register situó su despliegue en julio de 2023, para chat, análisis de documentos y recuperación en la investigación interna de la firma. El artículo de CodeWall, que también registra de dónde proviene el nombre —la primera mujer profesional que contrató la firma, en 1945—, describe más de 100.000 documentos internos que la respaldan. The Register, al informar sobre la divulgación ese mismo día, situó la adopción en el 72 % de los empleados y el volumen por encima de 500.000 prompts al mes —cifras que McKinsey ha publicado por cuenta propia en un caso de estudio público de la plataforma.

Cómo entró el agente

El relato de CodeWall comienza con documentación, no con explotación. Su agente descubrió que la documentación de la API de Lilli estaba expuesta públicamente y completamente detallada: más de 200 endpoints en total, la mayoría requerían autenticación, y 22 que no. Uno de esos endpoints no autenticados escribía las consultas de búsqueda de los usuarios en la base de datos. Los valores estaban parametrizados correctamente, pero las claves JSON —los nombres de los campos— se concatenaban directamente en SQL.

El agente se dio cuenta porque los mensajes de error de la base de datos le devolvían literalmente esas claves JSON. CodeWall dice que el escáner ZAP de OWASP no marcó el problema, y que el agente ejecutó entonces quince iteraciones ciegas, en las que cada mensaje de error le enseñaba un poco más sobre la forma de la consulta, hasta que empezaron a devolverse filas reales de producción. A partir de ahí, encadenó la inyección con una falla de autorización a nivel de objeto para leer los historiales de búsqueda de empleados individuales. La empresa describe toda la ejecución como totalmente autónoma, desde la selección del objetivo hasta el informe, sin credenciales y sin intervención humana. Su fundador y director ejecutivo, Paul Price, dijo a The Register que el proceso fue "totalmente autónomo desde la investigación del objetivo, el análisis, el ataque y la elaboración del informe".

Lo que CodeWall dice que estaba dentro

Todas las cifras de esta sección proceden del informe de CodeWall del 9 de marzo. No se publicó ningún payload, por lo que nada de ello puede reproducirse ni contabilizarse de forma independiente — una limitación que se aborda en la sección siguiente.

• 46,5 millones de mensajes de chat, almacenados en texto plano, que abarcan trabajo de estrategia, encargos con clientes, finanzas y fusiones y adquisiciones.

• {{1}}728.000 archivos{{/1}}, de los cuales el informe desglosa {{2}}192.000 PDF{{/2}}, {{3}}93.000 hojas de cálculo de Excel{{/3}}, {{4}}93.000 presentaciones de PowerPoint{{/4}} y {{5}}58.000 documentos de Word{{/5}} — {{6}}436.000 en total{{/6}}, lo que deja los {{7}}292.000 restantes sin clasificar{{/7}} en la misma oración.

• 57.000 cuentas de usuario, 384.000 asistentes de IA y 94.000 espacios de trabajo, que CodeWall describe como la estructura organizativa completa de cómo la empresa utiliza la IA internamente.

• 95 system prompts y configuraciones de modelos en 12 tipos de modelo, que muestran cómo se le dio instrucciones al asistente, qué salvaguardas existían y qué modelos lo sustentaban.

• 3,68 millones de fragmentos de documentos de generación aumentada por recuperación, con rutas de almacenamiento S3 y metadatos internos de archivos — la base de conocimiento que alimenta al asistente.

• 1,1 millones de archivos y 217.000 mensajes de agentes que circulan por API externas de IA, incluidos más de 266.000 almacenes vectoriales en la plataforma de OpenAI.

El hallazgo que CodeWall considera el titular no es la inyección, sino dónde aterrizó la inyección. Los prompts del sistema de Lilli eran filas de la misma base de datos en la que el agente podía escribir, lo que significa que un atacante con el mismo acceso podría haber reescrito las instrucciones del asistente con una sola sentencia UPDATE envuelta en una sola llamada HTTP: sin despliegue, sin cambios de código, sin ningún archivo en disco que comparar. CodeWall afirma que sus propias pruebas fueron únicamente de verificación: leyó, no escribió, y asegura que ningún servicio en producción se vio afectado.

Lo que McKinsey dijo el mismo día

Un portavoz de McKinsey dijo a The Register el 9 de marzo que la firma solucionó todos los problemas identificados por CodeWall en cuestión de horas tras conocerlos. «Nuestra investigación, respaldada por una destacada empresa forense externa, no encontró ninguna evidencia de que este investigador ni ninguna otra parte no autorizada haya accedido a datos de clientes ni a información confidencial de clientes», señaló el portavoz, y añadió que «los sistemas de ciberseguridad de McKinsey son sólidos».

Silicon UK informó de la misma postura el 13 de marzo, en el artículo de Matthew Broersma: McKinsey dijo que "un investigador de seguridad nos alertó recientemente de una vulnerabilidad relacionada con nuestra herramienta interna de IA, Lilli", que "confirmó rápidamente la vulnerabilidad y solucionó el problema en cuestión de horas", y que no se accedió a ningún dato de clientes ni a información confidencial de clientes. Ese artículo también señala que Price es el único empleado de CodeWall, un detalle que merece la pena mencionar porque tiene doble filo: una organización de investigación unipersonal encontró en dos horas lo que los propios escáneres de la empresa no encontraron, y una organización unipersonal también está vendiendo la herramienta que lo encontró.

Dos versiones de la solución, con un día de diferencia.

La cronología de divulgación propia de CodeWall es la siguiente: el agente identifica la inyección SQL y comienza a enumerar la base de datos de producción el 28 de febrero; la cadena completa se confirma ese mismo día con 27 hallazgos documentados; un correo de divulgación responsable se envía al equipo de seguridad de McKinsey el 1 de marzo con un resumen de impacto de alto nivel; el director de seguridad de la información de la empresa acusa recibo y solicita pruebas detalladas el 2 de marzo; y el 2 de marzo todos los endpoints no autenticados se parchean y verifican, el entorno de desarrollo se desconecta y la documentación pública de la API se bloquea. La divulgación pública se produce el 9 de marzo.

La versión de McKinsey es que la corrección llegó pocas horas después de recibir el aviso. La cronología de CodeWall sitúa el parche al día siguiente de su correo de divulgación. Ambas versiones constan oficialmente. Ninguna de las partes las ha conciliado, y este artículo no intenta hacerlo: la diferencia está entre una corrección el mismo día y una al día siguiente, y la secuencia que importa —avisar, luego parchear, luego publicar— no está en disputa.

Establecido, de fuente única, y la brecha entre ambos

Establecido y acordado por ambas partes: había una debilidad no autenticada en la superficie de la API pública de Lilli; la encontró un investigador de seguridad externo y no alguien interno; McKinsey la confirmó y la parcheó; los endpoints no autenticados se cerraron, el entorno de desarrollo se puso fuera de línea y la documentación de la API pública se bloqueó.

Fuente única, de CodeWall: cada cifra mencionada arriba, la cronología de dos horas, las quince iteraciones a ciegas, los 27 hallazgos documentados y la afirmación de que los prompts se podían escribir mediante la misma inyección. Nada de ello ha sido refutado. Tampoco nada de ello ha sido verificado de forma independiente, porque no se publicaron los payloads que permitirían a alguien comprobarlo, y Price se negó a dar a The Register los prompts exactos que utilizó su equipo.

Promptfoo, la empresa de seguridad de IA, publicó una evaluación el 10 de marzo que señala el límite con precisión: el registro público {{1}}no demuestra de forma independiente cada recuento de filas reportado ni cada paso de la explotación,{{/1}} aunque sí respalda la forma del incidente. Esa es la lectura correcta del material disponible. La clase de error es reconstruible; la escala es testimonio.

El daño que el registro no conlleva

Aquí es donde la calificación del archivo hace un trabajo real. Un camino de dos horas hacia el acceso de lectura y escritura dentro de la base de datos de producción de un asistente para toda la empresa suena a registro de daño, y el archivo no registra ninguno. El campo se sustenta en tres cosas: la declaración de McKinsey de que una investigación forense de terceros no encontró evidencia de que se haya accedido a datos de clientes; la declaración de CodeWall de que sus pruebas fueron solo de verificación y no interrumpieron nada; y la ausencia, en la cobertura revisada para este artículo, de cualquier hallazgo contradictorio.

No se basa en una auditoría técnica independiente, en la determinación de un regulador ni en una notificación de brecha. No se asignó ningún identificador CVE en ninguna cobertura revisada —Lilli es software interno en lugar de un producto distribuido, y ningún aviso de seguridad menciona uno—, y ninguna autoridad supervisora parece haber abierto un expediente. No surgió ninguna evidencia pública, en la cobertura revisada para este artículo, de que los datos se usaran, vendieran o se expusieran aún más. Eso es lo que significa aquí «no se registró ningún daño real»: una declaración de evidencia sobre un registro, no una conclusión de que la exposición fuera segura.

La brecha importa porque el riesgo interesante era prospectivo. El acceso de lectura expone lo que había allí. El acceso de escritura a la capa de prompts expone lo que el asistente diría a continuación: consejos envenenados, eliminación de barreras de seguridad, material confidencial incorporado en una respuesta que un consultor luego pega en un documento para un cliente. CodeWall describió esas consecuencias como disponibles para cualquiera que tuviera el mismo acceso. Nadie ha demostrado que se hayan aprovechado. Ambas afirmaciones pueden ser ciertas a la vez: la capacidad era real y el daño no se materializó según las pruebas que alguien haya publicado.

Por qué se clasifica como infraestructura, no como un fallo del modelo

El archivo etiqueta este registro como INFRA, y el registro técnico respalda la etiqueta. Nada en la cuenta de CodeWall requería engañar al modelo. No hubo jailbreak, ni inyección de prompts desde un documento, ni entrada adversaria que se pidiera al asistente aceptar. El punto de entrada fue documentación expuesta, una verificación de autenticación faltante y una construcción SQL insegura; el modelo era simplemente lo más valioso detrás de la puerta.

El análisis de Promptfoo del 10 de marzo hace la misma distinción desde la perspectiva defensiva: Lilli «según la información pública, parece un incidente de seguridad de aplicaciones que alcanzó a un sistema de IA, no un jailbreak de modelo», y gran parte de lo que se llama seguridad de la IA sigue siendo seguridad de software, seguridad de datos y gobernanza de la configuración. La parte específica de la IA fue el radio de impacto, no la vulneración —porque los prompts, las reglas de enrutamiento y la configuración de recuperación eran datos mutables de la aplicación, el acceso de escritura a la base de datos se convirtió en la capacidad de cambiar el comportamiento del asistente sin tocar el código.

¿Qué cambió después?

Los cambios concretos son los que ambas partes describen: los endpoints no autenticados se cerraron y verificaron, el entorno de desarrollo se puso fuera de línea y la documentación pública de la API se bloqueó. McKinsey ha dicho que encontró la vulnerabilidad, la confirmó y la corrigió, y su posición pública es que no se accedió a datos de clientes.

Lo que no ha cambiado es la mayor exposición que describió este incidente. El artículo de CodeWall termina argumentando que los prompts se almacenan en bases de datos, pasan por API y se guardan en caché en archivos de configuración, y que rara vez reciben controles de acceso, historial de versiones o monitoreo de integridad; lo cual es una afirmación sobre una industria, no un hallazgo sobre McKinsey, y debe leerse como el argumento de una empresa que vende pruebas automatizadas continuas. La empresa está en una etapa de vista previa temprana y busca socios de diseño; la revelación sirve además como demostración.

Lo que deja el expediente es más acotado y más útil que el argumento. Un asistente para toda la firma, una base de datos de producción, dos horas, sin credenciales y una línea de daño que se lee como falsa porque ambas partes con acceso a los hechos afirman que los datos no se utilizaron. Los recuentos pertenecen a una de esas partes. La vulnerabilidad pertenece a ambas.