Quatro falhas. Quatro camadas. A arquitetura em si é a vulnerabilidade.

Um episódio recente de 10 de abril de 2026 do podcast Hard Fork do New York Times examinou as implicações de segurança cibernética de sistemas de IA avançados e levantou uma questão que a indústria vinha evitando: e se a segurança cibernética não estiver funcionando mal, mas fundamentalmente mal concebida?

O episódio foi ao ar semanas após uma sequência de incidentes que tornou a resposta difícil de ignorar. Em um mês, um agente de IA autônomo violou a plataforma de IA interna da McKinsey em duas horas. Um ataque de cadeia de suprimentos a uma biblioteca de IA de código aberto amplamente utilizada se espalhou para empresas downstream. Pesquisadores mostraram que o hardware destinado a ser a última linha de defesa pode ser quebrado com peças de prateleira que custam menos de mil dólares. E a Anthropic divulgou que um modelo de fronteira havia encontrado autonomamente milhares de vulnerabilidades zero-day em código que a indústria considerava estável.

Quatro incidentes. Quatro camadas da pilha de IA: aplicação, orquestração, hardware e sistema operacional. Cada um revelou limitações significativas nos controles projetados para protegê-los.

O Fim do Pensamento de Perímetro

A segurança cibernética tradicional se baseia em um único pressuposto: com controles suficientes, monitoramento e investimento, os sistemas podem ser seguros. Esse pressuposto moldou décadas de arquitetura, incluindo firewalls, gerenciamento de identidade, segurança de endpoint e plataformas SIEM, todas construídas na ideia de que visibilidade e gerenciamento rigoroso igualam segurança.

A indústria está se movendo em direção à Arquitetura de Confiança Zero, refletindo o reconhecimento crescente de que as fronteiras de rede tradicionais não podem mais ser consideradas confiáveis. No entanto, mesmo à medida que os modelos de confiança evoluem, os sistemas de IA introduzem um desafio diferente: dados sensíveis são rotineiramente agregados, processados e compartilhados em múltiplas camadas de infraestrutura.

Essa abordagem fez sentido quando os sistemas eram relativamente centralizados e os dados permaneciam dentro de limites claramente definidos. Ela se torna muito menos eficaz quando os dados se movem continuamente entre nuvens, APIs, fornecedores terceirizados e pipelines de IA, enquanto os usuários e os recursos de computação são distribuídos globalmente. O perímetro não é mais uma fronteira. É uma superfície em constante mudança, e ainda estamos aplicando pensamento baseado em controles a sistemas que não podem realisticamente ser controlados.

Falha na Camada de Aplicação: Lilli da McKinsey

Em 9 de março de 2026, a startup de segurança CodeWall publicou uma divulgação que destacou os riscos enfrentados por organizações que implantam IA internamente.

O agente ofensivo autônomo da CodeWall, sem credenciais, conhecimento interno ou orientação humana, alcançou acesso de leitura e gravação ao banco de dados de produção por trás de Lilli, a plataforma de IA interna da McKinsey, em menos de duas horas. Lilli é usada por mais de 40.000 funcionários para trabalho de estratégia, pesquisa de clientes e análise de documentos, gerando centenas de milhares de prompts por mês.

O ponto de entrada não foi sofisticado. O agente encontrou documentação de API exposta publicamente que listava mais de 200 endpoints, 22 dos quais não exigiam autenticação. As vulnerabilidades envolvidas espelham os riscos destacados no OWASP Top 10 para Aplicativos de LLM, particularmente em torno de interfaces expostas, integrações inseguras e confiança excessiva em sistemas conectados.

Um desses endpoints continha uma vulnerabilidade de injeção de SQL escondida em nomes de campos JSON, e não em valores de entrada, onde a maioria dos scanners automatizados procura. A partir daí, o agente iterou através de injeção de SQL cega até que os dados de produção se tornassem acessíveis.

O que ele acessou: dezenas de milhões de mensagens de chat em texto puro, centenas de milhares de arquivos, dezenas de milhares de contas de usuário e milhões de pedaços de documentos RAG que representam anos de pesquisa proprietária. Ele também identificou os prompts do sistema que governavam o comportamento de Lilli para cada usuário.

A descoberta mais alarmante não foi o volume. Foi que os prompts do sistema eram graváveis. Um atacante poderia ter reescrito silenciosamente as instruções que governavam as saídas de Lilli, envenenando conselhos estratégicos, incorporando dados confidenciais em respostas ou removendo barreiras entirely, com uma única atualização do banco de dados. Nenhuma implantação. Nenhuma alteração de código. Nenhum rastro nos logs de aplicativos.

Em uma declaração pública, a McKinsey disse que resolveu a questão em questão de horas e, após uma investigação de uma empresa de forenses terceirizada, não encontrou evidências de que dados confidenciais de clientes foram acessados. Essa resposta importa. Mas não muda a lição estrutural: uma classe de vulnerabilidade com décadas de existência expôs a memória operacional de um sistema de IA moderno porque os dados por trás dele existiam em forma legível.

Falha na Camada de Orquestração: O Ataque LiteLLM

Três semanas depois, o mesmo padrão apareceu de um ângulo diferente e por meio de uma camada diferente.

O LiteLLM é um gateway de IA de código aberto usado por milhares de empresas para encaminhar solicitações por meio de provedores de IA. Sua posição na pilha é crítica: ele se situa na camada de orquestração, mantendo chaves de API para cada provedor ao qual se conecta. Qualquer comprometimento nessa camada expõe credenciais em todos os serviços integrados.

De acordo com um relatório de incidente do PyPI, o grupo de atacantes TeamPCP explorou credenciais vinculadas a uma dependência no pipeline de CI/CD do LiteLLM e usou o acesso do mantenedor para publicar duas versões comprometidas do pacote LiteLLM diretamente no PyPI. As versões contaminadas estiveram ao vivo por menos de uma hora antes de serem removidas. A operação foi descoberta apenas porque o malware continha um bug que travou a máquina de um pesquisador.

A cadeia de suprimentos foi o vetor. A camada de orquestração foi o alvo. Ao comprometer uma única dependência upstream, os atacantes alcançaram a camada onde as chaves de provedor de todas as empresas downstream viviam.

A equipe do LiteLLM detalhou mais tarde o incidente e os esforços de mitigação em uma divulgação pública no GitHub.

O raio de explosão se tornou visível quase imediatamente. A TechCrunch, a Fortune e o The Register relataram que a Mercor, uma startup de recrutamento de IA no valor de 10 bilhões de dólares que trabalha com empresas como OpenAI, Anthropic, Meta e Google, foi uma das organizações afetadas. Os atacantes alegaram ter obtido grandes volumes de dados, incluindo perfis de candidatos, informações de identificação pessoal, entrevistas de vídeo de contratados, código-fonte e chaves de API. A Meta pausou o trabalho com a Mercor pendente de investigação. Relatórios subsequentes indicaram padrões de malware semelhantes aparecendo em outras ferramentas e pacotes de desenvolvedor, sugerindo que a operação pode ter se estendido além de um único projeto.

O incidente do LiteLLM não foi uma anomalia. Foi o sistema se comportando como projetado. Cada componente em um pipeline de IA requer acesso a dados utilizáveis para funcionar, o que significa que cada componente também é um ponto potencial de extração. Prender dependências e girar credenciais são respostas necessárias, mas elas abordam o incidente, não a arquitetura.

Falha na Camada de Hardware: TEE.fail

Se a violação da McKinsey demonstrou que a camada de aplicação não pode ser confiável, e o ataque do LiteLLM demonstrou que a cadeia de suprimentos não pode ser confiável, a pesquisa do TEE.fail demonstrou que o hardware destinado a compensar ambos não pode ser totalmente confiável.

Em 28 de outubro de 2025, pesquisadores da Georgia Tech, Purdue University e Synkhronix publicaram o TEE.fail, um ataque de canal lateral que extrai chaves criptográficas de Ambientes de Execução Confiáveis usando interposição de barramento de memória física em servidores DDR5. O ataque afeta Intel SGX, Intel TDX e AMD SEV-SNP, incluindo sistemas totalmente patchados, com status de confiança e com a Ciphertext Hiding da AMD habilitada. Essas são as tecnologias amplamente promovidas como a base da computação confidencial.

Os pesquisadores extraíram chaves de atestado: o material criptográfico usado para verificar que as cargas de trabalho estão sendo executadas dentro de ambientes seguros. Com essas chaves, um sistema comprometido pode se apresentar como confiável enquanto opera inteiramente fora das proteções esperadas. Os pesquisadores demonstraram isso diretamente: eles forjaram atestações TDX no BuilderNet do Ethereum para acessar dados de transações confidenciais e falsificaram atestações da Intel e da NVIDIA para executar cargas de trabalho fora de qualquer TEE enquanto pareciam legítimas.

A implicação da NVIDIA importa especificamente para a IA. Porque a atestação da GPU depende da atestação da CPU, uma cadeia de confiança da CPU comprometida pode minar as garantias fornecidas por ambientes de inferência de IA confidenciais. A base de hardware da inferência de IA confidencial é, nesse modelo de ameaça, condicional a uma TEE da CPU que foi demonstravelmente quebrada.

Os fornecedores de hardware responderam com avisos formais. A AMD afirmou que ataques de acesso físico estão fora de seu modelo de ameaça padrão e indicou que não emitiria atualizações de firmware. A Intel e a NVIDIA reconheceram as descobertas e indicaram trabalho de mitigação em andamento. Essas respostas são razoáveis dentro de seus modelos de ameaça. Elas também destacam um limite importante: as garantias de segurança baseada em hardware dependem de suposições, incluindo controle físico, que implantações soberanas, regulamentadas e enfrentadas por adversários não podem sempre fazer.

O TEE.fail não torna a isolamento de hardware irrelevante. Ele demonstra que é condicional.

Falha na Camada do SO: A Revelação do Mito

Se os três primeiros incidentes questionaram a camada de aplicação, a camada de orquestração e a camada de hardware, uma quarta divulgação em abril de 2026 questionou a camada abaixo de todas elas: os sistemas operacionais e bibliotecas centrais que todas as outras camadas executam.

Em 7 de abril de 2026, a Anthropic anunciou o Claude Mythos Preview, um modelo de fronteira que se recusou a lançar publicamente devido às suas capacidades de segurança ofensiva, e lançou simultaneamente o Project Glasswing, um consórcio com a AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, a Linux Foundation, Microsoft, NVIDIA e Palo Alto Networks. A Anthropic relatou que, em questão de semanas, o Mythos havia identificado autonomamente milhares de vulnerabilidades desconhecidas em sistemas operacionais e navegadores da web principais e era capaz de produzir exploits funcionais para muitos deles.

As descobertas específicas são mais difíceis de descartar do que qualquer resumo sugere. Um bug de 27 anos em OpenBSD. Uma falha de execução de código remoto de 17 anos no servidor NFS do FreeBSD, agora rastreada como CVE-2026-4747, que concede acesso de root a um atacante não autenticado. Uma vulnerabilidade de 16 anos no FFmpeg, uma das bibliotecas de mídia mais amplamente implantadas na internet. Em um caso, um engenheiro da Anthropic sem treinamento formal em segurança pediu ao modelo que procurasse por falhas de execução de código remoto durante a noite e acordou com um exploit de trabalho completo.

Essas são descobertas de nível de sistema operacional. O OpenBSD e o FreeBSD são kernels. O NFS é um subsistema de rede de kernel. O FFmpeg é uma biblioteca de sistema que é enviada com a maioria das distribuições de Linux e sustenta pipelines de mídia em toda a internet. A camada do SO foi considerada segura não porque foi provada segura, mas porque encontrar falhas profundas nela exigia expertise humana escassa e cara. Essa suposição era a melhor heurística disponível. Nunca foi uma garantia.

Essa restrição agora se alivia. A própria Anthropic enquadrava isso como uma mudança de uso duplo: as mesmas capacidades que permitem que um modelo de fronteira encontre e corrija vulnerabilidades em escala também permitem que ele, nas mãos erradas, encontre e explore-as em escala. A decisão da Anthropic de restringir o acesso por meio do Project Glasswing reflete essa realidade. Ela não a resolve. Capacidades semelhantes, por avaliação da própria empresa, proliferarão. O custo de auditoria de código legado desmoronou, e com ele a defesa implícita de que tal código era muito obscuro, muito antigo ou muito amplamente revisado para ainda conter falhas críticas.

Isso também é onde os quatro incidentes se somam. Os três primeiros incidentes descrevem como os sistemas de IA estão sendo violados hoje. O Mythos descreve a taxa na qual tudo abaixo deles, incluindo os sistemas operacionais, módulos de kernel e bibliotecas de sistema, está prestes a ser reauditorado por máquinas. A violação da McKinsey explorou uma classe de vulnerabilidade de injeção de SQL que existe há mais de duas décadas. Vulnerabilidades dessa idade são exatamente o que os modelos da classe do Mythos são capazes de encontrar em escala industrial.

As três primeiras descobertas descrevem como os sistemas de IA estão sendo violados hoje. O Mythos descreve a taxa na qual tudo abaixo deles, incluindo os sistemas operacionais, módulos de kernel e bibliotecas de sistema, está prestes a ser reauditorado por máquinas. A violação da McKinsey explorou uma classe de vulnerabilidade de injeção de SQL que existe há mais de duas décadas. Vulnerabilidades dessa idade são exatamente o que os modelos da classe do Mythos são capazes de encontrar em escala industrial.

O Padrão

Em cada caso, os dados estavam em texto puro no momento em que importava.

A camada de aplicação os processou em claro. A camada de orquestração os encaminhou em claro. A camada de hardware, apesar de suas proteções, ultimatemente exigiu descriptografia no ponto de execução. A camada do SO abaixo de todas elas operou neles em claro por definição. Quatro camadas, quatro falhas, e em cada camada a mesma condição se manteve: quando a violação ocorreu, os dados eram legíveis.

Isso não é uma coleção de falhas isoladas. É a arquitetura em si.

Os sistemas de IA modernos são projetados para operar em dados legíveis. Cada camada, incluindo recuperação, encaminhamento, inferência e execução de ferramentas, requer acesso em texto puro para funcionar. Essa escolha de design significa que qualquer violação em qualquer camada expõe os dados por trás dela.

A pergunta não é se uma camada será comprometida. É o que o atacante encontra quando ela é.

De Violação Assumida a Exposição Zero

A indústria já começou a mudar de “prevenir violação” para “assumir violação.” Mas a maioria das arquiteturas não seguiu em frente com as implicações.

Se a violação for inevitável, então a pergunta real não é como manter os atacantes fora. É o que acontece quando eles entram. Agora, a resposta é simples: eles obtêm os dados. Porque, apesar de todo o investimento em infraestrutura de segurança, os dados ainda são expostos no exato momento em que se tornam valiosos, quando estão sendo usados.

A resposta da indústria foi previsível: mais monitoramento, detecção mais rápida, camadas adicionais de computação confidencial. Essas são melhorias. Mas elas não resolvem a questão central. Elas ainda assumem que alguma camada — seja software, hardware ou operacional — pode ser confiável para manter os dados em texto puro seguros.

A alternativa é remover os dados em texto puro completamente. Não para proteger as camadas em torno dos dados, mas para tornar os dados em si inacessíveis a qualquer um que os alcance. Computação em dados criptografados, onde prompts, pesos de modelo e saídas permanecem criptografados ao longo do pipeline, aborda a exposição que cada um desses incidentes explorou.

Avanços em criptografia homomórfica completa e outras técnicas de computação de preservação de privacidade estão começando a tornar arquiteturas que minimizam ou eliminam a exposição de texto puro cada vez mais práticas para cargas de trabalho de IA do mundo real. Embora desafios de desempenho, escalabilidade e implementação significativos permaneçam, o objetivo é fundamentalmente diferente dos controles de segurança tradicionais: reduzir o valor de uma violação bem-sucedida em vez de simplesmente tornar a violação menos provável.

A mudança não é de uma ferramenta de segurança para outra. É de segurança de sistemas para redução de exposição. De infraestrutura confiável para dados de confiança zero. De gerenciamento de risco para minimização da superfície de ataque em si.

O Que Vem a Seguir

A discussão do Hard Fork levantou a questão de se a segurança cibernética está fundamentalmente mal concebida. As evidências das últimas semanas sugerem que a resposta é sim, pelo menos para a IA.

O modelo antigo supunha que os sistemas podem ser seguros, violações podem ser contidas e exposição pode ser gerenciada. A realidade emergente é que violações devem ser assumidas e exposição minimizada. Os incidentes descritos aqui sugerem que a segurança de sistemas de IA pode depender cada vez mais de reduzir a quantidade de dados sensíveis disponíveis quando os controles falham.

As vulnerabilidades expostas em todos esses quatro incidentes não estão confinadas a uma única camada. Elas são sistêmicas. Abordá-las exigirá mais do que melhorias incrementais. Exigirá uma mudança de segurança de sistemas para redução de exposição, de defesa do perímetro em torno dos dados para remoção do texto puro que o perímetro foi construído para proteger.

A segurança de IA não é mais sobre manter os atacantes fora. É sobre garantir que, quando eles entram, e eles entrarão, não há nada legível para eles encontrar.