A Lilli da McKinsey foi tornada pública em 9 de março. O registro não traz dano algum.

Em 9 de março de 2026, a startup de segurança CodeWall publicou seu relato de como um agente autônomo que ela desenvolveu obteve acesso completo de leitura e escrita ao banco de dados de produção por trás do Lilli, o assistente de IA de toda a empresa da McKinsey & Company, em cerca de duas horas e sem uma única credencial. A intrusão em si ocorreu em 28 de fevereiro; o que este registro no arquivo de incidentes de IA documenta é o dia em que ela se tornou pública. Segundo a CodeWall, o banco de dados que ele alcançou continha 46,5 milhões de mensagens de chat em texto não criptografado, 728.000 arquivos, 57.000 contas de usuário e os 95 prompts de sistema que regem como o Lilli responde — e esses prompts estavam no mesmo banco de dados em que o agente podia gravar. As pessoas nos dados eram funcionários da própria McKinsey: a empresa afirma que 72% de seus funcionários, mais de 40.000 pessoas, usam o Lilli, que processa mais de 500.000 prompts por mês. O registro completo, com suas classificações de severidade e confiança e os registros vizinhos entre os quais ele se encontra, está no Orca AI Incident Archive.

Essa abertura é uma compressão de dois tipos muito diferentes de alegação, e a entrada do arquivo é cuidadosa quanto à diferença. Ela classifica o registro como um incidente, confiança A, não disputado, gravidade alta, região EUA, tipo INFRA — infraestrutura, não uma falha de modelo. Ela também registra que não houve dano real. Esse último campo é o que vale a pena ler duas vezes, porque não significa que a exposição foi inofensiva. Significa que nenhum dano foi estabelecido no registro, e o artigo abaixo separa aquilo em que duas partes concordam daquilo que se baseia no relato de uma empresa sobre sua própria pesquisa.

Por que a divulgação é um evento datado próprio

O resumo do arquivo para esta entrada remete a 28 de fevereiro de 2026, o dia em que o agente da CodeWall encontrou a falha, e o arquivo carrega essa data anterior como um registro separado. A divisão não é burocrática. Antes de 9 de março, as únicas partes que sabiam o que havia acontecido dentro do Lilli eram a McKinsey e o pesquisador que a havia informado. Depois de 9 de março, a forma da falha, a resposta da empresa e a alegação sobre o que estava no banco de dados estavam todas no registro público, onde outros pesquisadores de segurança podiam contestá-las.

Lilli não é um projeto paralelo. O The Register situou seu lançamento em julho de 2023, para chat, análise de documentos e recuperação de informações na pesquisa interna da empresa. O artigo do CodeWall, que também registra de onde vem o nome — a primeira mulher contratada para uma função profissional pela empresa, em 1945 —, descreve mais de 100.000 documentos internos por trás dele. O The Register, ao noticiar a divulgação no mesmo dia, estimou a adoção em 72% dos funcionários e o volume em mais de 500.000 prompts por mês — números que a própria McKinsey publicou em um estudo de caso público da plataforma.

Como o agente entrou

O relato da CodeWall começa com documentação, não com exploração. Seu agente encontrou a documentação da API da Lilli exposta publicamente e totalmente detalhada: mais de 200 endpoints ao todo, a maioria exigindo autenticação, e 22 que não exigiam. Um desses endpoints não autenticados gravava as consultas de pesquisa dos usuários no banco de dados. Os valores estavam devidamente parametrizados, mas as chaves JSON — os nomes dos campos — eram concatenadas diretamente no SQL.

O agente percebeu porque as mensagens de erro do banco de dados refletiam essas chaves JSON de volta literalmente. A CodeWall diz que o scanner ZAP da OWASP não sinalizou o problema e que o agente então executou quinze iterações cegas, com cada mensagem de erro lhe ensinando um pouco mais sobre a forma da consulta, até que linhas reais de produção começaram a retornar. A partir daí, ele encadeou a injeção com uma falha de autorização em nível de objeto para ler os históricos de busca de funcionários individuais. A empresa descreve toda a execução como totalmente autônoma, desde a seleção do alvo até o relatório, sem credenciais e sem intervenção humana. Seu fundador e diretor-executivo, Paul Price, disse ao The Register que o processo foi "totalmente autônomo, desde a pesquisa do alvo, a análise, o ataque e o relatório".

O que o CodeWall diz que estava dentro

Todos os números desta seção vêm do relatório de 9 de março da CodeWall. Nenhum payload foi publicado, então nada disso pode ser reproduzido ou contabilizado de forma independente — uma limitação que a próxima seção aborda.

• 46,5 milhões de mensagens de chat, armazenadas em texto simples, abrangendo trabalho de estratégia, compromissos com clientes, finanças e fusões e aquisições.

• 728.000 arquivos, dos quais o relatório detalha 192.000 PDFs, 93.000 planilhas do Excel, 93.000 apresentações do PowerPoint e 58.000 documentos do Word — 436.000 no total, deixando os 292.000 restantes sem classificação na mesma frase.

• 57.000 contas de usuário, 384.000 assistentes de IA e 94.000 workspaces, que a CodeWall descreve como a estrutura organizacional completa de como a empresa usa IA internamente.

• 95 prompts de sistema e configurações de modelo em 12 tipos de modelo, mostrando como o assistente foi instruído, quais salvaguardas existiam e quais modelos estavam por trás dele.

• 3,68 milhões de chunks de documentos de geração aumentada por recuperação, com caminhos de armazenamento no S3 e metadados internos de arquivos — a base de conhecimento que alimenta o assistente.

• 1,1 milhão de arquivos e 217.000 mensagens de agentes trafegando por APIs externas de IA, incluindo mais de 266.000 armazenamentos vetoriais na plataforma da OpenAI.

A descoberta que a CodeWall trata como manchete não é a injeção, mas onde a injeção foi parar. Os prompts de sistema da Lilli eram linhas no mesmo banco de dados em que o agente podia escrever, o que significa que um atacante com o mesmo acesso poderia ter reescrito as instruções do assistente com uma única instrução UPDATE envolvida em uma única chamada HTTP — sem implantação, sem alteração de código, sem arquivo em disco para comparar. A CodeWall diz que seus próprios testes foram apenas de verificação: ela leu, não escreveu, e afirma que nenhum serviço de produção foi interrompido.

O que a McKinsey disse no mesmo dia

Um porta-voz da McKinsey disse ao The Register em 9 de março que a empresa corrigiu todas as questões identificadas pela CodeWall poucas horas depois de tomar conhecimento delas. "Nossa investigação, apoiada por uma empresa líder de perícia forense independente, não identificou evidências de que dados de clientes ou informações confidenciais de clientes tenham sido acessados por este pesquisador ou por qualquer outro terceiro não autorizado", disse o porta-voz, acrescentando que "os sistemas de segurança cibernética da McKinsey são robustos."

O Silicon UK relatou a mesma posição em 13 de março, no relato de Matthew Broersma: a McKinsey disse que foi "recentemente alertada sobre uma vulnerabilidade relacionada à nossa ferramenta interna de IA, Lilli, por um pesquisador de segurança", que "confirmou prontamente a vulnerabilidade e corrigiu o problema em poucas horas", e que nenhum dado de cliente ou informação confidencial de cliente foi acessado. Esse relatório também observa que Price é o único funcionário da CodeWall, um detalhe que vale a pena manter porque funciona nos dois sentidos — uma equipe de pesquisa de uma única pessoa descobriu em duas horas o que os próprios scanners da empresa não descobriram, e uma operação de uma única pessoa também está vendendo a ferramenta que o descobriu.

Dois relatos da correção, com um dia de diferença

A linha do tempo de divulgação própria da CodeWall é a seguinte: o agente identifica a injeção SQL e começa a enumerar o banco de dados de produção em 28 de fevereiro; a cadeia completa é confirmada no mesmo dia, com 27 constatações documentadas; um e-mail de divulgação responsável é enviado à equipe de segurança da McKinsey em 1 de março, com um resumo de alto nível do impacto; o diretor de segurança da informação da firma confirma o recebimento e solicita evidências detalhadas em 2 de março; e, em 2 de março, todos os endpoints não autenticados são corrigidos e verificados, o ambiente de desenvolvimento é colocado offline e a documentação pública da API é bloqueada. A divulgação pública ocorre em 9 de março.

O relato da McKinsey é que a correção veio poucas horas depois de ser comunicada. A cronologia da CodeWall situa o patch no dia seguinte ao seu e-mail de divulgação. Ambas as versões estão registradas. Nenhuma das partes as conciliou, e este artigo não tenta fazê-lo: a diferença é entre uma correção no mesmo dia e uma no dia seguinte, e a sequência que importa — comunicada, depois corrigida, depois publicada — não está em disputa.

Estabelecidos, de fonte única, e a lacuna entre eles

Estabelecido, acordado por ambas as partes: havia uma vulnerabilidade não autenticada na superfície pública da API da Lilli; ela foi encontrada por um pesquisador de segurança externo, e não por um insider; a McKinsey confirmou e corrigiu; os endpoints não autenticados foram fechados, o ambiente de desenvolvimento foi tirado do ar e a documentação pública da API foi bloqueada.

Fonte única, da CodeWall: todas as contagens acima, a linha do tempo de duas horas, as quinze iterações cegas, os 27 achados documentados e a alegação de que os prompts podiam ser escritos por meio da mesma injeção. Nada disso foi refutado. Nada disso foi verificado de forma independente também, porque os payloads que permitiriam a alguém verificar não foram publicados, e Price se recusou a fornecer ao The Register os prompts exatos que sua equipe usou.

A Promptfoo, empresa de segurança de IA, publicou em 10 de março uma avaliação que estabelece o limite com precisão: o registro público "não comprova de forma independente cada contagem de linhas reportada nem cada etapa da exploração", embora sustente o formato do incidente. Essa é a leitura correta do material disponível. A classe da falha é reconstruível; a escala é testemunho.

O dano que o registro não carrega

É aqui que a classificação do arquivo realmente faz diferença. Um caminho de duas horas para obter acesso de leitura e escrita dentro do banco de dados de produção de um assistente usado em toda a empresa soa como um registro de dano, e o arquivo não registra nenhum. O campo se apoia em três coisas: a declaração da McKinsey de que uma investigação forense de terceiros não encontrou evidências de que dados de clientes tenham sido acessados; a declaração da CodeWall de que seus testes eram apenas de verificação e não interromperam nada; e a ausência, na cobertura revisada para este artigo, de qualquer conclusão contraditória.

Isso não se baseia em uma auditoria técnica independente, na determinação de um regulador ou em uma notificação de violação. Nenhum identificador CVE foi atribuído em nenhuma das matérias analisadas — Lilli é software interno, e não um produto distribuído, e nenhum aviso de segurança o nomeia — e nenhuma autoridade supervisora parece ter aberto um processo. Nenhuma evidência pública surgiu, na cobertura analisada para este artigo, de que os dados tenham sido usados, vendidos ou expostos de forma mais ampla. É isso que "nenhum dano real registrado" significa aqui: uma declaração de evidência sobre um registro, não uma conclusão de que a exposição era segura.

A lacuna importa porque o risco interessante era prospectivo. O acesso de leitura expõe o que estava lá. O acesso de escrita à camada de prompt expõe o que o assistente diria em seguida — conselhos envenenados, remoção de salvaguardas, material confidencial incorporado a uma resposta que um consultor depois cola em um documento do cliente. A CodeWall descreveu essas consequências como disponíveis a qualquer pessoa com o mesmo acesso. Ninguém demonstrou que tenham sido aproveitadas. As duas afirmações podem ser verdadeiras ao mesmo tempo: a capacidade era real, e o dano não se concretizou, com base nas evidências que foram publicadas.

Por que isso é registrado como infraestrutura, e não como uma falha de modelo

O arquivo classifica este registro como INFRA, e o registro técnico sustenta essa classificação. Nada no relato da CodeWall exigia enganar o modelo. Não houve jailbreak, nem injeção de prompt a partir de um documento, nem entrada adversária que o assistente tivesse de engolir. O ponto de entrada era documentação exposta, uma verificação de autenticação ausente e construção insegura de SQL; o modelo era simplesmente a coisa mais valiosa atrás da porta.

A análise de 10 de março do Promptfoo faz a mesma distinção pelo lado defensivo: Lilli "parece, nos registros públicos, um incidente de segurança de aplicações que atingiu um sistema de IA, e não um jailbreak de modelo", e boa parte do que se chama de segurança de IA ainda é segurança de software, segurança de dados e governança de configuração. A parte específica de IA era o raio de impacto, não a violação — porque prompts, regras de roteamento e configurações de recuperação eram dados mutáveis da aplicação, o acesso de escrita ao banco de dados tornou-se a capacidade de alterar o comportamento do assistente sem tocar no código.

O que mudou depois

As mudanças concretas são as que ambas as partes descrevem: os endpoints não autenticados foram fechados e verificados, o ambiente de desenvolvimento foi colocado offline e a documentação pública da API foi bloqueada. A McKinsey afirmou que encontrou a vulnerabilidade, a confirmou e a corrigiu, e a sua posição pública é que nenhum dado de cliente foi acedido.

O que não mudou é a exposição mais ampla descrita por este incidente. O relatório da CodeWall termina argumentando que os prompts são armazenados em bancos de dados, passam por APIs e são armazenados em cache em arquivos de configuração, e que raramente recebem controles de acesso, histórico de versões ou monitoramento de integridade — o que é uma afirmação sobre um setor, não uma constatação sobre a McKinsey, e deve ser lida como o argumento de uma empresa que vende testes automatizados contínuos. A empresa está em prévia inicial e procurando parceiros de design; a divulgação também serve como demonstração.

O que o registro deixa é mais estreito e mais útil do que a discussão. Um assistente de toda a empresa, um banco de dados de produção, duas horas, nenhuma credencial, e uma linha de dano que soa falsa porque as duas partes com acesso aos fatos dizem ambas que os dados não foram usados. As contagens pertencem a uma dessas partes. A vulnerabilidade pertence a ambas.