Segundo testes da Aikido Security, algumas chaves de API do Google continuaram aceitando requisições mesmo depois de apagadas. Em certos casos, a janela chegou a quase 23 minutos, tempo suficiente para um invasor abusar de uma credencial vazada.
E olha, para quem trabalha com cloud, Gemini, BigQuery, Maps ou qualquer serviço ligado a chaves de API, esse detalhe muda bastante a forma de responder a um incidente.
Chaves do Google Cloud podem seguir ativas por minutos
A falha não significa, necessariamente, que a chave “volta” depois de excluída. O problema está na propagação da revogação pela infraestrutura do Google.
Na prática, alguns servidores entendem rapidamente que aquela chave foi apagada. Outros demoram mais para receber essa informação e continuam aceitando chamadas por alguns minutos. Foi essa diferença que os pesquisadores chamaram de “janela de revogação”.
É como trocar a fechadura da porta principal, mas descobrir que algumas entradas laterais ainda reconhecem a chave antiga por um tempinho. Parece pouco, mas em segurança digital poucos minutos podem virar um problemão.
O risco aumenta quando a chave vazada dá acesso ao Gemini
A situação preocupa mais quando a chave exposta está ligada a APIs sensíveis ou caras, como serviços de inteligência artificial.
A própria documentação do Google recomenda restringir chaves de API para limitar o impacto caso uma credencial seja comprometida. Também orienta evitar chaves em código fonte ou repositórios, já que isso facilita roubo e abuso.
O perigo é simples de entender: se alguém encontra uma chave vazada e ela ainda funciona depois da exclusão, esse invasor pode tentar fazer o máximo de chamadas possível antes que todos os servidores parem de aceitá-la.
Nesse intervalo, podem acontecer coisas como:
uso indevido de APIs pagas, gerando cobranças inesperadas;
acesso a serviços habilitados no projeto;
exploração de dados ou contexto disponível em ferramentas de IA;
aumento repentino de tráfego difícil de conter.
O Google também afirma que chaves padrão podem ser usadas com qualquer API que as aceite, salvo quando restrições específicas são aplicadas. Ou seja, deixar uma chave sem limite nunca é uma boa ideia.
O painel pode dar uma sensação errada de segurança
Um ponto que chamou atenção no relatório foi a mensagem exibida ao apagar uma chave. Para o usuário comum, a ideia transmitida é bem direta: excluiu, parou de funcionar.
Mas os testes mostraram outro cenário. A Aikido disse ter realizado dez tentativas ao longo de dois dias, criando e apagando chaves enquanto seguia enviando requisições autenticadas. O resultado variou bastante: em alguns testes, a chave falhou logo; em outros, continuou funcionando por vários minutos.
Esse tipo de comportamento é especialmente delicado em uma emergência. Quem está lidando com uma credencial vazada precisa saber se o acesso foi realmente encerrado ou se ainda existe uma brecha temporária.
Segundo a Aikido, o Google reabriu o relatório em 22 de maio de 2026 e passou a tratar o caso como um bug P0, depois de inicialmente considerar o comportamento esperado.
O que fazer se uma chave de API for exposta
Até que exista uma mudança definitiva, o caminho mais seguro é tratar a exclusão como parte de um processo, não como uma solução instantânea.
A recomendação prática dos pesquisadores é considerar uma janela de até 30 minutos após apagar a chave. Nesse período, o ideal é acompanhar o uso das APIs, procurar chamadas estranhas e bloquear serviços que possam gerar prejuízo.
Também vale reforçar medidas básicas, mas que muita gente só lembra depois do susto:
use restrições de API e de aplicação sempre que possível;
nunca deixe chaves irrestritas em produção;
monitore cobranças e picos de uso;
rotacione credenciais com frequência;
evite colocar chaves em apps, front end ou repositórios.
A página oficial do Google sobre boas práticas recomenda adicionar restrições, apagar chaves desnecessárias e não incluir credenciais diretamente em código cliente ou repositórios.
No fim das contas, apagar a chave continua sendo necessário. Só não dá para assumir que isso fecha a porta no mesmo segundo.
A descoberta serve como um alerta bem direto: em ambientes de nuvem, “excluir” nem sempre significa “revogar imediatamente”.
Para empresas, desenvolvedores e equipes de segurança, a melhor resposta é combinar exclusão, monitoramento e restrições. Assim, mesmo que uma chave escape, o estrago fica menor e a reação deixa de depender apenas de um botão.
E, sinceramente, essa é uma daquelas situações em que prevenir sai muito mais barato do que tentar explicar uma cobrança absurda depois.