Como impedir a “tríplice ameaça letal” da IA

• Os LLMs têm um problema estrutural de não conseguir separar código e dados, o que os torna vulneráveis a ataques de injeção de prompt
• Em especial, quando recebem ao mesmo tempo acesso a dados externos, leitura de segredos internos e permissão de comunicação externa, surge a chamada tríade letal (lethal trifecta), que pode levar a danos graves
• Engenheiros de IA precisam pensar como engenheiros mecânicos e, em vez de uma abordagem determinística, aceitar a incerteza de sistemas probabilísticos e trabalhar com margens de segurança
• Assim como engenheiros da era vitoriana deixavam folga com projetos superdimensionados para lidar com a incerteza dos materiais, sistemas de IA também precisam adotar limites de segurança, tolerância a risco e taxa de erro
• Assim como pontes no mundo físico têm limite de carga, chegou o momento de os sistemas de IA também terem normas com limites explícitos e margens de segurança

---

O problema de segurança intrínseco dos LLMs

• Grandes modelos de linguagem têm uma falha estrutural: não conseguem separar código de dados
• Por isso, são vulneráveis a ataques de injeção de prompt
  • O sistema é enganado para seguir instruções que não deveria obedecer
  • Em alguns casos, isso só produz resultados constrangedores, como fazer um agente de suporte ao cliente falar como um pirata
  • Em outros, pode causar danos muito mais destrutivos

Tríade letal (Lethal Trifecta)

• O pior impacto acontece quando se forma a “tríade letal”
• Os três elementos são:
  • permissão de acesso a dados não confiáveis
  • capacidade de ler informações confidenciais importantes
  • capacidade de se comunicar com o mundo externo
• Quando uma empresa tenta dar aos funcionários um assistente de IA poderoso e concede essas três capacidades ao mesmo tempo, problemas graves se tornam inevitáveis
• Não são apenas os engenheiros de IA: usuários comuns também precisam aprender a usar IA com segurança
  • Instalar a combinação errada de apps pode criar acidentalmente esses três elementos

A necessidade de mudar a forma de pensar dos engenheiros de IA

Pensar como engenheiros mecânicos

• Melhor engenharia de IA é a primeira linha de defesa
• Engenheiros de IA devem pensar como engenheiros que constroem estruturas como pontes
  • reconhecendo que um trabalho malfeito pode custar vidas

A lição da engenharia vitoriana

• As grandes obras da era vitoriana na Grã-Bretanha foram construídas por engenheiros que não podiam ter certeza das propriedades dos materiais
  • Na época, o ferro muitas vezes tinha baixa qualidade por incompetência ou fraude
  • Como resultado, os engenheiros optavam pela cautela e incorporavam redundância por meio de superdimensionamento
  • O resultado foram obras-primas que resistiram por séculos

O problema atual do setor de segurança em IA

• Fornecedores de segurança para IA não pensam dessa forma
• A programação tradicional é determinística
  • vulnerabilidades de segurança são tratadas como bugs a serem corrigidos
  • uma vez corrigidas, desaparecem
• Engenheiros de IA se acostumaram com essa forma de pensar desde a formação
  • por isso, agem como se mais dados de treinamento e prompts de sistema mais inteligentes fossem suficientes para resolver o problema

Uma abordagem adequada para sistemas probabilísticos

Os limites dos dados de treinamento e dos prompts

• Dados de treinamento e prompts inteligentes de fato reduzem o risco
  • os modelos mais novos e mais inteligentes são melhores do que modelos antigos ou menores para detectar e recusar pedidos maliciosos
• Mas não conseguem eliminar totalmente o risco
  • ao contrário da maior parte do software, os LLMs são probabilísticos
  • a saída é determinada por uma escolha aleatória entre respostas possíveis
  • por isso, uma abordagem de segurança determinística é inadequada

Imitar a engenharia do mundo físico

• Uma forma melhor é imitar os engenheiros do mundo físico
• Aprender a trabalhar com sistemas imprevisíveis
  • em vez de lutar contra sistemas temperamentais que não podem ser garantidos de funcionar como desejado, trabalhar junto com eles
• Introduzir margens de segurança, tolerância a risco e taxa de erro para lidar com a imprevisibilidade com mais tranquilidade

Estratégia de superdimensionamento para a era da IA

• Usar modelos mais poderosos do que o estritamente necessário
  • reduzindo o risco de serem enganados a se comportar de forma inadequada
• Impor limites no número de consultas que um LLM pode receber de fontes externas
  • ajustando isso ao risco de dano causado por consultas maliciosas
• Dar ênfase a falhas seguras
  • se um sistema de IA precisa acessar segredos, deve-se evitar entregar a ele as chaves do reino

A necessidade de definir limites de segurança

• No mundo físico, pontes têm limite de carga
  • mesmo que isso nem sempre seja mostrado claramente aos motoristas, ele existe
  • o ponto importante é que esses limites deixam margem suficiente dentro da faixa real de tolerância que os cálculos indicam que a ponte suportaria
• Agora é a vez de o mundo virtual dos sistemas de IA passar a ter algo semelhante
• É essencial projetar sistemas com limites claros de segurança e margens de folga

[GN⁺]

Comentário do Hacker News

• Link do artigo arquivado
• Esta é a segunda matéria da Economist nesta semana a mencionar a lethal trifecta. A primeira foi Sistemas de IA nunca são totalmente seguros — a “tríplice ameaça letal” com a qual precisamos lidar, e me pareceu a explicação mais clara na mídia sobre o que é prompt injection e por que é perigoso. Posso ser um pouco tendencioso porque há um trecho em que fui citado, mas ainda assim é um artigo que eu recomendaria fortemente para executivos. Já esta matéria nova não me agradou muito. Ela menciona que, como LLMs são não determinísticos, é difícil corrigir vulnerabilidades de segurança, e por isso usa a analogia de que seria preciso “superdimensionar” como se faz com pontes e se preparar para margens de tolerância. Isso pode fazer sentido para pontes, mas não me parece uma solução fundamental para vulnerabilidades de segurança. Se um sistema cair em prompt injection mesmo que seja só 1 vez em 100, o atacante vai continuar tentando variantes até conseguir. Se você bloquear qualquer um dos três elementos da lethal trifecta (acesso a dados privados, exposição a instruções não confiáveis, caminho de exfiltração externa), o ataque deixa de funcionar.
  • Construtores de pontes geralmente não projetam pensando em ataques adversariais. E, mesmo quando pensam, costumam focar mais em algo fácil de mover e rápido de reposicionar do que em torná-lo robusto. Em vez de uma ponte fortíssima que sobreviva a bombardeios, muitas vezes é mais rápido e mais barato simplesmente instalar mais uma ponte temporária. Veja este caso concreto.
  • LLMs, assim como humanos, são não determinísticos. Então a gestão de segurança pode ser abordada como se faz com humanos. É preciso conceder apenas o mínimo de privilégios necessário por meio de controle de acesso baseado em papéis, e tarefas arriscadas ou de alto custo devem passar por processos de aprovação. Em organizações importantes de tecnologia, infraestrutura, defesa, finanças etc., o básico é fazer modelagem de ameaças partindo do pressuposto de que agentes de governos estrangeiros — como Rússia, China, Israel ou Coreia do Norte — podem estar misturados na equipe.
  • Na verdade, os dois artigos são o mesmo artigo. A Economist publica toda semana, no começo da edição, uma série chamada “Leaders”, que resume e generaliza as reportagens aprofundadas publicadas na mesma edição. Ou seja, eles aplicam uma estrutura de pirâmide invertida ao jornal inteiro (explicação da pirâmide invertida). Neste caso também, o artigo linkado funciona como uma versão resumida da matéria principal sobre o tema.
  • Eu penso no problema de segurança dos LLMs como: “e se meu código pudesse ser comprometido por engenharia social?”. LLMs, como humanos, inevitavelmente podem ser enganados, por mais treinamento que recebam. Se você der privilégios de root a um computador e permitir que qualquer pessoa no mundo converse com o LLM, o sistema inevitavelmente ficará vulnerável. Assim como não delegamos autoridade ilimitada a humanos, também faz sentido não permitir que LLMs acessem dados sem relação com o solicitante ou alterem dados de usuários.
  • O problema de dizer que basta cortar um lado da lethal trifecta é que esses três elementos estão entrelaçados. Por exemplo, conteúdo externo como e-mail também pode conter informações pessoais, e ao enviar um e-mail, o conteúdo da minha caixa de entrada pode acabar indo para um atacante. Além disso, e-mail, GitHub etc. são mais úteis justamente quando tanto envio quanto recebimento estão habilitados, e ter um servidor dedicado separado para cada função é ineficiente.
• Vindo de uma formação em engenharia mecânica, achei este artigo insuficiente. É comum dizer “basta aumentar a robustez”, mas na prática isso só se aplica entendendo em detalhe os vários modos de falha. A lethal trifecta é apenas um modo de falha, e então se adiciona “robustez” para bloqueá-lo. Não é uma questão de “esta ponte vibra demais, então vamos pensar em como atravessá-la com segurança”; o correto é modificar a ponte para que ela não vibre excessivamente.
  • Tenho a sensação de que o mundo enlouqueceu. Seguindo essa analogia da ponte, seria como se já tivéssemos tecnologia para construir pontes há muito tempo, mas de vez em quando o chão simplesmente sumisse e as pessoas caíssem no rio; ainda assim, em vez de discutir “vamos fazer de outro jeito”, a resposta fosse “vamos colocar uma rede embaixo e pegar todo mundo quando cair”. Estamos despejando bilhões em uma tecnologia essencialmente imprevisível e, no fim, só adicionando mais guarda-corpos. Não faz sentido nenhum.
  • Quando vejo a expressão “coders need to” em um artigo, eu perco o interesse na hora. A própria analogia parece errada, e mesmo para quem tem experiência real na área soa estranha. A condição usada pelo jornalista como exemplo — “se, dentro de uma empresa, um LLM puder ao mesmo tempo lidar com dados não confiáveis, informações importantes e comunicação com o exterior” — já é o próprio problema. Muitas empresas criam esse risco porque priorizam funcionalidade acima de segurança. A afirmação de que “como LLMs são não probabilísticos, uma abordagem determinística é inadequada” é um salto lógico. Mesmo sendo não determinísticos, a lógica de sandbox continua válida; em outras palavras, se você força demais a analogia, ela acaba atrapalhando em vez de ajudar a área. Seria melhor usar a terminologia certa e conhecimento de domínio, mas aí talvez o texto perdesse apelo jornalístico.
• Será que o artigo estava mesmo dizendo que a solução é simplesmente limite de velocidade e modelos melhores? Engenheiros de software já estudam isso há décadas. Esta indústria conhece as respostas de segurança; o problema é que elas não combinam com a pressa atual de lançar produtos de IA.
  • IA agora também faz parte da mesma área de TI, então a conclusão seria: “na verdade, nós não entendemos segurança”. Dizer que a IA é descuidada não corresponde aos fatos. Não existe uma forma perfeita de separar dados e tokens de instrução, e isso é uma limitação fundamental, não mera negligência. Dizer “já descobrimos tudo isso há décadas” é arrogância.
  • Esse tipo de fala de “já resolvemos segurança há décadas” aparece quando uma nova indústria corre para relançar “produtos de IA” recriando os mesmos maus padrões antigos. Basta ver casos como o padrão MCP, que já nasceu vulnerável; abordagens do tipo “escrever prompts melhores” chegam a ser risíveis. O maior problema é que quase todo mundo na indústria de IA parece ter projetado sem estranhar o fato de que um servidor MCP acessa diretamente o banco de dados. É um exemplo de que poder fazer algo não significa que você deva fazer, e essa segurança frouxa está levando a comprometimentos reais em inúmeros produtos de IA.
  • A alegação de que “já entendemos segurança” na prática não é verdade. Quando entra o fator humano, menos ainda, e isso apesar de gastarmos bilhões em treinamentos repetidos que vão perdendo eficácia com o tempo. Ainda recentemente houve casos de especialistas brilhantes em segurança que caíram em phishing simples no YouTube.
• Texto original de @simonw: The lethal trifecta for AI agents, com texto adicional relacionado. Também deixo o link para a discussão relacionada no HN.
• A lethal trifecta é o problema que surge quando um LLM tem, ao mesmo tempo, acesso a dados não confiáveis, visibilidade sobre informações importantes e comunicação com o exterior. A solução é reduzir o risco por meio da gestão de fronteiras (permissões), algo bem básico de segurança 101.
  • Sim, mas na prática surge uma grande tensão entre segurança e funcionalidade. Para fazer algo útil com dados pessoais, você acaba abrindo vulnerabilidade a prompt injection. E, ao mesmo tempo, reunir o máximo possível de contexto relacionado melhora a eficiência do agente; por isso, se você separar/isolar completamente um agente que lê entradas não confiáveis, pode acabar reduzindo sua utilidade. Veja este blog relacionado.
  • Estritamente falando, isso também é só controle de acesso básico. No momento em que há conexão com a internet, o risco cresce muito. Se houver um pesquisador de segurança realmente excelente, uma única prompt injection pode bastar para dominar o sistema inteiro e satisfazer imediatamente pelo menos uma das condições.
• LLMs não distinguem entre prompt e dados. Não existe nada como o bit NX (bit de não execução), nem há caso conhecido de algo semelhante implementado para isso. Claro que, assim como a introdução do NX bit não impediu completamente execução remota de código, só isso também não resolveria tudo. No momento, a abordagem mais realista é controlar o processo do agente LLM com mecanismos de segurança tradicionais. Por exemplo, executá-lo em uma conta de usuário separada para limitar acesso a arquivos, e adicionar restrições de rede, hardware e via cgroups. Ainda assim, se dados não confiáveis vierem misturados com instruções, o risco de o LLM acabar exfiltrando dados secretos continua. E, se o usuário copiar a saída do LLM para fora sem perceber, o caminho de exfiltração se abre de novo.
  • Dizem que ninguém criou algo semelhante, mas eu me pergunto se alguém realmente ao menos tentou, ou se há dados de treinamento relacionados. Animais sociais fazem compartmentalization naturalmente. Até cães percebem a reação humana e escondem a existência de comida. Eu também, criando meu filho, separo e gerencio informações conforme vida social, conhecimento confidencial, privacidade da criança, informações que ela ainda não está pronta para receber, meus pensamentos íntimos e conteúdos aprendidos de fontes não confiáveis. Inteligência importa, mas sabedoria ainda não é uma consideração de primeira classe no universo dos LLMs. Até cachorros e crianças pequenas parecem estar à frente em capacidade de compartimentalização.
• Vi uma citação marcante na matéria aprofundada relacionada: o sistema CaMeL, proposto pelo Google, evita parte dos riscos da lethal trifecta usando dois LLMs. Um acessa apenas dados não confiáveis, e o outro lida com todo o resto. Um modelo de alta confiança converte instruções em linguagem natural do usuário em código de escopo restrito, e o modelo não confiável preenche as lacunas desse código. Essa arquitetura oferece garantias de segurança, mas em troca impõe fortes restrições ao tipo de trabalho que o LLM pode realizar. Eu não conhecia isso e fiquei curioso sobre a eficácia real. Será que realmente garante segurança “absoluta”, que restrições isso cria e se pode ser uma alternativa prática? Fonte do artigo
  • Já pensei bastante sobre o artigo do CaMeL. É uma abordagem bem interessante, mas é consideravelmente difícil de implementar na prática e o sistema acaba ficando limitado a um conjunto bem restrito de funções. Resumi isso em minha análise.
• Há a analogia de que “engenheiros de IA também precisam pensar como engenheiros de verdade em áreas como construção de pontes, onde erros podem causar mortes”. A ideia é algo como: “engenheiros de IA são condicionados desde a escola a acreditar que, com mais dados de treinamento e prompts mais inteligentes, qualquer problema será resolvido”.
  • Aqui, dizer que “engenheiros de IA precisam pensar como engenheiros de verdade” significa pensar não só como engenheiros de software, mas como engenheiros de fato; já que hoje software também está em pontes e carros, no mínimo deveriam adotar a forma de raciocínio da engenharia de sistemas físicos.
  • Isso quase sugere a exigência de licença profissional em engenharia de software, com certificação ética incluída. Mas, como software antiético porém legal pode gerar lucros enormes, sinto que ideias desse tipo são difíceis de aplicar na prática.
  • A conclusão da mentalidade de “isso se resolve com dados de treinamento melhores” é que essas próprias tragédias acabam virando dados de treinamento.
  • Não devemos esquecer o papel de “arquiteto”, além do de “engenheiro” de software.
• Fico pensando se não haveria oportunidade de negócio em oferecer, por assinatura de baixo custo, um produto de software que monitore automaticamente contas de LLM e filtre/processe em pipeline as entradas.