Fazer modelagem de ameaças de aplicações de IA generativa exige mais do que analisar o modelo de linguagem isoladamente. O modelo é apenas um componente da aplicação.
Boa parte dos exercícios de modelagem de ameaças em projetos de IA ainda se comporta como se o modelo fosse a aplicação inteira. Toda a atenção recai sobre o prompt e a resposta. O restante do fluxo, de onde vem o dado, com que identidade a aplicação age, o que ela pode fazer depois de responder, fica fora da análise.
Esse recorte produz um modelo de ameaças incompleto. Uma aplicação de IA generativa raramente é só "entrada de texto, modelo, saída de texto". Na maioria dos casos reais, ela:
- recupera contexto de alguma fonte de dados
- opera sob uma identidade com determinado nível de acesso
- pode chamar plugins ou ferramentas externas
- gera uma saída que, com frequência, aciona uma ação em outro sistema
Este artigo percorre esse fluxo etapa por etapa, com perguntas de Modelagem de ameaças para cada uma. Elas não substituem uma metodologia completa, nem formam uma lista exaustiva. Servem como ponto de partida, a ser adaptado à arquitetura de cada aplicação.
Entrada de dados
A primeira etapa é a mais discutida publicamente: o que entra na aplicação, seja como prompt de um usuário, seja como dado processado automaticamente por um pipeline.
Perguntas de Modelagem de ameaças para essa etapa:
- A entrada vem de um usuário autenticado, de um sistema automatizado ou de uma fonte externa à organização?
- Existe validação de que o conteúdo recebido não tenta manipular o modelo por meio de instruções embutidas no próprio dado?
- Se a entrada vem de um documento, e-mail ou página web processada pela aplicação, essa origem recebe o mesmo nível de ceticismo que se teria com um usuário desconhecido?
Tratar toda entrada como potencialmente adversária, mesmo quando parece interna, é o ponto de partida dessa etapa.
Recuperação de contexto
Essa etapa concentra a maior parte da complexidade em aplicações de IA generativa atuais. Raramente um modelo responde só com base no que foi digitado no momento. A aplicação busca contexto adicional, e esse contexto chega por três caminhos diferentes, cada um expondo dado de uma forma própria.
Entrada direta em prompts. O caminho mais visível: dado sensível inserido diretamente por um usuário dentro da conversa. Pergunta central: existe algum controle que impeça ou sinalize a inserção de dado sensível em um prompt antes do processamento?
Permanência em históricos, memória ou logs. Esse caminho expõe dado depois da interação original. Histórico de conversa, memória de longo prazo e registros de log criam uma superfície de dado que persiste no tempo, muitas vezes com controle de acesso mais fraco do que o resto do ambiente. Pergunta central: quem acessa esse histórico, por quanto tempo ele é retido, e esse acesso é auditado como qualquer outro repositório sensível?
Retorno por mecanismos de recuperação (RAG). O caminho menos intuitivo. O dado não entra pela interação do usuário nem fica em um histórico de conversa: é buscado dinamicamente em uma base de conhecimento e injetado no contexto da resposta. Pergunta central: o mecanismo de busca respeita as mesmas permissões que o usuário teria ao consultar aquela base diretamente, ou a camada de recuperação tem acesso mais amplo, criando um caminho indireto até um dado que o usuário não poderia acessar de outra forma?
Esses três caminhos costumam coexistir na mesma aplicação. Um modelo de ameaças que avalia só a entrada direta, por ser a mais óbvia, deixa os outros dois sem cobertura.
Identidades
Toda aplicação de IA generativa opera sob alguma identidade: a do usuário que iniciou a interação, uma identidade de serviço própria da aplicação, ou uma combinação das duas em pontos diferentes do fluxo.
Perguntas de Modelagem de ameaças para essa etapa:
- A aplicação segue o princípio de menor privilégio, restrita ao que aquele usuário específico poderia acessar?
- Ou ela roda sob uma identidade de serviço com permissão mais ampla do que qualquer usuário individual teria?
- Existe uma identidade única e genérica para toda a aplicação, ou cada componente (recuperação de contexto, chamada de plugins, execução de ação) opera sob identidades distintas?
Se a identidade de serviço tem permissão mais ampla do que o necessário, uma manipulação bem-sucedida do modelo pode se traduzir em uma ação com acesso que nenhum usuário humano naquele fluxo possuiria sozinho.
Plugins ou ferramentas
Quando a aplicação pode chamar plugins, ferramentas externas ou funções que interagem com outros sistemas, essa etapa concentra um dos riscos mais diretos do fluxo: a diferença entre o modelo sugerir uma ação e o modelo ser capaz de executá-la.
Perguntas de Modelagem de ameaças para essa etapa:
- A ferramenta precisa, de fato, da permissão que tem hoje, dada a finalidade real da aplicação?
- Existe confirmação humana antes de uma ação irreversível, ou a execução é automática a partir de uma decisão do próprio modelo?
- Uma ferramenta pode chamar outra ferramenta, criando uma cadeia de ações que nenhum componente isolado foi desenhado para validar como um todo?
Saídas
A saída costuma ser tratada como o fim do fluxo, mas é, ela própria, uma superfície de risco, por dois motivos.
Primeiro: vazamento de dado através da resposta. Informação que entrou em alguma etapa anterior (prompt, histórico, contexto via RAG) pode reaparecer para um usuário que não deveria ter acesso a ela.
Segundo: o conteúdo da saída pode servir como vetor de ataque para o próximo sistema que a consome, especialmente quando ela é processada automaticamente, sem revisão humana no meio do caminho.
Pergunta central: existe verificação sobre o conteúdo da saída antes de ela ser exibida ou repassada a outro sistema, ou a aplicação assume, por padrão, que a resposta do modelo é segura para ser consumida sem validação?
Ações em sistemas conectados
A última etapa recebe, com frequência, menos atenção em um modelo de ameaças, porque a análise já se esgotou no modelo em si. É também a etapa onde o risco deixa de ser hipotético: um sistema de produção alterado, um e-mail enviado, uma transação iniciada.
Perguntas de Modelagem de ameaças para essa etapa:
- Existe um limite claro sobre quais sistemas podem ser alterados a partir de uma ação originada nesse fluxo?
- Existe log de auditoria suficiente para reconstruir, depois do fato, qual decisão do modelo levou a qual ação em qual sistema?
- Existe algum teste de que a cadeia completa, da entrada manipulada até a ação final, não consegue de fato se concretizar?
Da hipótese ao teste
Um modelo de ameaças seguindo essas seis etapas produz um conjunto de hipóteses: pontos onde a aplicação pode estar exposta, com base em como dados, identidades e permissões se movem pelo fluxo. Essas hipóteses são necessárias, mas não confirmam, sozinhas, que um risco é real.
É aqui que o Modelagem de ameaças se conecta a teste ofensivo. Um pentest com apoio de IA verifica, na prática, se as hipóteses da modelagem de ameaças são exploráveis:
- Uma instrução adversária na entrada realmente atravessa a etapa de recuperação de contexto?
- Uma identidade de serviço com permissão ampla pode ser usada para uma ação não autorizada?
- Uma ferramenta conectada ao modelo pode ser manipulada para executar algo fora do escopo pretendido?
Modelo de ameaças sem teste é hipótese não verificada. Teste ofensivo sem modelo de ameaças prévio é busca sem direção, com risco de validar só os cenários mais óbvios. As duas disciplinas se completam.
Próximos passos
Esse trabalho de Modelagem de ameaças e validação por teste ofensivo faz parte das jornadas de AppSec e DevSecOps e Exposição Cibernética da IBLISS, da análise de arquitetura até a verificação prática de quais hipóteses de risco se confirmam em ambiente real.
Se sua organização já tem aplicações de IA generativa em produção e ainda não mapeou o fluxo completo de dados, identidades e permissões por trás delas, fale com um especialista da IBLISS para estruturar essa análise.
Leia mais conteúdos sobre segurança da informação no blog da IBLISS