Capítulo 2 — Threat Modeling para Sistemas LLM

Segundo post do passeio capítulo a capítulo pelo LLM Primer VII: Segurança de IA. O capítulo que pega as quatro perguntas de Shostack, STRIDE, PASTA e MITRE ATLAS e as aplica a um sistema cujo componente mais poderoso lê toda entrada como potencialmente instrucional.

Por que este capítulo existe

O Capítulo 1 sustentou que a segurança de IA é estruturalmente diferente. O Capítulo 2 dá a essa diferença forma operacional. As quatro perguntas de Adam Shostack — no que estamos trabalhando, o que pode dar errado, o que vamos fazer a respeito, fizemos um bom trabalho — são as mesmas para qualquer sistema, mas os diagramas, inventários de ativos e catálogos de adversários que as respondem ficam diferentes quando o sistema em questão inclui lógica de construção de prompt, um pipeline de recuperação, um registro de ferramentas e uma função probabilística que trata conteúdo recuperado em pé de igualdade com as instruções do desenvolvedor. O capítulo percorre os frameworks — STRIDE, PASTA, MITRE ATLAS, NIST AI 100-2 — e produz o template operacional de um threat model de LLM ao qual os capítulos seguintes voltam a se referir.

Em uma linha: o threat model de um sistema LLM é a mesma disciplina de qualquer outro sistema, mas precisa começar por um diagrama que exponha os componentes de construção de prompt, recuperação, ferramenta e manejo de saída como distintos — porque "uma caixa rotulada LLM" esconde a maior parte da estrutura relevante para segurança.

2.1 Frameworks se adaptam, diagramas não podem ficar preguiçosos

STRIDE — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — mapeia surpreendentemente bem em sistemas LLM. Spoofing vira ataques de identidade na API ou personificação de usuário. Tampering vira prompt injection, envenenamento de dados de treinamento e manipulação do índice de recuperação. Repudiation vira as disputas sobre quem enviou qual prompt e quem produziu qual saída. Information disclosure vira extração de dados de treinamento, vazamento de system prompt e exposição cross-tenant. Denial of service vira o LLM10 da OWASP, consumo ilimitado por prompts caros e enchentes de tokens. Elevation of privilege vira a fronteira de uso de ferramenta — um usuário que induz o modelo a chamar uma ferramenta privilegiada herda os privilégios dessa ferramenta. PASTA acrescenta contexto de negócio e simulação de adversário para times que já fazem red team. Os dois frameworks pressupõem um diagrama de fluxo de dados que separa os componentes dos quais depende a pergunta de vigilância. Para sistemas LLM, o diagrama sempre deveria separar a lógica de construção de prompt, o pipeline de recuperação, o registro de ferramentas, a chamada do modelo, o caminho de manejo de saída e o caminho de logging.

2.2 Ativos que não aparecem em inventários convencionais

Um threat model é tão bom quanto seu inventário de ativos. Sistemas LLM introduzem categorias desconhecidas para times cujo trabalho anterior era em aplicações convencionais. O próprio modelo tem vários subativos — os pesos (um binário de vários gigabytes que representa um investimento significativo em treinamento), o comportamento documentado (system prompt, políticas de segurança, alignment training) e a reputação (uma falha pública danifica o produto independentemente de qualquer comprometimento técnico). Os dados cobrem dados de treinamento, de fine-tuning, corpora de recuperação, entradas de usuário e saídas; cada um tem seus próprios requisitos de confidencialidade, integridade e disponibilidade. O próprio prompt agora é um ativo — a propriedade intelectual de muitos produtos vive em um system prompt refinado ao longo de meses, e a lista OWASP de 2025 chama explicitamente o vazamento de system prompt de LLM07. A infraestrutura cobre a stack de inferência, o vector store, as interfaces de ferramenta e as credenciais que os amarram. Logs são um ativo porque são o registro forense, e ativos de segunda ordem — reputação do modelo, situação regulatória, confiança do cliente — dependem de os ativos primários sobreviverem ao contato com o tráfego.

2.3 Adversários têm incentivos específicos

Um threat model que protege igualmente contra tudo não protege contra nada. O inventário de adversários precisa ser específico. Usuários curiosos exploram o sistema para ver o que ele faz — usam técnicas de rede social, seu volume é alto, seu impacto individual por incidente é baixo, mas seu efeito cumulativo sobre a segurança aparente do sistema é significativo. Usuários maliciosos pretendem dano específico — extrair conteúdo que o sistema deveria recusar, roubar dados de outros usuários ou o system prompt, usar o sistema para atacar terceiros por phishing redigido ou malware gerado. Concorrentes extraem o modelo (Capítulo 8) ou o system prompt para reduzir seu próprio custo de desenvolvimento. Insiders operam de dentro da fronteira de confiança. Atores estatais combinam ataques em nível de modelo com o tradecraft mais amplo, e seus alvos costumam ser organizações, não o modelo diretamente. Agentes automatizados — eles mesmos LLMs, às vezes dirigidos por outros adversários — são a categoria mais nova e a que o Capítulo 17 retoma. Cada categoria de adversário tem capacidades diferentes, incentivos diferentes e perfis de detecção diferentes, e as mitigações que elevam o custo contra uma podem não afetar outra.

Vale a pena guardar: em deployments de LLM baseados em API, grandes porções do que o time de segurança chama de "lógica de aplicação" — o comportamento do modelo — ficam do outro lado de uma fronteira contratual que o time não pode inspecionar. O threat model precisa reconhecer essa assimetria em vez de fingir que o modelo é apenas mais um componente.

O que o Capítulo 2 prepara

O template desenvolvido aqui — descrição de sistema em uma página, diagrama de fluxo de dados com fronteiras de confiança, inventário de ativos, catálogo de adversários, enumeração de ameaças por STRIDE, mapeamento de mitigações, registro de risco residual — é o quadro que o restante do livro preenche. O Capítulo 3 expande a categoria de ativos de dados em toda a sua estrutura — riscos dos dados de treinamento, memorização e extração, manejo de entradas sensíveis, criptografia e retenção. O Capítulo 4 retoma prompt injection, que a categoria tampering de STRIDE já nomeou como a ameaça dominante contra o componente de construção de prompt. Os capítulos 5 e 6 desenvolvem as mitigações para prompt injection nas camadas de entrada, saída e RAG. Capítulos posteriores voltam ao mesmo template — Capítulo 11 para observabilidade, Capítulo 12 para identidade — mas o inventário de ativos e o catálogo de adversários introduzidos aqui são o que esses capítulos estendem.

Próximo — Capítulo 3: Segurança de Dados e Privacidade. Risco dos dados de treinamento, memorização e extração, os incidentes da Samsung e do Garante e a disciplina de criptografia, isolamento e retenção que a segurança de dados em sistemas LLM exige.

Quer o panorama completo? O capítulo do livro inclui os exemplos executáveis de diagrama de fluxo de dados, o registro de ameaças passo a passo para um assistente de suporte com RAG, as tabelas completas de mapeamento STRIDE e PASTA e os quadros In Plain English que este artigo apenas resume. Veja o LLM Primer VII na Amazon →