Segredos e chaves: o erro de segurança mais comum de quem constrói com IA

Um protótipo que nasceu num fim de semana com Lovable, Cursor, n8n ou Claude costuma carregar um problema que ninguém percebe até ser tarde demais: a chave da API da OpenAI, a credencial do banco de dados ou o token do provedor de pagamento gravados direto no código, sem nenhuma proteção. Na demonstração isso não aparece. O problema surge quando esse código sai do computador de quem construiu e vai para um repositório compartilhado, para um deploy público ou fica preso no histórico de commits que ninguém nunca chega a limpar.

O erro que aparece em quase todo protótipo construído com IA

Existem duas variações do mesmo erro, e as duas são comuns. A primeira é a chave escrita direto no arquivo de código, colada ali pelo próprio assistente de IA no momento em que gerou a integração, sem passar por variável de ambiente nenhuma. A segunda, mais traiçoeira, é a chave que até está numa variável de ambiente, mas de um jeito que acaba embutida no pacote JavaScript que o navegador baixa: qualquer pessoa que abrir o código-fonte da página no navegador encontra a credencial ali, pronta para copiar.

Chave no código

Esse é o caso mais direto: a credencial aparece como texto puro no arquivo, some do editor quando o desenvolvimento termina, mas continua existindo para sempre no histórico do Git. Apagar a linha num commit novo não apaga a chave do commit anterior. Quem tiver acesso ao repositório, ou quem encontrar um repositório que deveria ser privado e não é, encontra a chave inteira revisando o histórico.

Chave no bundle do frontend

Esse caso é mais sutil porque parece resolvido: a chave está numa variável de ambiente, separada do código-fonte, exatamente como se recomenda. O problema é quando essa variável é do tipo que o processo de build injeta direto no pacote que roda no navegador do visitante. Uma credencial sensível, que deveria existir só no servidor, passa a existir em texto legível em qualquer computador que carregar a página, sem exigir nenhuma invasão.

Por que isso acontece com tanta frequência quando quem constrói é a própria IA

Ferramentas de vibe coding são otimizadas para um resultado visível rápido, não para uma arquitetura correta desde o início. Quando alguém pede para o assistente conectar a aplicação a uma API, o caminho mais curto para algo funcionar na tela é colar a chave onde ela é usada. Isso funciona, a demonstração roda, e o problema fica invisível justamente porque não trava nada: o código compila, a tela carrega, o cliente do lançamento não percebe nada de errado. O erro só aparece quando alguém de fora consegue ver o que está por trás da tela, e a essa altura o protótipo já pode estar em produção com cliente real dentro.

Existe ainda um segundo fator: quem está construindo sozinho, sem um segundo par de olhos revisando o que a IA escreveu, não tem o hábito de perguntar "essa chave deveria estar acessível pelo navegador, ou só pelo servidor". É uma pergunta de arquitetura, não de funcionalidade, e ferramentas de vibe coding raramente fazem essa pergunta sozinhas.

O que esse erro custa na prática

Um cenário típico, hipotético, ajuda a entender o tamanho do risco: uma chave de API de um provedor de IA fica exposta num repositório público por engano. Ferramentas automatizadas varrem o GitHub o tempo todo procurando exatamente esse padrão de credencial. Em poucas horas, a chave já está sendo usada por terceiros, gerando cobrança em nome de quem a criou, muitas vezes bem além do que o projeto consumiria num mês inteiro de uso legítimo. Esse é o custo mais visível, mas não o único.

Quando a chave exposta dá acesso a um banco de dados ou a uma API que devolve dado de cliente, o risco deixa de ser só financeiro e passa a ser de LGPD: dado pessoal exposto por falha de arquitetura é incidente de segurança, com obrigação de tratamento e, dependendo do caso, de comunicação. E há um terceiro custo, mais silencioso: a credencial exposta costuma ser reaproveitada em outras integrações do mesmo projeto, então corrigir de verdade nunca é trocar uma chave só, é mapear tudo que aquela credencial tinha permissão para tocar.

Como corrigir quando a chave já está exposta

• Revogar a chave exposta e gerar uma nova antes de qualquer outra coisa, mesmo que ainda não exista prova de uso indevido.
• Verificar o painel de uso do provedor da API por atividade fora do padrão nos dias anteriores à correção.
• Remover a credencial do histórico do Git, não só do arquivo atual: apagar a linha num commit novo não apaga o commit anterior.
• Mapear tudo que aquela chave tinha permissão de acessar, porque a mesma credencial costuma estar reaproveitada em mais de uma integração.
• Nunca reaproveitar a chave antiga em nenhum ambiente, nem mesmo no de teste.

Como evitar que isso aconteça de novo

A correção pontual resolve o incidente, mas não impede o próximo. O que evita a repetição é separar, desde o início do projeto, o que pode existir no navegador do visitante do que só pode existir no servidor. Chave que autentica uma chamada sensível, banco de dados, provedor de IA, gateway de pagamento, nunca deveria estar acessível pelo lado do cliente: a chamada precisa passar por um backend que guarda a credencial e expõe só o resultado. Isso significa, na prática, que nem toda funcionalidade que roda rápido num protótipo pode ir direto para produção do mesmo jeito: algumas chamadas precisam ser reescritas para passar por um servidor antes de chegar ao ar.

A segunda parte da prevenção é mecânica, não é pedir para o time tomar cuidado. É a diferença entre confiar que ninguém vai errar e ter uma ferramenta que barra o erro antes dele sair do computador de quem escreveu: varredura automática de segredo antes de cada commit, revisão de segurança antes de qualquer deploy em produção, ambiente de desenvolvimento separado do de produção com credenciais diferentes em cada um. É exatamente esse o papel do que chamamos de harness na Atlaas: regras e proteções que o projeto carrega, não um lembrete que depende de alguém não esquecer.

Se a sua empresa já construiu um protótipo com IA e vai colocar cliente de verdade dentro dele, vale revisar isso antes do lançamento, não depois de um incidente. Nosso diagnóstico gratuito do projeto de IA em /construa-com-ia dura 45 minutos com um engenheiro e serve exatamente para isso: mapear os riscos de segurança do que já foi construído, segredos expostos incluídos, sem compromisso de contratar nada.