Como criar ferramentas web com IA sem comprometer a segurança

Criar uma ferramenta web com inteligência artificial ficou simples: um formulário, uma chamada à API de um modelo de linguagem e a resposta na tela. Um resumidor de textos, um gerador de descrições de produto, um assistente que responde perguntas sobre um documento.

O problema é que essa simplicidade esconde riscos. Alguns são velhos conhecidos da web, como vazamento de credenciais e cross-site scripting. Outros são novos, como a injeção de prompt. Este tutorial organiza as defesas em sete passos, com base no OWASP Top 10 para aplicações com LLMs, a lista de riscos mantida pelo projeto de segurança de IA generativa da OWASP, fundação sem fins lucrativos dedicada à segurança de software.

Os trechos de código são ilustrativos. Adapte-os à linguagem e ao provedor que você usa e confira a documentação oficial deles.

Passo 1: a chave da API nunca vai para o navegador

Toda API de modelo de linguagem é acessada com uma chave de API, uma senha que identifica a sua conta e gera cobrança a cada uso. Quem tiver essa chave usa o modelo por sua conta.

O erro mais comum em protótipos é colocar a chave no JavaScript da página. Qualquer visitante abre as ferramentas de desenvolvedor do navegador e a copia. A documentação do Google sobre chaves da API Gemini é explícita: não coloque a chave diretamente em aplicativos web ou móveis e nunca a envie para sistemas de controle de versão, como o Git. Para aplicações no navegador, a recomendação é ter um servidor intermediário que faça as chamadas à API.

A arquitetura mínima fica assim:

1. O navegador envia o texto do usuário para o seu backend.
2. O backend confere quem é o usuário, aplica limites e só então chama a API do modelo, com a chave guardada em variável de ambiente.
3. O backend devolve ao navegador apenas o que ele precisa exibir.

Se a chave vazar mesmo assim, troque-a imediatamente. Quando o provedor permitir, restrinja a chave a determinadas APIs ou origens, o que o mesmo guia do Google aponta como forma de reduzir o estrago. Como guardar segredos em um processo de publicação está detalhado em como configurar deploy automático com segurança.

Passo 2: o prompt de sistema não é cofre

O prompt de sistema é a instrução fixa que você envia ao modelo antes da mensagem do usuário: “você é um assistente que resume contratos; responda em português”. É tentador colocar ali regras de segurança e até credenciais.

A OWASP desaconselha as duas coisas. A página sobre vazamento do prompt de sistema diz que ele não deve ser considerado segredo nem usado como controle de segurança. Chaves, senhas e endereços de banco de dados ficam fora do prompt. Controles críticos, como separação de privilégios e verificação de autorização, não devem ser delegados ao modelo.

Na prática: suponha que qualquer usuário insistente vai conseguir ler o seu prompt de sistema. Escreva-o de modo que isso não cause dano.

Passo 3: trate a saída do modelo como entrada não confiável

Este é o ponto que mais surpreende quem vem do desenvolvimento web comum. A resposta do modelo pode ser influenciada pelo usuário. Logo, ela merece a mesma desconfiança que um campo de formulário.

A OWASP chama esse risco de tratamento inadequado da saída. Um dos cenários descritos: um prompt manipulado faz o modelo devolver JavaScript, que roda no navegador de outro usuário quando a resposta é exibida. Isso é XSS (cross-site scripting), a injeção de código em uma página vista por terceiros. A mesma página lista outros perigos: passar a saída sem verificação para um comando do sistema, para eval, para uma consulta SQL ou para a montagem de caminhos de arquivo.

As defesas são as da web clássica, aplicadas a um novo remetente:

• Exiba texto como texto. A folha de referência da OWASP sobre XSS recomenda trocar innerHTML por textContent, que insere o conteúdo sem interpretá-lo como HTML.
• Se precisar de formatação, sanitize. Quando a resposta vem em Markdown e você a converte em HTML, passe o resultado por um sanitizador antes de inseri-lo na página. A OWASP recomenda o DOMPurify e alerta que alterar o HTML depois de sanitizado pode anular a proteção.
• Nunca monte SQL com a resposta. Use consultas parametrizadas, como em qualquer entrada externa.
• Valide o formato. Se você pediu um JSON com três campos, confira com código que veio exatamente isso antes de usar.

// Ilustrativo: exibir a resposta como texto puro
saida.textContent = respostaDoModelo;

// Se a resposta for HTML (por exemplo, Markdown convertido), sanitize antes
saida.innerHTML = DOMPurify.sanitize(htmlConvertido);

Como camada extra, configure uma política de segurança de conteúdo, a CSP (Content Security Policy). Segundo a documentação da MDN, ela é um conjunto de instruções que o site envia ao navegador para limitar o que o código da página pode fazer, com o objetivo principal de mitigar XSS. A própria MDN lembra que a CSP é defesa em profundidade: complementa a sanitização, não a substitui.

Passo 4: limite o uso antes que a conta chegue

Cada chamada ao modelo custa dinheiro. Uma ferramenta aberta, sem limites, pode ser usada por robôs até esgotar o orçamento. A OWASP descreve esse cenário em consumo sem limites, que inclui a chamada denial of wallet: um volume alto de requisições feito para explorar a cobrança por uso e gerar custos insustentáveis.

As medidas recomendadas pela OWASP são de engenharia comum:

• Tamanho máximo de entrada. Recuse textos acima de um limite razoável para a sua ferramenta.
• Limite de requisições por usuário, por endereço IP ou por sessão, em uma janela de tempo.
• Cotas por usuário e tempo máximo de execução por chamada.
• Monitoramento do consumo, com alerta para padrões fora do normal.

Some a isso um teto de gastos no painel do provedor, quando ele oferecer. Para entender por que textos longos custam mais, veja como funcionam os tokens nos modelos de IA.

Passo 5: reduza o estrago da injeção de prompt

Injeção de prompt é quando um texto consegue mudar o comportamento do modelo de forma não prevista. A OWASP distingue dois tipos na página sobre injeção de prompt: a direta, escrita pelo próprio usuário, e a indireta, que chega escondida em conteúdo externo processado pelo modelo, como uma página web ou um arquivo enviado.

A mesma página reconhece que não está claro se existem métodos infalíveis de prevenção, por causa da natureza probabilística dos modelos generativos. Ou seja: você não elimina o risco, você limita o que um ataque bem-sucedido consegue fazer.

As medidas listadas pela OWASP incluem:

• definir no prompt de sistema o papel e os limites da tarefa;
• exigir formatos de saída e validá-los com código;
• separar e marcar claramente o conteúdo externo não confiável;
• dar à aplicação o mínimo de privilégio e executar funções sensíveis em código, não pelo modelo;
• exigir aprovação humana para operações de alto risco;
• fazer testes adversariais regulares, tratando o modelo como um usuário não confiável.

Se a sua ferramenta lê documentos enviados pelo público, a injeção indireta é o cenário principal. O texto como construir um chatbot com seus próprios documentos trata desse caso.

Passo 6: dê ao modelo só as ferramentas de que ele precisa

Muitas ferramentas evoluem de “responde perguntas” para “executa ações”: enviar e-mail, consultar o banco de dados, buscar uma URL. É aí que a injeção de prompt deixa de ser constrangimento e vira incidente.

A OWASP chama o problema de agência excessiva e aponta três causas: funções demais, permissões demais e autonomia demais. As recomendações:

• ofereça só as funções necessárias e evite as genéricas, como executar comandos no sistema ou buscar qualquer URL;
• use permissões mínimas: usuário de banco somente leitura, escopos restritos, ações feitas no contexto do usuário que pediu;
• peça confirmação humana para ações de alto impacto;
• faça a verificação de autorização no sistema que executa a ação, e não perguntando ao modelo se a ação é permitida.

O tema é aprofundado em o que são agentes de IA e como executam tarefas.

Passo 7: cuide dos dados e do código gerado por IA

Duas frentes costumam ficar para depois e não deveriam.

Dados pessoais. Tudo o que o usuário digita é enviado ao provedor do modelo. A página da OWASP sobre divulgação de informações sensíveis recomenda filtrar dados sensíveis antes que cheguem ao modelo, aplicar controle de acesso, orientar o usuário a não enviar informações sensíveis e publicar regras claras de retenção e uso. Ela também alerta que restrições escritas no prompt podem ser contornadas por injeção, então não podem ser o único controle. Para as obrigações no Brasil, veja privacidade de dados ao usar ferramentas de IA. Cuidado também com os registros (logs): guardar prompts completos é útil para depurar, mas cria uma cópia dos dados dos usuários.

Código escrito com assistentes de IA. Se você usa IA para programar a ferramenta, revise as dependências que ela sugere. Um estudo apresentado no USENIX Security 2025, We Have a Package for You!, testou 16 modelos geradores de código e encontrou taxa média de pacotes inexistentes de pelo menos 5,2% nos modelos comerciais e 21,7% nos de código aberto, com 205.474 nomes únicos inventados. O risco é alguém registrar um pacote com esse nome e código malicioso. Antes de instalar, confirme que o pacote existe, quem o mantém e se é o que você procurava. O texto IA na programação discute os limites desses assistentes.

O que levar deste texto

• Chave de API só no servidor. O navegador fala com o seu backend, que autentica, limita e registra.
• O prompt de sistema não guarda segredos nem faz controle de acesso.
• A resposta do modelo é entrada não confiável: texto como texto, HTML sanitizado, SQL parametrizado, formato validado.
• Limite tamanho, frequência e custo antes de abrir a ferramenta ao público.
• Injeção de prompt não tem cura definitiva; permissões mínimas e aprovação humana reduzem o estrago.
• Proteja os dados dos usuários e confira cada dependência sugerida por IA.