Dano por acidente, dano por atacante

O curso de nível Sênior "Ética de IA: justiça, transparência, prestação de contas" tratou do dano que um sistema causa funcionando como projetado. Um modelo treinado em histórico enviesado reproduz esse viés em escala. Uma decisão não pode ser explicada a quem foi afetado por ela. Ninguém atacou aquele sistema. Ele fez o que foi construído para fazer, e o que foi construído para fazer estava errado.

Este curso é a outra metade. Um sistema justo, bem testado e em plena conformidade no papel ainda pode ser levado a fazer algo que os donos nunca quiseram, por alguém que quer esse resultado. Imagine um agente de suporte que lê a mensagem de um cliente e reembolsa um pedido que nunca teve autorização para reembolsar. Ou um assistente de código que lê um arquivo de um repositório e exfiltra um segredo de outro arquivo, na mesma sessão. Ou um agente de pesquisa que lê uma página envenenada e passa a hora seguinte, e quarenta dólares em chamadas de API, perseguindo uma instrução que aquela página plantou. Nada disso é problema de justiça. Tudo é problema de segurança, e o atacante é o centro da questão, e não um caso extremo.

Duas perguntas diferentes

"Esse sistema é justo?" e "esse sistema pode ser atacado?" parecem relacionadas, mas disciplinas completamente diferentes as respondem. A justiça pergunta como o comportamento normal do sistema se distribui entre as pessoas que ele afeta. A segurança pergunta o que um adversário, alguém tentando ativamente fazer o sistema se comportar mal, consegue levá-lo a fazer contra a vontade dos donos. Um sistema pode ir muito bem na primeira pergunta e falhar de forma catastrófica na segunda. O contrário também acontece. Um sistema que trata todo usuário do mesmo jeito ainda pode estar a um input bem montado de entregar esse tratamento a um atacante que nunca teve direito a ele.

Threat modeling é a disciplina da segunda pergunta. Ela pergunta como o sistema quebra, e para quem, de propósito e antes que um incidente responda por você. Se o comportamento do sistema é bom é outra pergunta.

Threat modeling não começou com IA

O threat modeling clássico já tem um método que funciona, e nada dele se aposenta aqui. O STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) ainda nomeia categorias reais de falha num sistema de IA. As fronteiras de confiança (trust boundaries) continuam importando: a linha onde o dado passa de algo que você controla para algo que você não controla. Você ainda as desenha do mesmo jeito. Faça o diagrama do sistema, marque cada fronteira e pergunte o que a atravessa e se isso merece confiança do outro lado.

O novo não é uma categoria nova de dano. É um formato novo de input. Numa aplicação web convencional, o corpo da requisição é dado. A aplicação decide o que fazer com ele. O dado só muda essa decisão por caminhos que a aplicação escreveu, como uma string SQL que alguém esqueceu de parametrizar ou um template que alguém esqueceu de escapar. O prompt de um modelo de linguagem é diferente. Qualquer texto que chega ao modelo, seja a mensagem do usuário, um documento recuperado ou o retorno de uma tool, é dado e instrução ao mesmo tempo. O modelo não tem um jeito confiável de saber quais partes deve obedecer. Não existe campo que você possa escapar para uma frase deixar de ser um comando plausível. É por isso que este curso é um assunto próprio, e não um capítulo de AppSec clássico.

A segunda novidade: não dá para enumerar os estados

Um programa tradicional tem um conjunto finito e inspecionável de estados sobre os quais você consegue raciocinar, porque você escreveu a lógica que os produz. O comportamento de um modelo grande é aprendido de dados numa escala que ninguém lê. A resposta dele a um input é uma distribuição de probabilidade, e não uma consulta. Não dá para listar "os inputs que o fazem se comportar mal" do jeito que você lista os ramos de um if. Não há ramo. Há uma função ponderada com bilhões de parâmetros que ninguém consegue prever por completo diante de um input novo, nem as pessoas que a treinaram. O threat modeling de sistemas de IA precisa trabalhar dentro dessa restrição, em vez de fingir que o modelo é uma especificação que dá para conferir por inteiro.

O que "agente autônomo" acrescenta

Tudo acima vale para um chatbot simples que só responde com texto. Um agente acrescenta uma segunda camada. É um modelo ligado a tools, capaz de ler arquivos, chamar APIs, gastar dinheiro e tomar ações com efeitos reais. Agora o input não confiável não arrisca só uma frase ruim; ele arrisca uma ação ruim. O resto do curso passa bastante tempo aqui, porque é aqui que moram as vulnerabilidades dos agentes autônomos. Um modelo que só fala pode envergonhar você. Um modelo que age pode custar dinheiro, vazar dados ou fazer algo que você não consegue desfazer.

O que este curso cobre

1. Esta lição: por que sistemas de IA precisam de threat modeling como disciplina própria. O input deles não é confiável e também é instrução, e o comportamento deles não dá para enumerar.
2. Prompt injection, direta e indireta: por que a indireta é a que quebra sistemas em produção, e por que defesas no nível do prompt acrescentam profundidade sem resolver o problema.
3. A superfície de ataque própria dos agentes: abuso de tools, o problema do confused deputy, excesso de autonomia (excessive agency), loops descontrolados e envenenamento de memória.
4. Confiança entre agentes e a fronteira de privilégio: o que acontece quando o output de um agente vira a instrução de outro. A resposta de arquitetura que se sustenta é restringir o que o agente pode fazer, além do que pedem a ele. Um desafio faz você codificar essa decisão.
5. Risco de dados e de cadeia de suprimentos: envenenamento de dados de treino, modelos com backdoor baixados de um hub, desserialização insegura de modelos e risco de dependências no ferramental de IA.
6. Ataques voltados ao modelo: extração, inferência de pertencimento (membership inference) e vazamento de informação sensível pelos outputs. A lição separa as preocupações práticas para um produto Rails típico das que são mais acadêmicas nessa escala.
7. Defesas que se sustentam, e para onde ir depois: privilégio mínimo, aprovação humana no fluxo, sandbox, limites de gasto, proveniência e logs que permitem reconstruir um incidente. Tudo se liga à trilha de evidências do curso de nível Sênior "Sistema de gestão de IA: ISO 42001".

Este é um guia de engenharia para construir e revisar sistemas Rails integrados a IA de forma mais defensável. Ele não é uma auditoria de segurança, e não substitui uma num sistema que guarda dados sensíveis ou dinheiro de verdade. Trate cada seção de "como você se defenderia disso" como um checklist inicial para o threat model do seu sistema, e não como um checklist pronto.