Segurança em LLMs: guia técnico para avaliar, proteger e reduzir a superfície de ataque
Aplicações baseadas em Large Language Models deixaram de ser simples interfaces de conversa. Atualmente, elas consultam bases corporativas, analisam documentos, chamam APIs, operam ferramentas, atualizam registros e participam de decisões empresariais. Essa evolução aumenta a produtividade, mas também transforma o LLM em um componente relevante da arquitetura de segurança.
O risco não está apenas no modelo. Uma solução completa normalmente envolve prompts do usuário, instruções de sistema, memória, mecanismos de RAG, bancos vetoriais, arquivos, páginas externas, plugins, ferramentas, APIs, sistemas de identidade e código responsável por interpretar a resposta gerada. Cada conexão cria uma possível entrada, saída ou caminho de abuso.
Por isso, a avaliação deve começar pelo desenho da arquitetura. É necessário mapear de onde vêm os dados, quais informações podem alcançar o modelo, quais ferramentas estão disponíveis e o que acontece depois que o LLM produz uma resposta. A lógica é semelhante à análise de uma aplicação web: toda entrada deve ser considerada não confiável, e nenhuma saída deve ser executada sem validação adequada.
Como mapear a superfície de ataque
O inventário deve incluir prompts digitados, uploads, mensagens de e-mail, páginas da internet, documentos internos, resultados de mecanismos de busca, registros recuperados por RAG e respostas de ferramentas. Mesmo quando o conteúdo parece legítimo, ele pode conter instruções ocultas ou manipulações destinadas a alterar o comportamento do agente.
Também é importante registrar todas as consequências possíveis de uma resposta. Exibir texto em uma tela apresenta um risco diferente de inserir o conteúdo em HTML, convertê-lo em uma consulta SQL, enviá-lo para outro serviço ou utilizá-lo para executar uma função. Quanto maior o impacto da ação, mais rigorosa deve ser a validação.
O modelo pode sugerir uma ação, mas não deve ser o responsável final por autorizá-la. Permissões, regras de negócio e controles de acesso precisam permanecer em componentes determinísticos da aplicação.
Prompt injection: conteúdo não é autoridade
Prompt injection acontece quando um texto influencia o modelo a abandonar ou modificar o comportamento esperado. A técnica pode ser direta, quando o próprio usuário formula a tentativa, ou indireta, quando a instrução maliciosa está escondida em um documento, página, e-mail ou resultado recuperado.
Um exemplo comum ocorre quando o usuário solicita o resumo de uma mensagem. Dentro do e-mail, pode haver uma frase instruindo o agente a encaminhar documentos, ignorar políticas ou revelar informações internas. Se o sistema tratar todo texto recuperado como instrução confiável, o atacante poderá controlar o fluxo por meio de uma fonte aparentemente legítima.
Instruções no system prompt ajudam, mas não constituem uma barreira suficiente. Frases como “ignore comandos maliciosos” podem ser contornadas por técnicas de engenharia de prompt, ambiguidades e combinações de contexto. A defesa precisa estar distribuída entre isolamento de dados, validação de ações, controle de permissões e monitoramento.
Excessive agency: poder demais nas mãos do agente
O risco aumenta quando o LLM pode chamar ferramentas. Uma função aparentemente inofensiva pode ler dados confidenciais, alterar contas, enviar mensagens, criar regras ou executar operações irreversíveis. Se o modelo decidir sozinho o que pode fazer, uma manipulação de contexto poderá transformar uma interação textual em uma ação de alto impacto.
A estratégia central é aplicar o princípio do menor privilégio. Cada agente deve receber apenas as ferramentas indispensáveis, com parâmetros limitados e escopos claramente definidos. Funções de leitura e escrita devem ser separadas, e operações sensíveis devem exigir confirmação explícita ou aprovação humana.
Também é recomendável utilizar listas de ações permitidas, limites de frequência, validação de destinatários e bloqueio de parâmetros inesperados. Uma ferramenta não deve aceitar comandos genéricos quando pode oferecer operações específicas e restritas.
Insecure output handling: a resposta também é entrada
Uma resposta gerada pelo LLM não deve ser considerada segura apenas porque foi produzida pelo próprio sistema. Ela pode conter HTML, JavaScript, consultas, comandos, dados falsificados ou parâmetros manipulados. Quando a saída é passada diretamente para outro componente, o risco pode evoluir para XSS, injeção de SQL, execução de comandos ou fraude de fluxo.
A aplicação deve validar o formato, aplicar codificação contextual, utilizar consultas parametrizadas e rejeitar campos fora do esquema esperado. Respostas estruturadas devem ser verificadas com validadores de tipo e regras de negócio antes de qualquer processamento.
Quando possível, o sistema deve trabalhar com esquemas rígidos, enumerando valores aceitos e impedindo que o modelo produza campos arbitrários. Mesmo assim, a validação no servidor continua obrigatória.
Vazamento de dados e exposição de prompts
Informações confidenciais podem aparecer no contexto enviado ao modelo, na memória da conversa, nos logs, nos mecanismos de observabilidade ou em mensagens de erro. O problema pode envolver dados pessoais, segredos de API, documentos internos, informações financeiras e instruções de sistema.
A solução deve reduzir a quantidade de dados compartilhados, aplicar mascaramento, remover segredos antes do processamento e estabelecer políticas de retenção. Logs precisam ser avaliados com o mesmo cuidado que bancos de dados, pois podem concentrar prompts completos, respostas e tokens de autenticação.
O acesso a instruções internas também merece atenção. Embora não seja possível garantir que um modelo nunca revele fragmentos de contexto, a arquitetura deve evitar que o system prompt contenha segredos, credenciais ou regras que dependam de permanecer ocultas.
RAG, embeddings e fontes externas
Sistemas de Retrieval-Augmented Generation ampliam o conhecimento do modelo, mas criam novas possibilidades de ataque. Documentos maliciosos podem ser inseridos na base, conteúdos antigos podem permanecer indexados e permissões podem ser perdidas durante a recuperação.
O controle de acesso precisa ser aplicado antes da consulta ou filtrado de forma confiável no momento da recuperação. Um usuário não pode receber trechos apenas porque foram encontrados no banco vetorial. Metadados de autorização, origem, data e classificação devem acompanhar cada documento.
Também é necessário controlar a ingestão. Arquivos devem passar por verificação de origem, análise antimalware, classificação e revisão quando apresentarem instruções operacionais. O conteúdo recuperado deve ser tratado como dado não confiável, nunca como uma extensão automática das instruções do sistema.
Metodologia prática de avaliação
Uma avaliação consistente pode seguir estas etapas:
1. Desenhar o fluxo completo de dados e ações.
2. Listar todas as entradas diretas e indiretas.
3. Identificar ferramentas, APIs, bancos e permissões disponíveis.
4. Classificar cada saída conforme seu impacto.
5. Testar injeções diretas e indiretas.
6. Verificar tentativas de extração de contexto e dados privados.
7. Avaliar chamadas de ferramentas com parâmetros inesperados.
8. Testar respostas malformadas, ambíguas e excessivamente longas.
9. Confirmar se a aplicação bloqueia ações fora do escopo.
10. Registrar evidências, impacto, probabilidade e medidas corretivas.
Os testes devem incluir variações linguísticas, textos codificados, instruções divididas em múltiplas mensagens, conteúdo inserido em documentos e tentativas de manipulação por autoridade falsa. O objetivo não é apenas verificar se o modelo responde corretamente, mas se a aplicação permanece segura quando ele falha.
Proteção em camadas
O LLM não deve funcionar como firewall, mecanismo de autorização ou filtro único. Uma arquitetura robusta combina várias barreiras:
– autenticação e autorização convencionais;
– segregação de ambientes e contas de serviço;
– permissões mínimas para cada ferramenta;
– validação determinística de entradas e saídas;
– filtros para dados sensíveis;
– confirmação humana em ações críticas;
– limites de tempo, volume e frequência;
– logs auditáveis e alertas;
– isolamento de conteúdo externo;
– revisão periódica de prompts, ferramentas e conectores.
Essa abordagem reduz a dependência de uma única camada probabilística. Se o modelo interpretar uma instrução de maneira incorreta, controles posteriores ainda devem impedir o impacto.
Red teaming e segurança no ciclo de desenvolvimento
Testes de segurança precisam acompanhar toda a vida útil da solução. Mudanças no modelo, no prompt, na base vetorial, nos conectores ou nas permissões podem alterar o comportamento do sistema e reabrir vulnerabilidades já corrigidas.
O red teaming deve combinar testes automatizados e avaliações manuais. Além de ataques de prompt injection, é importante investigar escalada de privilégios, vazamento entre usuários, abuso de ferramentas, manipulação de documentos e contorno de aprovações.
No pipeline de desenvolvimento, modelos e prompts devem ser tratados como componentes versionados. Cada alteração precisa passar por testes de regressão, análise de impacto e revisão de segurança. Métricas úteis incluem taxa de bloqueio de ataques, chamadas indevidas de ferramentas, exposição de dados e quantidade de ações que exigiram intervenção humana.
O papel de AppSec e Segurança da Informação
Para equipes de AppSec, aplicações com LLM exigem ampliar práticas tradicionais de threat modeling, testes de API e revisão de código. O modelo adiciona comportamento probabilístico, mas os riscos continuam conectados a problemas conhecidos: controle de acesso inadequado, injeção, exposição de dados e falhas de validação.
Já a área de Segurança da Informação deve participar da definição de políticas para dados, fornecedores, retenção, auditoria, residência das informações e uso de serviços externos. A governança precisa estabelecer quais dados podem ser enviados ao modelo, quais ações são proibidas e quando a aprovação humana é obrigatória.
Uma implementação segura não depende de um prompt perfeito. Ela nasce de uma arquitetura que assume falhas, limita privilégios, valida cada etapa e mantém o controle das decisões críticas fora do modelo. Ao tratar o LLM como um componente não confiável dentro de um sistema maior, as organizações conseguem aproveitar seus benefícios sem transformar automação em uma nova porta de entrada para ataques.