Segredos hardcoded em código gerado por IA: o problema de throughput

O relatório State of Secrets Sprawl 2026 da GitGuardian documentou 29 milhões de novos segredos hardcoded em commits públicos do GitHub ao longo de 2025, alta de 34% em relação a 2024 e o maior salto em um único ano já registrado. Esse pico coincide quase exatamente com o período em que GitHub Copilot e Cursor atingiram adoção em massa. A resposta padrão a esses dados é um checklist: use variáveis de ambiente, rode um scanner, adicione um pre-commit hook. Esse enquadramento erra o modo de falha real. O problema central é a velocidade com que a IA escreve e o que essa velocidade faz com as ferramentas de detecção que o time já tinha.

Commits gerados por IA têm taxa de vazamento mais que dobrada

Os números brutos da GitGuardian merecem atenção. Em todos os commits públicos de 2025, a taxa de vazamento de segredos foi de 1,5%. Em commits gerados ou assistidos por IA, essa taxa foi de 3,2%, mais que o dobro. O 2025 GenAI Code Security Report da Veracode adiciona um dado compatível: código gerado por IA continha 2,74 vezes mais vulnerabilidades que código escrito por humanos, em uma amostra de 80 tarefas de programação, quatro linguagens e quatro categorias de vulnerabilidade. Apenas 55% do código gerado por IA nessa análise estava seguro na entrega.

O mecanismo não é misterioso. Ferramentas de código com IA são treinadas para produzir código funcional que satisfaz um prompt imediato. Quando um desenvolvedor pede uma integração com uma API externa, o modelo produz algo que roda, o que frequentemente significa preencher credenciais inline para o exemplo funcionar. O modelo não é malicioso, ele está otimizando para o sinal errado. Passar num teste não é o mesmo que estar pronto para produção, e nada no loop de geração penaliza um API_KEY = "sk-..." hardcoded se o código resultante executa corretamente.

A Veracode também observou que 97% dos desenvolvedores já usaram ferramentas de IA, citando a pesquisa de desenvolvedores do GitHub de 2024. Com essa taxa de adoção, o índice de 3,2% em commits assistidos por IA não é uma preocupação de nicho. Está se tornando o novo baseline.

O descompasso de throughput é o que quebra seu pipeline de detecção

Aqui é onde a cobertura padrão erra: trata segredos hardcoded como um problema de qualidade de código com uma solução em forma de scanner. O problema mais difícil é arquitetural. Pre-commit hooks, cadência de revisão de PR e triagem de alertas de scanner foram todos desenhados em torno da velocidade humana de codificação. Um desenvolvedor experiente abre talvez três ou quatro PRs por semana. Um desenvolvedor trabalhando com um agente de IA pode gerar esse número em uma tarde, e a superfície de código em cada PR é maior porque o agente preenche boilerplate que um humano escreveria de forma incremental.

O resultado é um descompasso de throughput. Seu scanner de segredos ainda dispara na mesma taxa, mas agora está varrendo dez vezes mais superfície de código na mesma janela de tempo. O humano que faz a triagem desses alertas não ficou mais rápido. As filas de alerta crescem. Segredos validados, ou seja, credenciais que o scanner confirma como ativas e exploráveis, ficam sem rotação no histórico de commits enquanto a fila de triagem cresce.

Os dados da GitGuardian tornam a consequência concreta: quase 70% das credenciais confirmadas como válidas em 2022 ainda eram válidas em janeiro de 2025. Quando retestadas em janeiro de 2026, a taxa de validade permanecia acima de 64%. A detecção não foi a falha, esses segredos foram encontrados. A falha está no pipeline de remediação, que nunca foi desenhado para processar segredos na velocidade de commits assistidos por IA. Como a GitGuardian colocou diretamente no relatório: "A diferença entre sucesso e fracasso não é encontrar mais segredos, é saber quais consertar primeiro."

Esse é um problema de priorização e workflow, não de configuração de scanner. Adicionar mais regras ao seu pre-commit hook não ajuda se o gargalo é o humano lendo o output.

Três padrões de falha que a cobertura típica ignora

A maioria dos artigos sobre o tema descreve código gerado por IA como a principal superfície de ameaça. Na prática, as falhas que persistem por mais tempo tendem a se agrupar em três padrões que não aparecem de forma limpa em um scan de repositório.

Segredos que se espalham lateralmente após o commit inicial. A GitGuardian encontrou que, em média, cada segredo ativo aparecia em oito locais diferentes na mesma máquina comprometida: arquivos .env, histórico de shell, configurações de IDE, tokens em cache e artefatos de build. Rotacionar a credencial no repositório não limpa os outros sete locais. Quando um desenvolvedor usa um agente de IA para montar um projeto localmente, esses arquivos intermediários frequentemente persistem sem nunca chegar a um repositório.

Runners de CI/CD como principal superfície de exposição. Das máquinas comprometidas analisadas pela GitGuardian, 59% eram runners de CI/CD, não laptops de desenvolvedores. O desenvolvimento assistido por IA acelera o caminho do scaffold local para a execução em pipeline, o que significa que segredos incorporados durante prototipagem rápida chegam aos runners de CI mais rapidamente do que antes. Runners frequentemente têm permissões amplas, e seus logs às vezes ficam armazenados em ferramentas de colaboração com acesso interno amplo.

Arquivos de configuração de servidores MCP como um novo ponto cego. A GitGuardian identificou 24.008 segredos únicos expostos em arquivos de configuração relacionados a MCP em repositórios públicos do GitHub, incluindo 2.117 credenciais confirmadas como válidas. Servidores MCP ficam na fronteira entre agentes de IA e serviços externos. Arquivos de configuração para eles frequentemente são commitados junto com o código do projeto por desenvolvedores que os tratam como ferramentas locais e não como artefatos de produção. Essa é uma categoria que não existia em escala há dois anos, e os conjuntos de regras dos scanners atuais estão apenas começando a cobri-la. Se quiser entender melhor como o MCP funciona tecnicamente, a documentação da Anthropic tem a especificação completa.

A análise da CSA de maio de 2026 sobre aplicações de produção construídas com vibe coding adiciona um achado compatível: a Escape.tech escaneou mais de 1.400 aplicações de produção e encontrou que 58% continham pelo menos uma vulnerabilidade crítica, com mais de 400 segredos expostos. O problema de segredos não viaja sozinho.

Serviços de IA são a categoria de vazamento que mais cresce

Os dados da GitGuardian sobre o tipo específico de segredos vazando merecem destaque separado porque mudam quais credenciais você deve priorizar.

Em 2025, a GitGuardian detectou mais de 1,2 milhão de segredos vazados vinculados a serviços de IA, alta de 81% em relação a 2024. Oito das dez categorias de segredos com crescimento mais rápido ano a ano são credenciais de serviços de IA. Isso cria um risco composto específico: desenvolvedores que usam ferramentas de IA para escrever código também são os mais propensos a possuir chaves de API de serviços de IA, e essas chaves são cada vez mais o que acaba hardcoded no output. A ferramenta que gera o código e as credenciais que vazam nesse código frequentemente vêm do mesmo ecossistema de fornecedor.

Uma chave de API da OpenAI ou da Anthropic sem limite de taxa ou teto de gasto é materialmente diferente de uma senha de banco de dados interno vazada. Ela pode ser usada para rodar inferência à custa do dono da credencial, ou para sondar conteúdo do system prompt se a chave estiver associada a um assistente em produção. O raio de dano é mais amplo do que um vazamento de credencial tradicional. Se você está construindo com Claude e não tem controles de gasto configurados, vale revisar isso antes de qualquer outra coisa na sua política de segredos.

O ajuste não é um scanner, é um gate de workflow com consequências reais

Isso não significa que scanners são inúteis. Tratá-los como solução completa é o enquadramento errado. O que precisa mudar é o gate de revisão entre código gerado por IA e a branch principal.

Algumas abordagens que endereçam o problema de throughput, não apenas o de detecção:

• Bloqueio automático, não apenas alerta. Pre-commit hooks que avisam são fáceis de contornar sob pressão de tempo. Hooks que impedem o commit até o segredo ser removido funcionam como um gate rígido independente de quantos commits por dia estão sendo gerados.
• Filas de triagem separadas para PRs assistidos por IA. Se sua ferramenta consegue identificar PRs que contêm código gerado por IA em volume, sua equipe de segurança pode aplicar um protocolo de revisão diferente a eles sem revisar todos os PRs com a mesma profundidade.
• Vida útil curta para segredos por padrão. Se um segredo é válido indefinidamente até ser rotacionado manualmente, a janela de exposição cresce com a velocidade de commits. Segredos que expiram em 24 ou 72 horas limitam o dano da fila de remediação, independente de quanto tempo o alerta fique na fila.
• Restrições de escopo em tokens de CI. Se runners de CI/CD são 59% das máquinas comprometidas, limitar o que esses tokens podem realmente fazer é um controle de maior alavancagem do que revisar cada log de build.

Nenhuma dessas abordagens elimina a tendência subjacente do código gerado por IA de incorporar credenciais. Elas endereçam o descompasso de throughput que permite que essas credenciais sobrevivam.

Na prática

No meu trabalho, o ponto de atenção mais imediato com IA foi exatamente esse: quando começo a usar um agente para montar integrações, os arquivos de configuração intermediários se multiplicam rápido. Arquivos .env de teste, tokens copiados para verificar se a conexão funciona, configurações de ferramentas que ficam na pasta do projeto. Nenhum desses vai para o repositório deliberadamente, mas a chance de um deles escapar por distração é real, especialmente quando o ritmo de geração de código acelera.

O que ajudou foi tratar as configurações de ferramentas de IA com o mesmo critério de qualquer artefato de produção, não como arquivos de tooling pessoal. Se tem uma credencial, ela precisa de ciclo de vida definido. Não basta não commitar: precisa saber onde está, por quanto tempo vale e o que acontece se vazar.

Isso vale especialmente para quem está começando a usar servidores MCP em automações, porque esses arquivos de configuração têm uma aparência de "coisa local" que convida ao descuido.

FAQ

O GitHub Copilot realmente sugere credenciais inline, ou isso é exagerado?

Copilot e ferramentas similares podem e sugerem credenciais inline, especialmente ao gerar código de exemplo para integrações com APIs externas ou quando o contexto ao redor inclui padrões similares, como um arquivo .env.example existente. O achado da GitGuardian de que commits assistidos por IA têm taxa de vazamento de 3,2% contra 1,5% de baseline sugere que a tendência é real e mensurável em escala, embora o mecanismo exato por ferramenta não tenha sido replicado de forma independente em estudos controlados até onde acompanhei.

Escanear o histórico de commits retroativamente ajuda depois que um segredo vazou?

O scan retroativo encontra segredos, mas não os revoga. Um segredo no histórico do git, mesmo depois de removido do HEAD, permanece acessível para qualquer pessoa que clonou o repositório antes da remoção ou que tem acesso ao histórico. A remediação correta é sempre rotacionar a credencial imediatamente, depois limpar o histórico. Ferramentas como git filter-repo podem limpar o histórico, mas qualquer fork ou clone criado antes da limpeza retém os commits originais. Rotação é a única ação que efetivamente fecha a exposição.

O que é um servidor MCP e por que importa para gestão de segredos?

MCP (Model Context Protocol) é um padrão desenvolvido pela Anthropic para conectar agentes de IA a ferramentas e serviços externos. Arquivos de configuração de servidores MCP tipicamente incluem chaves de API e credenciais de serviço para as ferramentas que o agente está autorizado a usar. Como esses arquivos são frequentemente criados durante desenvolvimento local e tratados como configuração, não como código, desenvolvedores às vezes os commitam sem aplicar a mesma revisão que dariam a arquivos de código da aplicação. Se você está usando agentes com MCP, vale incluir esses arquivos explicitamente nas regras do seu scanner. Mais contexto sobre como o protocolo funciona está na documentação oficial da Anthropic.

Projetos de código fechado em repositórios privados têm risco menor?

O raio de dano é menor, mas a exposição não está totalmente contida. A GitGuardian encontrou que 28% dos incidentes têm origem em ferramentas de colaboração e produtividade, não em repositórios. Se um desenvolvedor cola um trecho com credencial em um canal do Slack ou em um documento compartilhado enquanto depura algo, o segredo saiu do ambiente controlado. Repositório privado reduz o blast radius, não elimina o vetor.

Nas equipes que estão absorvendo ferramentas de código com IA mais rápido, o aumento de 34% ano a ano em segredos hardcoded reflete uma infraestrutura de revisão e remediação construída para um mundo mais lento, agora operando em um ritmo que esses sistemas nunca foram desenhados para suportar. Os segredos estão sendo encontrados. A distância entre encontrá-los e corrigi-los está crescendo a cada sprint, e a velocidade de commits é o que continua alargando essa distância.