Segurança em aplicações que usam IA

Construir aplicações com modelos de linguagem trouxe uma classe nova de problemas de segurança. Os riscos tradicionais de aplicações web continuam valendo, mas a presença de um LLM adiciona vetores de ataque que muitos desenvolvedores nunca encontraram antes. Um modelo que interpreta linguagem natural e age com base nela é poderoso, mas também é manipulável de formas sutis.

Este texto percorre os principais riscos de segurança específicos de aplicações que usam IA e as defesas para cada um. Se você está colocando um LLM em produção, esses são os problemas que precisa conhecer antes que um atacante os descubra por você.

O problema fundamental: dados e instruções se misturam

A raiz de boa parte dos riscos de segurança em IA é uma característica dos LLMs: para o modelo, não há separação clara entre as instruções que você deu e os dados que ele está processando. Tudo chega como texto no mesmo contexto. Num sistema tradicional, código e dados vivem em camadas separadas; num LLM, uma instrução maliciosa escondida dentro de um dado pode ser obedecida como se fosse um comando legítimo.

Essa é uma diferença conceitual importante. Se você entende como um LLM funciona, prevendo a continuação mais provável de um texto sem distinguir a origem de cada parte, os ataques que veremos deixam de ser surpreendentes. Vale revisar o texto sobre o que é um LLM se esse mecanismo ainda não estiver claro, porque ele é a base para entender as vulnerabilidades.

Injeção de prompt

A injeção de prompt é o ataque mais característico de aplicações com IA. Consiste em inserir instruções maliciosas na entrada do modelo para desviar seu comportamento. Se sua aplicação monta um prompt combinando instruções fixas com texto fornecido pelo usuário, um atacante pode escrever esse texto de forma a sobrescrever suas instruções originais, algo como "ignore tudo que foi dito antes e faça o seguinte".

Existe uma variante ainda mais perigosa, a injeção indireta. Nela, a instrução maliciosa não vem diretamente do usuário, mas de um conteúdo que o modelo lê como parte da tarefa: uma página web que ele resume, um documento que ele processa, um email que ele analisa. O atacante planta a instrução nesse conteúdo, e o modelo a executa ao processá-lo, sem que o usuário legítimo perceba.

A defesa não é trivial, porque não existe uma solução perfeita ainda. As mitigações incluem separar claramente instruções de dados na estrutura do prompt, tratar toda saída do modelo como não confiável, limitar drasticamente o que o modelo pode fazer, e nunca dar a ele poder de executar ações sensíveis sem confirmação. A regra de ouro é assumir que a injeção pode acontecer e desenhar o sistema para que ela cause o mínimo de dano possível.

Vazamento de dados sensíveis

Aplicações com IA frequentemente lidam com dados sensíveis, e há vários caminhos pelos quais eles podem vazar. O primeiro é o modelo revelar, na resposta, informações que estavam no seu contexto mas não deveriam chegar àquele usuário. Se você coloca dados de vários usuários no mesmo contexto, ou instruções internas que deveriam ficar ocultas, um prompt bem construído pode extraí-los.

O segundo caminho é enviar dados sensíveis a um provedor de IA externo sem a devida cautela. Ao usar uma API de LLM de terceiros, você está mandando o conteúdo do prompt para fora da sua infraestrutura. Dados regulados, segredos ou informações pessoais podem acabar em servidores que você não controla, com implicações legais e de privacidade.

As defesas incluem nunca colocar no contexto do modelo mais dados do que a tarefa exige, isolar rigorosamente os dados de usuários diferentes, remover ou mascarar informação sensível antes de enviá-la ao modelo, e entender as políticas de retenção do provedor que você usa. O princípio do menor privilégio, dar ao modelo apenas o acesso estritamente necessário, vale aqui como em qualquer sistema seguro.

Segredos nunca no cliente

Um erro grave e comum é embutir a chave de API do provedor de IA no código do frontend, no aplicativo ou em variáveis expostas ao navegador. Qualquer chave que chega ao cliente pode ser extraída, e a partir daí um atacante usa seu crédito, acessa seus recursos e potencialmente sua conta no provedor. Esse risco não é exclusivo de IA, mas se torna especialmente caro por causa do custo por uso das APIs de modelo.

A defesa é absoluta e não admite exceção: chaves de API e segredos ficam apenas no servidor. As chamadas ao provedor de IA passam por um backend seu, que guarda a chave e faz a requisição em nome do cliente. O cliente fala com o seu servidor, e só o seu servidor fala com o provedor. Isso também te dá o ponto de controle para aplicar limites, validação e monitoramento, que veremos adiante. Esse mesmo princípio de segurança aparece no OWASP Top 10 explicado.

Alucinações com consequências

As alucinações, aquelas afirmações que o modelo produz com confiança mas que são falsas, deixam de ser apenas um problema de qualidade e viram um problema de segurança quando a saída do modelo alimenta uma ação. Se o modelo gera um comando que será executado, um trecho de código que será rodado, uma consulta que irá ao banco, ou uma decisão que afeta um usuário, uma alucinação pode causar dano real.

Um caso concreto e crescente é o de modelos que geram código sugerindo pacotes de software que não existem. Atacantes percebem quais nomes de pacotes o modelo inventa com frequência e publicam pacotes maliciosos com exatamente esses nomes, esperando que desenvolvedores confiantes os instalem. A alucinação vira porta de entrada para código malicioso.

A defesa é nunca tratar a saída do modelo como confiável por padrão. Toda saída que vai virar ação passa por validação. Código gerado é revisado antes de rodar. Pacotes sugeridos são conferidos antes de instalar. Quanto mais consequente a ação, mais rigorosa a verificação, idealmente com um humano no circuito para decisões críticas. Técnicas como RAG reduzem alucinações ao ancorar respostas em material real, mas não eliminam a necessidade de verificar.

Consumo excessivo e negação de serviço

APIs de LLM custam dinheiro por uso e têm limites de capacidade. Isso cria um vetor de ataque econômico: um adversário pode disparar requisições caras em massa, inflando sua conta ou esgotando sua cota até o serviço parar para os usuários legítimos. Prompts elaborados que forçam respostas longas amplificam o custo de cada chamada.

As defesas são as mesmas de qualquer serviço exposto, aplicadas à camada de IA. Imponha limites de taxa por usuário. Estabeleça tetos de tamanho para entradas e saídas. Monitore o consumo e configure alertas para picos anômalos. E autentique quem pode usar o recurso, evitando que a funcionalidade de IA fique aberta ao mundo sem controle. O backend que guarda sua chave é o lugar natural para aplicar tudo isso.

Excesso de autonomia

Uma tentação ao construir com IA é dar ao modelo a capacidade de agir, conectando-o a ferramentas que enviam emails, executam código, movem dinheiro ou modificam dados. Quanto mais autonomia o modelo tem, mais útil ele parece, mas também maior o estrago que uma injeção de prompt ou uma alucinação pode causar. Um modelo comprometido com poder de agir é muito mais perigoso do que um que apenas conversa.

A defesa é limitar deliberadamente a autonomia. Dê ao modelo o menor conjunto de capacidades que a tarefa exige. Exija confirmação humana para ações irreversíveis ou sensíveis. Coloque validações entre a decisão do modelo e sua execução. E projete cada ferramenta que o modelo pode usar assumindo que ele pode ser induzido a usá-la de forma maliciosa. Autonomia é conveniência que se paga em risco, e o equilíbrio precisa ser consciente.

Envenenamento de dados e do modelo

Um risco menos visível mora antes da aplicação existir: nos dados usados para treinar ou ajustar o modelo. O envenenamento de dados acontece quando um atacante consegue inserir exemplos maliciosos no conjunto de treinamento, fazendo o modelo aprender comportamentos indesejados ou portas dos fundos que podem ser ativadas depois. Para quem usa modelos de terceiros, o risco é indireto mas real, porque você herda o que quer que tenha entrado no treinamento daquele modelo.

Um cuidado relacionado surge quando você faz ajuste fino com seus próprios dados ou monta uma base de conhecimento para recuperação. Se você deixa qualquer conteúdo entrar nesses conjuntos sem controle, abre espaço para que material malicioso influencie as respostas. Isso se conecta diretamente com a injeção indireta que vimos antes: uma base de conhecimento contaminada é um vetor de ataque. Controlar a procedência e a integridade de tudo que alimenta o modelo, seja no treinamento, no ajuste ou na recuperação, é parte da defesa. Se você usa a técnica de RAG, trate a curadoria da base como uma responsabilidade de segurança, não apenas de qualidade.

Uma mentalidade para construir com IA

O fio que costura todas essas defesas é uma postura de desconfiança estruturada. Não confie na entrada que chega ao modelo, porque pode conter injeção. Não confie na saída que sai do modelo, porque pode conter alucinação ou instrução manipulada. Não exponha segredos ao cliente. Não dê ao modelo mais dados nem mais poder do que ele precisa. Monitore tudo. Essas são extensões naturais dos princípios de segurança que já valem para qualquer aplicação, adaptadas à natureza particular dos LLMs.

Vale também acompanhar o trabalho da comunidade nessa área. A OWASP mantém uma lista específica dos principais riscos de segurança em aplicações com LLM, que sistematiza esses e outros vetores e é uma referência valiosa para quem constrói nesse espaço.

Conclusão

Aplicações com IA herdam todos os riscos de segurança tradicionais e adicionam uma camada própria, nascida do fato de que um LLM não separa instruções de dados e produz saídas que podem ser falsas ou manipuladas. Injeção de prompt, vazamento de dados, segredos expostos, alucinações consequentes, consumo abusivo e excesso de autonomia são os principais pontos de atenção.

Nenhum desses riscos tem uma solução mágica, mas todos têm mitigações concretas baseadas em princípios sólidos: menor privilégio, desconfiança de entradas e saídas, segredos só no servidor, validação antes de agir e monitoramento constante. Construir com IA de forma responsável significa tratar o modelo como um componente poderoso porém não confiável, e desenhar o sistema ao redor dele para que, mesmo quando algo der errado, o dano seja contido.