Software seguro é uma decisão de arquitetura, não um recurso comprado à parte. Trate a resposta do modelo como entrada hostil e você elimina boa parte das falhas antes do primeiro incidente. A pergunta deixa de ser se sua equipe deve usar IA, e passa a ser onde colocar os limites.
IA e segurança de software funcionam melhor quando você parte de uma premissa incômoda: a saída do modelo é tão não confiável quanto o input de um usuário. Isso vale para o prompt que você monta, para o tool call que o modelo dispara e para o SQL que volta pronto. Tratar essa saída como entrada hostil resolve boa parte dos problemas antes de eles virarem incidente.
A OWASP Top 10 for LLM Applications lista prompt injection como risco número um desde 2023, o primeiro ano da lista. Já o relatório de vulnerabilidades da NVD registrou mais de 29 mil CVEs em 2024, contra cerca de 13 mil em 2016 — o volume quase triplicou em oito anos. O modelo populariza um vetor, não cria um problema novo.
Se você precisa argumentar com quem decide, compare os números que medem a mesma coisa:
| Período | CVEs publicadas (NVD) | Risco nº 1 em aplicações com LLM (OWASP) |
|---|---|---|
| 2016 | ~13 mil | lista não existia |
| 2023 | ~28 mil | prompt injection |
| 2024 | ~29 mil | prompt injection |
O caminho prático tem três passos:
- Trate toda saída do modelo como entrada de usuário e valide no servidor, nunca no prompt.
- Aplique o menor privilégio possível em cada tool call que o modelo pode disparar.
- Registre tentativas de injeção como evento de segurança, igual você faz com tentativas de login falho.
A saída de um modelo é entrada hostil: trate tudo que volta como dado não confiável e valide antes de executar. As seções abaixo mostram onde essa inversão quebra sistemas e como separar o uso de IA que tolera erro do uso que não tolera.
IA e segurança de software: por que a saída do modelo é entrada hostil
IA e segurança de software parte de uma inversão simples: o texto que volta do modelo deve ser validado exatamente como você valida o formulário de um usuário desconhecido. Quando o sistema executa essa resposta direto, uma alucinação ou um prompt injection deixa de ser erro cosmético e passa a ser ação real no seu banco. O OWASP Top 10 para aplicações com LLM coloca o prompt injection no topo da lista de riscos desde 2023, e a categoria cobre exatamente esse caminho: dado do usuário virando instrução executada.
O argumento a favor de usar modelos para achar falhas é assimétrico. Se a IA aponta uma vulnerabilidade que existe, você ganhou uma correção. Se aponta uma que não existe, o custo é o tempo de checar. Essa assimetria explica por que tanta gente está usando modelos para revisar código, endpoints e autenticação. O relatório 2024 State of AI in Software Development encontrou que a maioria dos times entrevistados já usava alguma forma de assistente em revisão de código, com ganho declarado de produtividade em tarefas bem delimitadas.
A Internet se enche de casos de modelos de ponta escapando de sandbox e encontrando exploits para sair dele. Isso mostra capacidade ofensiva, não garantia de cobertura. Um modelo que acha uma falha hoje não acha todas amanhã, e o resultado varia conforme o escopo que você entrega.
O detalhe que separa os dois usos não é o modelo, é o contrato da saída. Antes de deixar a resposta virar ação, defina o formato esperado e rejeite o que não bate. A tabela abaixo resume o que muda entre revisar e executar.
| Uso | Erro do modelo vira | Validação necessária | Custo de errar |
|---|---|---|---|
| IA revisora | hipótese falsa na sua lista | triagem humana antes do fix | minutos de triagem |
| IA executora | chamada de ferramenta real | schema fixo, allowlist de ações, limite de escopo | alteração em produção |
| IA com acesso a dados | consulta a dado sensível | filtro de tenant e de coluna por papel | vazamento entre clientes |
Para sair do discurso e virar prática, o caminho é ordenado:
- Trate a saída do modelo como entrada de usuário: parseie, valide tipo, tamanho e faixa antes de usar.
- Declare um schema fechado para cada ação executável e recuse qualquer campo fora dele.
- Separe revisão de execução em processos diferentes, com permissões diferentes e logs distintos.
A consequência prática é separar dois usos. Primeiro, IA como revisora: gera hipóteses para você triar. Segundo, IA como executora: chama ferramentas dentro do seu sistema. O primeiro uso tolera erro. O segundo precisa de validação determinística em cada passo.
Prompt injection: o SQL injection da camada de IA
Prompt injection é quando o texto do usuário vira instrução para o modelo. Ele não desliga o sistema: ele reescreve o que o sistema deve fazer. Em 2023, pesquisadores demonstraram o ataque em plugins de navegador e assistentes comerciais, publicado em paper revisado por pares. A defesa não é "prompt perfeito", é arquitetura.
A analogia com SQL injection ajuda mais do que atrapalha. Nos dois casos, o sistema mistura dado com comando na mesma string. Nos dois casos, a defesa separa os dois papéis, valida entradas e limita o que o componente consegue fazer mesmo quando a validação falha. A diferença é que em SQL você tem sintaxe formal para separar; em texto livre, não.
O impacto cresce rápido. O OWASP LLM Top 10 coloca prompt injection como risco número um da lista desde a primeira edição, publicada em 2023. Outro levantamento do NIST, de 2024, trata injeção de prompt como risco de segurança recorrente em sistemas de IA generativa. Vale ler os dois antes de desenhar qualquer fluxo que aceite texto livre de usuário.
Sanitizar prompt com outro modelo é uma camada, não a solução. Classificadores de intenção erram, e um atacante criativo ajusta a formulação até passar. Guardrails determinísticos no código continuam sendo a barreira que não depende da qualidade do modelo. A ordem que funciona na prática:
- Separe dado de instrução: coloque a entrada do usuário sempre em um campo delimitado e nunca junto do system prompt.
- Valide no código antes de chamar o modelo: tamanho, formato, origem e permissões do usuário.
- Limite o que a ferramenta pode fazer: escopo de leitura, lista de domínios, sem escrita livre em produção.
- Registre cada chamada com entrada e saída para revisão posterior.
Um comparativo rápido das abordagens de defesa:
| Camada | O que faz | Onde falha |
|---|---|---|
| Delimitação no prompt | Separa texto do usuário do system prompt | Atacante quebra o delimitador |
| Classificador de intenção | Bloqueia entrada maliciosa antes do modelo | Falso negativo em reformulação nova |
| Guardrail no código | Valida formato, permissões e escopo | Exige engenharia por ferramenta |
| Auditoria de chamadas | Detecta abuso depois do fato | Não impede o dano imediato |
Tool calling e o princípio do menor privilégio
O tool calling vira risco quando a ferramenta exposta ao modelo é ampla demais. Um sistema que aceita "quero minhas compras do mês passado" e devolve SQL pronto parece elegante, mas dá ao modelo poder de alterar ou ler qualquer tabela se o prompt for manipulado.
A regra prática é trocar ferramentas cruas por ferramentas estreitas. Em vez de uma ferramenta que executa SQL, ofereça uma que busca documentos indexados. Em vez de enviar e-mail, ofereça criar rascunho para revisão humana. O modelo mantém utilidade e perde alcance destrutivo.
Ferramentas como shell, SQL direto e envio de e-mail fora do controle do usuário são as que exigem mais cuidado. Se o modelo pode disparar qualquer comando, nenhum guardrail de prompt sobrevive a uma alucinação bem construída.
A comparação abaixo resume a troca que costuma resolver o problema.
Como validar o retorno do modelo antes de agir
Validar o retorno do modelo significa tratar a resposta como dado bruto, não como comando. Você confere formato, faixa de valores e permissão antes de qualquer escrita no banco ou chamada externa. Sem isso, o sistema executa a instrução que o provedor devolveu sem saber se ela faz sentido.
Em vez de rodar o SQL que voltou do modelo, passe a resposta por um query builder com parâmetros definidos. Em vez de aceitar qualquer campo, use um schema que recusa o que não está previsto. Em vez de confiar no identificador de usuário que o modelo citou, busque o identificador na sua própria sessão autenticada.
Essa camada também registra o que foi rejeitado. Um log de respostas inválidas mostra quais prompts estão sendo manipulados e ajuda a ajustar o escopo das ferramentas.
Segredos nunca entram em prompt
Chaves de API, credenciais de banco e tokens de serviço não podem aparecer no texto enviado ao provedor. Isso vale para o prompt, para o contexto recuperado e para qualquer dado que o modelo consiga ler por tool call. Vazamento de segredo não se desfaz com rotação rápida.
O erro comum é conveniência. Alguém coloca as variáveis de ambiente no contexto para o modelo "entender melhor o sistema" e o segredo passa a trafegar para fora da sua infraestrutura. Se o modelo precisa saber que existe um banco, ele precisa do schema, não da senha.
Um secret scanner no pipeline ajuda a pegar esse vazamento antes do deploy. A ferramenta compara o conteúdo do repositório com padrões de credencial conhecidos. O OWASP Cheat Sheet Series reúne checklists práticos para esse tipo de controle.
Ferramentas que já revisam código por você
Ferramentas de codificação agêntica já oferecem revisão de segurança sob demanda. O Claude Code, da Anthropic, roda no terminal e permite pedir análise de um escopo específico, como tratamento de input ou rotas de autenticação.
Escopar o pedido muda a qualidade do resultado. "Analise meu código" produz ruído. "Analise se este endpoint sanitiza o parâmetro de busca e se a autorização verifica o dono do recurso" produz achados que você consegue triar em minutos.
Outro uso possível é conferir regra de negócio contra implementação. Você pede ao modelo para descrever em linguagem natural o que o código faz e compara com a regra documentada. Bugs de data e fuso aparecem nesse tipo de leitura.
Comparação: ferramenta ampla versus ferramenta estreita
A diferença entre uma ferramenta ampla e uma estreita não está no modelo, e sim no alcance que você concede a ele. A tabela abaixo resume o que muda na prática.
Manter o modelo longe de comandos irreversíveis é a decisão que sobrevive a mudanças de versão e de prompt.
Revisão de segurança continua valendo
As práticas antigas de revisão não perderam valor com IA. Análise estática, scanner de dependências e leitura de código por outra pessoa seguem pegando classes de falha que o modelo ignora ou alucina.
Dependência desatualizada merece prioridade. Um modelo treinado em determinado período sugere a versão que era válida naquele momento, e vulnerabilidades descobertas depois ficam fora do corte de treino. Rodar um scanner de dependências no pipeline fecha essa lacuna.
Testes automatizados, incluindo testes dinâmicos contra a aplicação em execução, cobrem o que a leitura não pega. A combinação de estático, dependências e dinâmico continua sendo a base, com a IA somando hipóteses em cima.
Perguntas frequentes sobre IA e segurança de software
- O que é prompt injection? É a inserção de instruções maliciosas no texto que o sistema envia ao modelo, geralmente por um campo controlado pelo usuário. Quando o sistema concatena dados do usuário com instruções internas sem separação, o modelo pode obedecer ao texto injetado. A defesa combina separação de papéis, validação e limitação do que o modelo pode executar.
- Por que não posso deixar a IA executar SQL direto? Porque uma alucinação ou um prompt injection transforma a resposta em escrita ou leitura indevida no banco. O modelo não sabe o que o usuário pode acessar; quem sabe é a sua aplicação. Passe a resposta por um query builder com parâmetros e confira a permissão na sua camada autenticada.
- Guardrails com outro modelo resolvem o problema? Ajudam, mas não substituem controle determinístico. Classificadores de intenção erram, e o atacante ajusta a formulação até passar. Use a classificação como camada adicional e mantenha barreiras no código que não dependem da qualidade do modelo.
- O modelo precisa das minhas variáveis de ambiente? Não. Ele pode precisar do schema do banco ou do formato dos dados, nunca da senha ou da chave de API. Segredo em prompt é vazamento, e vazamento de credencial não se desfaz com rotação rápida.
- Como usar IA para achar vulnerabilidades no meu código? Escope o pedido. Peça análise do tratamento de input de um endpoint, da autorização de um recurso ou da regra de negócio de um fluxo. Depois trie os achados manualmente, porque a assimetria favorece gerar hipóteses e descartar as falsas.
- Análise estática ainda é necessária? Sim. Análise estática, scanner de dependências e testes dinâmicos pegam classes de falha que o modelo ignora. A IA soma hipóteses em cima dessas ferramentas, não as substitui.
- Dependência desatualizada é risco real? Sim, e é um dos mais baratos de explorar. Modelos sugerem versões que eram válidas no período de treino, e vulnerabilidades descobertas depois ficam fora desse corte. Um scanner de dependências no pipeline resolve a maior parte disso.
- Como validar o que volta do modelo? Trate a resposta como entrada de usuário. Confira formato com um schema, limite valores aceitos, busque identificadores na sua própria sessão e registre o que for rejeitado. A resposta do modelo nunca deve ir direto para escrita no banco ou chamada externa.
- IA substitui revisão humana de segurança? Não. Ela amplia o volume de hipóteses que você consegue levantar, e isso tem valor real. A decisão sobre o que é vulnerabilidade explorável e o que é falso positivo continua com quem conhece o sistema.
Por onde começar nesta semana
Comece inventariando as ferramentas que o seu modelo pode chamar. Liste cada uma e pergunte se ela permite ação irreversível. As que permitem viram prioridade de restrição, seja por escopo menor, seja por revisão humana obrigatória.
Depois verifique se algum segredo entra em prompt ou em contexto recuperado. Esse é o achado mais grave e o mais rápido de corrigir, porque basta remover o dado do fluxo.
Por último, escolha um endpoint e peça a um modelo uma análise escopada. Compare o que ele aponta com o que o seu scanner estático já reporta. A diferença entre os dois conjuntos mostra onde a IA agrega e onde ela só repete o que você já sabia.
Do transcrito ao artigo: transforme conhecimento em texto
A ideia central deste artigo é que hipóteses precisam ser levantadas em volume e depois triadas com critério. Vale para vulnerabilidade em código e vale para conhecimento que já existe gravado em vídeo, esperando virar texto.
Se você tem aulas, entrevistas ou opiniões registradas em vídeo no YouTube, o Skala Blog transforma esse material em artigo. Você cola a URL, o vídeo é transcrito e a partir daí nasce um texto estruturado, pronto para revisão antes de publicar.
É o mesmo princípio de escopar antes de executar: você parte de um material que já tem valor e dá a ele um formato que circula melhor.