46,5 Milhões de Mensagens em 2 Horas: Por Que Segurança de Agentes É um Problema de Arquitetura

Em 28 de fevereiro de 2026, a CodeWall publicou uma divulgação que deveria ter sido embaraçosa para toda a indústria de IA empresarial. A Lilli, plataforma interna de IA da McKinsey usada por 43 mil funcionários, foi violada por SQL injection. Não por uma cadeia sofisticada de exploits encadeados. Não por uma vulnerabilidade zero-day em infraestrutura de LLM. Por SQL injection, uma classe de ataque catalogada pela OWASP desde 2003.

O resultado: 46,5 milhões de mensagens de chat expostas em duas horas. Junto com 728 mil arquivos, 57 mil contas de usuário, 384 mil assistentes de IA configurados, 3,68 milhões de chunks de RAG e 266 mil vector stores da OpenAI. Noventa e cinco configurações de system prompt ficaram acessíveis, incluindo a capacidade de modificá-las. Sem deploy. Sem mudança de código. Apenas um UPDATE statement.

Onze dias depois, em 11 de março, a OpenAI publicou um paper sobre defesa contra injeção de prompt que reformula o problema inteiro. A coincidência temporal não é acidental. A indústria está sendo forçada a admitir algo que a comunidade de segurança repete há anos: proteger agentes de IA exige controles na camada de infraestrutura, não na camada de prompting.

A Violação Que Scanners Não Viram

A McKinsey não estava desprotegida. A Lilli tinha mais de 200 endpoints de API. Vinte e dois deles não exigiam autenticação. O OWASP ZAP, scanner padrão da indústria, não detectou a vulnerabilidade.

A CodeWall encontrou o vetor usando um agente autônomo que analisou mensagens de erro retornadas pela API. Em 15 iterações de tentativa cega, o agente identificou que certos endpoints aceitavam JSON key injection, permitindo SQL injection clássica através de parâmetros mal sanitizados.

Dois fatos merecem destaque aqui. Primeiro, a vulnerabilidade não era específica de IA. Era segurança web básica. O tipo de falha que qualquer pentest competente deveria encontrar. Segundo, um agente de IA encontrou o que ferramentas automatizadas tradicionais não encontraram. A ironia é precisa: IA quebrando a segurança de uma plataforma de IA que scanners de segurança julgavam segura.

A McKinsey corrigiu o problema em 24 horas após a divulgação responsável. Resposta rápida. Mas a velocidade da correção não altera a gravidade da exposição. Setenta por cento dos funcionários da McKinsey usavam a Lilli. Quinhentos mil prompts por mês. Cada um desses prompts potencialmente contendo informações confidenciais de clientes, estratégias internas e dados proprietários.

Transparência necessária: a CodeWall vende serviços de teste de segurança. A divulgação pública serve seus interesses comerciais. Isso não invalida os achados técnicos, mas explica a escolha de publicar com detalhes espetaculares.

A Inversão da OpenAI

O paper da OpenAI, publicado dois dias depois da divulgação da CodeWall, propõe uma mudança conceitual que merece atenção além do hype.

A tese central: injeção de prompt não é um problema de filtragem de input. É um problema de engenharia social. Assim como um atacante humano convence um funcionário a clicar num link malicioso, um prompt malicioso convence um agente a executar uma ação indesejada. A defesa, portanto, não pode depender de detectar todas as variações possíveis de input malicioso. Precisa controlar o que acontece quando o ataque inevitavelmente funciona.

A OpenAI formaliza isso através de uma análise source-sink. O atacante precisa de dois elementos: uma fonte (source) por onde o conteúdo malicioso entra no contexto do agente, e um destino (sink) onde o agente executa uma ação com efeito no mundo real. A defesa foca nos sinks, não nos sources. Em vez de tentar filtrar todo input possível, restringe as ações que o agente pode executar e para quem pode transmitir informação.

O mecanismo específico que a OpenAI apresenta, chamado Safe URL, detecta quando um agente tenta transmitir informação sensível para terceiros. Funciona independente de como o input malicioso entrou no contexto.

A frase que resume a mudança: “O defensor não pode depender apenas de filtrar inputs. Requer que o sistema seja desenhado para que o impacto da manipulação seja restrito, mesmo que ataques tenham sucesso.”

Leia de novo. Mesmo que ataques tenham sucesso. A OpenAI está dizendo, em paper oficial, que a prevenção perfeita de injeção de prompt não existe. O que existe é controle de raio de explosão.

Como exploramos em A Arquitetura da Confiança em Agentes, limites arquiteturais vencem instruções. O paper da OpenAI confirma essa tese com dados de produção.

O Padrão Que Conecta

A violação da Lilli e o paper da OpenAI parecem eventos separados. Não são. Formam dois lados do mesmo argumento.

A McKinsey confiou em scanning automatizado (OWASP ZAP) para proteger sua plataforma. O scanner não encontrou a vulnerabilidade. A defesa falhou porque dependia de detectar o ataque antes que ele acontecesse.

A OpenAI propõe o oposto: assuma que ataques vão acontecer. Projete o sistema para que o dano seja contido. Não tente construir um muro perfeito. Construa compartimentos que limitem o fogo.

Essa lógica não é nova em segurança. É o princípio de defesa em profundidade, praticado em segurança de redes desde os anos 90. O que é novo é aplicá-la especificamente a agentes de IA. E a resistência da indústria em fazê-lo.

A resistência existe porque a abordagem de compartimentação é cara. Credenciais de curta duração em vez de tokens permanentes significam mais infraestrutura. Permissões granulares por ação significam mais complexidade de configuração. Circuit breakers automáticos significam mais lógica de monitoramento. Cada camada de contenção adiciona custo operacional.

Mas o custo da alternativa é 46,5 milhões de mensagens expostas.

Três Controles que Faltaram na Lilli

A violação da McKinsey ilustra três controles de infraestrutura que, se presentes, teriam reduzido drasticamente o impacto.

Autenticação universal. Vinte e dois endpoints sem autenticação em uma plataforma com dados de 43 mil usuários. O controle mais básico de segurança web, ausente em mais de 10% da superfície de API.

Segmentação de acesso a dados. Um único vetor de SQL injection deu acesso a todas as tabelas: mensagens, arquivos, contas, configurações de prompt, vector stores. Sem segmentação por domínio, sem isolamento entre tipos de dado. O raio de explosão foi total porque não havia compartimentação.

Monitoramento de anomalias. A extração de 46,5 milhões de registros em duas horas gera um padrão de tráfego que deveria acionar alertas. Ou o monitoramento não existia, ou os thresholds estavam calibrados para ignorar exatamente esse tipo de evento.

Nenhum desses controles é específico de IA. São fundamentos de segurança de aplicações web que existem há duas décadas. A plataforma era de IA. A falha era de infraestrutura.

A Armadilha do “AI-Specific”

Existe uma tendência perigosa no mercado de segurança de IA: tratar toda vulnerabilidade em plataformas de IA como se fosse uma classe nova de problema que exige soluções novas.

A Lilli não foi violada por um ataque de IA. Foi violada por SQL injection. O fato de ser uma plataforma de IA é relevante pelo volume e sensibilidade dos dados expostos, não pelo vetor de ataque. As defesas que teriam impedido essa violação são as mesmas que impedem violações em qualquer aplicação web: autenticação, sanitização de input, segmentação de dados, rate limiting.

Ao mesmo tempo, a OpenAI argumenta corretamente que agentes de IA criam superfícies de ataque genuinamente novas. Injeção de prompt não tem equivalente exato em segurança tradicional. A capacidade de um agente interpretar texto arbitrário como instrução executável é uma classe de vulnerabilidade que não existia antes de LLMs.

A posição intelectualmente honesta é que ambas as coisas são verdadeiras simultaneamente. Plataformas de IA precisam de segurança web competente (a Lilli prova que isso não é óbvio). E precisam de controles adicionais específicos para agentes (o paper da OpenAI mostra quais).

Como discutimos em Governança de IA É Cibersegurança, a separação entre segurança “tradicional” e segurança de IA é artificial. A Lilli é o caso de estudo perfeito: uma falha tradicional expondo dados de IA.

O Que Muda na Prática

Para organizações operando agentes de IA em produção, a convergência entre a violação da McKinsey e o paper da OpenAI sugere três mudanças concretas.

Primeiro, auditar a superfície web das plataformas de IA com o mesmo rigor aplicado a qualquer aplicação crítica. Não confiar apenas em scanners automatizados. Pentests manuais e agentes autônomos de segurança encontram o que scanners não encontram. A ironia da Lilli é instrutiva: um agente de IA quebrou a segurança que scanners tradicionais consideravam intacta.

Segundo, implementar controles de contenção que assumem que ataques vão ter sucesso. Credenciais de curta duração que expiram antes que possam ser abusadas. Permissões por ação, não por role. Circuit breakers que cortam acesso automaticamente quando padrões anômalos são detectados. Cada agente com acesso apenas aos dados que precisa para a tarefa em andamento, com escopo que expira quando a tarefa termina.

Terceiro, separar a camada de dados da camada de agente. Como argumenta o artigo “Data Breach Machines” do idealloc, verificação de ações na camada de dados é o último perímetro. Quando o prompt é manipulável e o modelo é não-determinístico, o banco de dados precisa validar independentemente se a ação requisitada faz sentido. O banco não confia no agente. Verifica.

Não é uma questão de se sua plataforma de IA será testada. É quando. A questão é se, nesse momento, o raio de explosão será 46,5 milhões de registros ou um compartimento isolado.

Como abordamos em Injeção de Prompt É uma Arma na Cadeia de Suprimentos, a superfície de ataque de agentes não é o modelo. É tudo ao redor dele. A Lilli confirma: o ponto fraco não estava no LLM. Estava nos 22 endpoints sem autenticação que ninguém auditou.

---

Fontes

• CodeWall. “How We Hacked McKinsey’s AI Platform.” Março 2026.
• OpenAI. “Designing Agents to Resist Prompt Injection.” Março 2026.
• idealloc. “We Are Building Data Breach Machines.” Março 2026.

O Grupo Victorino ajuda empresas a construir arquitetura de segurança para agentes que não depende de prompting para proteção: contato@victorino.com.br | www.victorino.com.br