Neste artigo
Proteger uma aplicação com IA generativa exige defesas que a segurança tradicional não cobre: modelos de linguagem seguem instruções de qualquer texto que leem, podem expor dados do contexto e afirmam inverdades com confiança. A base do trabalho é tratar toda entrada como não confiável, limitar o que o modelo pode acessar e validar tudo que ele produz.
Se a sua empresa colocou (ou vai colocar) um LLM — modelo de linguagem de grande porte — diante de clientes ou conectado a sistemas internos, a superfície de ataque do seu software mudou. O OWASP, referência mundial em segurança de aplicações, mantém uma lista específica dos maiores riscos para aplicações com LLMs — e ela deve orientar seu modelo de ameaças tanto quanto o Top 10 clássico orienta a segurança web.
Por que IA generativa quebra o modelo mental de segurança
Em uma aplicação tradicional, dados e instruções vivem separados: o código decide, os dados são processados. Em uma aplicação com LLM, essa fronteira desaparece — o modelo recebe instruções e dados no mesmo canal, como texto, e não tem como distinguir com certeza uma coisa da outra.
Disso derivam três propriedades que todo time precisa internalizar:
- Todo texto é potencialmente uma instrução. Um e-mail, um PDF, uma página web que o modelo lê podem conter comandos maliciosos embutidos.
- O modelo não guarda segredo. O que está no contexto — prompts de sistema, documentos, dados de outros usuários — pode ser extraído por quem souber perguntar.
- A saída é plausível, não necessariamente verdadeira. O modelo gera texto convincente mesmo quando erra — e código, comandos ou decisões baseados nessa saída herdam o erro.
Os riscos que mais importam (segundo o OWASP)
Prompt injection: o novo ataque número um
É o risco no topo da lista do OWASP para LLMs. Na injeção direta, o usuário instrui o modelo a ignorar suas regras (“esqueça as instruções anteriores e…”). Na indireta — mais perigosa —, a instrução maliciosa vem escondida em um conteúdo que o modelo processa: um documento enviado, uma página consultada, um e-mail lido por um agente. O modelo executa o comando do atacante achando que atende ao usuário.
Não existe correção definitiva: a mitigação é arquitetural. Trate toda entrada como hostil, separe o privilégio do modelo do privilégio do usuário e exija confirmação humana para ações sensíveis.
Vazamento de informações sensíveis
Dados pessoais, segredos de negócio e prompts de sistema podem vazar pela resposta do modelo — seja porque entraram no contexto sem necessidade, seja porque um atacante os extraiu com perguntas bem construídas. A defesa começa antes do modelo: minimize o que entra no contexto, higienize dados sensíveis e nunca dependa do prompt de sistema como mecanismo de sigilo.
Manuseio inseguro da saída
Tratar a resposta do modelo como confiável é o equivalente moderno de concatenar entrada do usuário em uma query SQL. Saída de LLM que vira HTML sem sanitização, comando executado ou consulta a banco de dados é vetor clássico de exploração. Regra: a saída do modelo é entrada não confiável para o resto do sistema.
Autonomia excessiva de agentes
Quando o LLM ganha ferramentas — enviar e-mails, alterar registros, executar código —, cada permissão além do necessário vira dano potencial. Um agente com autonomia demais transforma uma alucinação ou uma injeção de prompt em ação real sobre seus sistemas.
Em aplicações com IA generativa, a pergunta de segurança muda de “o que o usuário pode fazer?” para “o que o modelo pode fazer em nome do usuário — e quem confirma antes?”.
Defesas práticas, em camadas
Nenhum controle isolado resolve; o que funciona é defesa em profundidade:
| Camada | Controles |
|---|---|
| Entrada | Validação e filtragem de conteúdo; separação clara entre instruções do sistema e dados do usuário |
| Contexto | Mínimo necessário no prompt; segregação de dados por usuário; segredos fora do contexto |
| Modelo | Guardrails de conteúdo; monitoramento de tentativas de injeção e de padrões anômalos |
| Saída | Sanitização antes de renderizar, executar ou persistir; validação de formato e de fatos críticos |
| Ações | Menor privilégio por ferramenta; aprovação humana para operações irreversíveis; limites de taxa |
| Auditoria | Log completo de prompts, respostas e ações para investigação e resposta a incidentes |
Duas frentes complementam a arquitetura. Primeiro, a governança de uso interno: defina quais ferramentas de IA o time pode usar e que dados podem (e não podem) ser enviados a elas — o vazamento mais comum ainda é um funcionário colando dados confidenciais em uma ferramenta pública. Segundo, os fundamentos continuam valendo: autenticação, controle de acesso e resposta a incidentes, que revisamos em segurança cibernética para empresas, são a base sobre a qual a segurança de IA se constrói.
Esses controles não são freio à adoção — são o que permite adotá-la em escala, aproveitando o potencial que descrevemos em IA generativa e o impacto nos negócios sem transformar cada novo caso de uso em incidente à espera de acontecer. O mesmo vale para o uso de IA dentro da engenharia, com os cuidados que detalhamos em agentes de IA no desenvolvimento de software.
Como a Tech Coders trata segurança em projetos com IA
Na Tech Coders, segurança entra na arquitetura dos projetos com IA desde o primeiro sprint — não como checklist de véspera de lançamento. Na nossa fábrica de software, aplicamos as diretrizes do OWASP para LLMs nos sistemas que construímos: privilégio mínimo para modelos e agentes, sanitização de entrada e saída, trilhas de auditoria e aprovação humana nas ações críticas. E, como nossos squads usam agentes de IA no próprio fluxo de desenvolvimento, a política de dados e ferramentas é definida em contrato, com clareza sobre o que pode e o que não pode sair do seu ambiente.
Perguntas frequentes
O que é prompt injection e por que é tão difícil de resolver?
É o ataque em que instruções maliciosas — digitadas pelo usuário ou escondidas em conteúdo que o modelo lê — fazem o LLM ignorar suas regras e executar o comando do atacante. É difícil de resolver porque o modelo processa instruções e dados no mesmo canal e não distingue um do outro com garantia. Por isso a mitigação é arquitetural: menor privilégio, validação em camadas e confirmação humana para ações sensíveis.
Usar um provedor de nuvem confiável já não resolve a segurança do LLM?
Não. O provedor protege a infraestrutura e o modelo, mas os riscos da lista OWASP — injeção, vazamento pelo contexto, saída insegura, autonomia excessiva — nascem na sua aplicação: no que você coloca no prompt, no que faz com a resposta e nas permissões que dá ao modelo. Essa responsabilidade não se terceiriza.
Minha empresa usa IA só internamente. Preciso me preocupar mesmo assim?
Sim. Ferramentas internas processam justamente os dados mais sensíveis da empresa, e a injeção indireta funciona em qualquer lugar onde o modelo leia conteúdo de terceiros — um e-mail, um currículo, um documento de fornecedor. Uso interno reduz a exposição pública, não o risco.
