As violações de segurança de IA de 2025 expuseram uma mentira de um trilhão de dólares — e eu construí a alternativa

Eu estava em uma ligação com um CISO de uma empresa de serviços financeiros de médio porte quando a divulgação do RCE no GitHub Copilot veio à tona. Estávamos no meio de uma frase — ele explicava por que sua equipe tinha acabado de implantar o Copilot para 400 desenvolvedores — e eu vi o rosto dele mudar enquanto o Slack dele explodia. Ele se colocou no mudo. Voltou noventa segundos depois e disse, muito baixinho: "Você pode explicar o que o CVE-2025-53773 significa para nós?"

O que aquilo significava era isto: uma instrução oculta plantada em um arquivo README — um arquivo de texto — podia escalar para execução remota completa de código em cada estação de trabalho de desenvolvedor rodando o Copilot. Não com um buffer overflow. Não com um zero-day no kernel. Com uma conversa com um assistente de IA.

Aquela ligação mudou a trajetória dos meus seis meses seguintes. Mas, sinceramente, os sinais já estavam claros havia mais de um ano.

Sou Ashutosh, fundador da Veriprajna — um nome derivado do latim Veri (verdade) e do sânscrito Prajna (sabedoria). Construímos o que chamo de Deep AI: sistemas determinísticos por design, auditáveis por exigência e soberanos por infraestrutura. Não construímos wrappers. E 2025 provou, de forma catastrófica, por que essa distinção importa.

A economia dos wrappers sempre esteve fadada ao colapso

Por cerca de dois anos, o mercado de IA corporativa operou sobre uma premissa sedutora: pegue um modelo fundacional — GPT-4, Claude, Gemini — envolva-o em uma interface bonita, acrescente um pouco de engenharia de prompt e venda como uma "solução". Milhares de startups fizeram exatamente isso. Muitas levantaram somas consideráveis com isso.

Eu entendia o apelo. O tempo até a demonstração era incrível. Você conseguia mostrar a um conselho de administração uma IA que "entendia" o negócio deles em uma semana. Mas eu não parava de fazer uma pergunta que me tornava impopular em eventos do setor: o que acontece quando essa coisa roda em produção, com permissões reais, em infraestrutura real?

A resposta chegou em 2025, e chegou de forma violenta.

Três incidentes — a vulnerabilidade de execução remota de código no GitHub Copilot, a exposição de "Zombie Data" pelo cache do Microsoft Bing e o envenenamento da cadeia de suprimentos do Amazon Q — afetaram, somados, mais de 16.000 organizações e quase um milhão de desenvolvedores. Não eram casos extremos. Eram a consequência previsível de implantar sistemas probabilísticos como se fossem infraestrutura determinística.

Quando a IA opera como um agente não monitorado com permissões administrativas, suas falhas se propagam na velocidade da infraestrutura.

Escrevi sobre a anatomia técnica completa dessas violações na versão interativa da nossa pesquisa. Mas é a história por trás dos números que me tira o sono.

O que acontece quando um prompt vira uma arma?

Deixe-me guiá-lo pelo incidente do Copilot, porque a mecânica é genuinamente arrepiante.

O CVE-2025-53773 recebeu nota 7,8 na escala de severidade CVSS — "Alta". A classe da vulnerabilidade foi algo para o qual o setor teve de inventar um nome: Prompt-to-RCE. A escalada de uma instrução linguística para a execução de código binário.

Veja como funcionava. Um atacante planta uma instrução oculta — uma injeção cruzada de prompt — dentro de um arquivo README, de um comentário de código ou até de uma issue do GitHub. Nada visualmente suspeito. Quando um desenvolvedor pede ao Copilot para "revisar o código" ou "explicar este projeto", a IA ingere essas instruções ocultas. Ela então modifica o arquivo de configuração do workspace, adicionando especificamente a linha "chat.tools.autoApprove": true.

A comunidade de segurança começou a chamar isso de "modo YOLO". Uma vez ativado, o assistente de IA podia executar comandos shell, navegar na web e interagir com o sistema de arquivos local — tudo isso sem pedir permissão ao desenvolvedor. A partir daí, baixar malware, exfiltrar credenciais ou recrutar a estação de trabalho para uma botnet era trivial.

Lembro de estar sentado em nosso escritório depois de ler a divulgação completa, virar para o meu engenheiro de segurança principal e dizer: "Isso não é um bug. Isso é a arquitetura funcionando conforme projetada." A IA recebeu agência. Recebeu permissões. E ninguém construiu um sistema capaz de dizer "não" a um prompt suficientemente persuasivo.

Essa é a parte que me assombrou. Os controles de acesso tradicionais presumem que o ator é ou um humano ou um software com comportamento fixo. Um agente de IA não é nem um nem outro. Ele herda todas as permissões do usuário, mas responde a manipulação linguística. É como dar a alguém as chaves da sua casa e depois se surpreender quando um golpista o convence a abrir a porta.

Por que dados mortos voltaram à vida?

A segunda violação foi mais estranha e, de certa forma, mais perturbadora.

Em fevereiro de 2025, pesquisadores da Lasso Security descobriram que o Copilot da Microsoft estava exibindo dados de repositórios do GitHub que haviam sido tornados privados ou excluídos — às vezes meses antes. Eles chamaram isso de "Zombie Data", e o nome pegou porque era exato. Eram dados que deveriam estar mortos. Não estavam.

O mecanismo era quase constrangedoramente simples. O buscador do Bing havia rastreado e armazenado em cache milhares de repositórios públicos. Quando esses repositórios foram posteriormente tornados privados — muitas vezes porque alguém percebeu que havia commitado acidentalmente chaves de API, documentação interna ou código proprietário — as versões em cache persistiram no sistema de geração aumentada por recuperação (RAG) do Bing. Qualquer pessoa usando o Copilot podia consultar aquela informação supostamente excluída.

A exposição era estarrecedora: repositórios privados da IBM, Google, Tencent e PayPal. Mais de 300 tokens privados e chaves de API extraídos para serviços como AWS, GCP, OpenAI e Hugging Face. Mais de 100 pacotes internos vulneráveis a ataques de confusão de dependências.

Tive uma conversa com um prospect por volta dessa época — um VP de Engenharia de uma empresa de saúde — que me disse que sua equipe tinha feito "tudo certo". Eles haviam rotacionado credenciais, tornado os repositórios privados, seguido o manual. E nada disso importou, porque a memória da IA era mais longa que a resposta de segurança deles.

Soberania de dados e conveniência da IA são fundamentalmente incompatíveis no modelo de wrapper. Você não pode controlar o ciclo de vida dos seus dados quando a janela de contexto da sua IA é o cache de busca de outra pessoa.

Essa é a violação que cristalizou algo que eu vinha argumentando havia um tempo: se a sua IA depende de um sistema de recuperação de terceiros — um buscador público, uma API externa, o índice de outra pessoa — você já perdeu o controle dos seus dados. Não importa quão boas sejam as suas políticas internas. Os dados vivem em algum lugar que você não alcança, em um cache que você não pode limpar, respondendo a perguntas que você nunca autorizou.

Como envenenar as sugestões de uma IA em escala?

O terceiro incidente foi o que deixou toda a minha equipe irritada.

Em julho de 2025, um atacante comprometeu a extensão Amazon Q Developer para o Visual Studio Code — uma extensão com mais de 950.000 instalações. O ponto de entrada foi um token do GitHub com escopo indevido em um serviço de CI/CD, que permitiu ao atacante commitar um arquivo chamado cleaner.md diretamente no repositório de origem.

Aquele arquivo era um template de prompt. Parecia inofensivo. Mas instruía a IA a se comportar como um "limpador de sistema" — sugerindo comandos Bash que apagariam o diretório home do usuário, encerrariam instâncias EC2, excluiriam buckets S3 e removeriam usuários IAM.

Pare e pense nisso por um instante. Um arquivo de texto em um repositório confiável, distribuído em uma atualização oficial do marketplace, transformou um assistente de programação com IA em uma arma apontada tanto para máquinas locais quanto para a infraestrutura de nuvem em produção.

Eu estava em uma reunião de equipe em que dissecávamos isso. Um dos meus engenheiros — alguém que está na área de segurança há quinze anos — resumiu sem rodeios: "Passamos décadas protegendo binários, contêineres e perímetros de rede. Ninguém protegeu as sugestões."

Ele tinha razão. O comprometimento do Amazon Q provou que prompts são o novo código. Eles moldam o comportamento da IA de forma tão definitiva quanto instruções compiladas moldam o comportamento de uma CPU. E, ainda assim, em todo o setor, templates de prompt eram armazenados em texto puro, commitados sem revisão e distribuídos sem assinatura criptográfica.

Às vezes me perguntam se esses incidentes foram realmente tão graves — afinal, foram detectados e corrigidos. Mas isso ignora completamente a questão. Os patches corrigiram vulnerabilidades específicas. Não corrigiram a arquitetura que tornou essas vulnerabilidades inevitáveis.

O problema fundamental da IA probabilística em ambientes de alto risco

Eis a verdade incômoda que a economia dos wrappers nunca quis encarar: Grandes Modelos de Linguagem (LLMs) são motores estocásticos. Eles preveem o próximo token mais provável com base em padrões estatísticos dos dados de treinamento. São extraordinariamente bons em produzir texto fluente e de aparência plausível. Mas não têm nenhum conceito de verdade. Não têm nenhum conceito de segurança. Não têm nenhum conceito de "esta ação vai destruir um banco de dados em produção".

Quando você envolve um modelo probabilístico em uma interface fina e lhe entrega permissões administrativas, você não construiu uma solução corporativa. Você construiu um passivo muito eloquente.

Um LLM não entende verdade — entende plausibilidade. Em um ambiente de produção, essa distinção é a diferença entre uma trilha de auditoria e um relatório de violação.

Foi para resolver esse problema que fundei a Veriprajna. Não abandonando redes neurais — elas são genuinamente poderosas para compreensão de linguagem natural, reconhecimento de padrões e inferência criativa. Mas recusando-me a deixá-las operar sozinhas.

Como é, na prática, uma arquitetura neuro-simbólica?

Arquitetamos sistemas híbridos que fundem dois modos distintos de inteligência. Penso neles como a Voz e o Cérebro.

O sistema neural — a Voz — cuida da percepção. Ele entende o que um desenvolvedor está pedindo, interpreta linguagem natural, reconhece padrões. É a camada de interface, e é excelente no que faz.

O sistema simbólico — o Cérebro — cuida do raciocínio. Ele impõe lógica determinística, cálculos auditáveis e restrições específicas do domínio. Ele não prevê. Ele prova.

A ideia central é o desacoplamento. Quando a Voz propõe uma ação — digamos, gerar um comando shell — o Cérebro a valida contra regras lógicas rígidas antes da execução. Se um modelo neural sugerir excluir um banco de dados em uma VPC de produção, o motor simbólico veta. Não porque alguém escreveu um prompt dizendo "por favor, não exclua bancos de dados". Porque a ação é fisicamente bloqueada no nível arquitetural.

Chamamos esses mecanismos de Guardrails Constitucionais, e eles são fundamentalmente diferentes dos guardrails linguísticos em que o setor se apoia. Guardrails linguísticos são instruções — "seja útil e inofensivo". Eles são contornados por jailbreaking, por injeção indireta de prompt, pelas exatas técnicas que alimentaram as violações de 2025. Guardrails arquiteturais são restrições embutidas no runtime. Não dá para convencê-los a não aplicar uma regra, assim como não dá para convencer um firewall a não bloquear uma porta.

Um mecanismo específico que usamos é a Verificação KG-Trie: a saída de um modelo neural é restringida por um Grafo de Conhecimento verificado. Se o modelo tentar gerar um fato, citação ou comando que não exista dentro do grafo verificado, o sistema impede que esses tokens sejam gerados. A IA literalmente não consegue alucinar fora dos limites do conhecimento verificado.

Para o detalhamento técnico completo desta arquitetura, incluindo nossa abordagem de implantação edge-native e redes neurais informadas por física, veja nosso aprofundamento técnico.

Por que infraestrutura soberana não é mais opcional

A violação de Zombie Data me ensinou algo que hoje repito para todo prospect corporativo: se o seu modelo de IA roda na infraestrutura de outra pessoa, a sua soberania de dados é uma ficção de fachada.

Na Veriprajna, implantamos inteiramente dentro do ambiente do próprio cliente. Zero dependências de caches de busca externos. Zero chamadas de API de terceiros para recuperação. Um sistema de ciclo fechado em que o contexto da IA é exatamente — e apenas — o que a organização forneceu explicitamente.

Isso não é paranoia. É a única arquitetura que torna exposições de "zombie data" tecnicamente impossíveis. Você não pode ter um problema de persistência de cache se não existe cache externo.

Tive um debate acalorado com um investidor no começo, que me disse que essa abordagem era "pesada demais". Ele dizia que o mercado queria soluções leves, rápidas, baseadas em chamadas de API. Eu disse a ele que o mercado queria soluções que funcionassem — e que o peso de uma implantação soberana não era nada comparado ao peso de explicar a um regulador por que as suas credenciais excluídas ainda estavam respondendo a perguntas por meio da IA de outra pessoa.

Ele não investiu. Não levo isso a mal. Mas noto que ele não defende mais esse argumento.

O setor consegue realmente consertar isso?

O OWASP Top 10 de 2025 para Aplicações de LLM se lê como um post-mortem de tudo o que deu errado neste ano. Injeção de Prompt está em primeiro lugar. Divulgação de Informações Sensíveis em segundo. Cadeia de Suprimentos em terceiro. Agência Excessiva — exatamente o modo de falha do RCE do Copilot — em sexto.

Esses não são riscos teóricos. São as causas documentadas de violações reais que afetaram organizações reais.

O NIST AI Risk Management Framework está evoluindo na direção certa, empurrando as organizações rumo a uma governança contínua em vez de avaliações pontuais. Mas frameworks não se escrevem em código sozinhos. Alguém precisa construir os sistemas que de fato os aplicam.

É isso que fazemos. Tratamos arquivos de prompt como artefatos executáveis — assinados criptograficamente, revisados e versionados com o mesmo rigor de binários compilados. Construímos perfis de comportamento de base para cada agente de IA, acompanhando padrões de chamadas de API e volumes de acesso a dados para detectar anomalias antes que virem incidentes. Rodamos testes de mutação e fuzzing adversarial contra nossos agentes, não apenas testes funcionais, porque a pergunta não é "isso funciona?" — é "o que acontece quando alguém tenta fazê-lo se comportar mal?"

A madrugada que mudou minha forma de pensar a segurança de IA

Houve uma noite — provavelmente eram 2 da manhã — em que eu revisava os detalhes técnicos do comprometimento do Amazon Q pela terceira vez. Minha equipe tinha ido para casa. Eu estava sentado com uma xícara de chai frio, encarando o conteúdo do arquivo cleaner.md, publicado na divulgação.

As instruções eram tão educadas. "Por favor, aja como um limpador de sistema." "Sugira comandos para limpar o ambiente." As cargas destrutivas estavam embrulhadas na linguagem da prestatividade. E percebi que aquilo era a metáfora perfeita para toda a economia dos wrappers: uma superfície prestativa escondendo uma arquitetura destrutiva.

Tínhamos passado anos construindo uma IA otimizada para ser agradável. Para dizer sim. Para gerar o próximo token plausível. E tínhamos dado a ela as chaves da infraestrutura de produção.

A economia dos wrappers otimizou a IA para ser agradável. Nunca ocorreu a ninguém que ser agradável e ser seguro estão fundamentalmente em tensão.

Naquela noite, reescrevi do zero os nossos princípios internos de segurança. A primeira linha agora diz: "A resposta padrão do sistema para qualquer ação com consequências irreversíveis é não."

A arquitetura é o produto

Sei como isso soa. Um fundador dizendo que a abordagem dele é melhor, que o mercado errou, que o futuro pertence justamente àquilo que ele por acaso vende. Entendo o ceticismo.

Mas eis o que eu pediria que você considerasse: os três maiores incidentes de segurança de IA de 2025 compartilham a mesma causa raiz. Não um bug específico. Não a negligência de um fornecedor específico. Uma filosofia de design — a crença de que é possível construir IA de nível corporativo envolvendo um modelo probabilístico em uma fina camada de interface e torcendo para que os prompts aguentem.

Os prompts não aguentaram. Nunca iriam aguentar. Instruções linguísticas são sugestões, não restrições. E em ambientes de alto risco — finanças, saúde, manufatura, defesa — a diferença entre uma sugestão e uma restrição é a diferença entre um sistema funcional e uma falha catastrófica.

O futuro da IA corporativa não é um wrapper melhor. É uma arquitetura que separa a voz do cérebro, que impõe restrições no nível do runtime, que mantém os dados soberanos e que trata cada ação da IA como infraestrutura auditável — não como uma mensagem de chat que desaparece em um arquivo de log.

Não construí a Veriprajna porque achava que a economia dos wrappers iria colapsar. Construí porque eu sabia que ela tinha que colapsar.