# Vazou sua chave sk-proj da OpenAI? O que fazer nos próximos 10 minutos Equipe iatize · 2026-07-29 · 8 min de leitura > **Resumo.** Revogue a chave agora em platform.openai.com/api-keys — é instantâneo e é a única ação que interrompe o prejuízo. Depois, nessa ordem: crie uma chave nova com permissão mínima, cheque o painel de uso pra medir o estrago, defina limite de gasto no projeto e troque a chave nos lugares legítimos que a usavam. Por fim, descubra POR ONDE vazou — quase sempre é chave commitada no GitHub ou embutida no código do site — senão a próxima vaza igual. A cobrança do uso indevido cai na sua conta; dá pra contestar no suporte da OpenAI, sem garantia. URL: https://www.iatize.tech/blog/vazou-chave-sk-proj-openai Se você chegou aqui pelo susto — a chave apareceu num repositório público, num print, no código do seu site, ou a OpenAI te mandou um e-mail de alerta — respira: esse é provavelmente o incidente de segurança mais comum do mundo dos apps feitos com IA, e o dano quase sempre é financeiro e reversível. Mas ele cresce por hora. Então a ordem das ações importa mais que a calma do texto: faça o passo 1 agora e volte pra ler o resto. Aviso de honestidade: a iatize constrói apps com IA e mantém um scanner que procura exatamente esse tipo de furo — chave exposta, banco aberto — em apps publicados. Temos interesse no assunto. Justamente por isso este guia é completo de verdade: a maior parte dele você resolve sozinho, sem pagar nada a ninguém. ## Os primeiros 10 minutos, na ordem 1. Revogue a chave vazada: entre em platform.openai.com/api-keys, ache a chave (o começo sk-proj-... e os últimos caracteres ajudam a identificar) e delete. É instantâneo. Se o app que usava essa chave parar por alguns minutos, aceite o custo — é menor que o da chave aberta. 2. Crie a chave substituta com escopo mínimo: chave de projeto (não da conta toda), só com as permissões que o app usa. Se o projeto permite, restrinja os modelos e endpoints. 3. Meça o estrago: no painel de uso (platform.openai.com/usage), procure picos que você não reconhece — horários, volume, modelos que você não usa. Anote valores e datas; é sua evidência pra contestação. 4. Trave o gasto: defina limite de orçamento no projeto (budget/limite de uso). Assim, se outra chave vazar amanhã, o teto do prejuízo já está definido. 5. Troque a chave nos lugares legítimos: atualize a variável de ambiente no servidor/host onde o app roda de verdade. Se você não sabe onde ela fica, esse é um sinal importante — falamos dele mais abaixo. > **Não faça o contrário.** O erro clássico é criar a chave nova primeiro, trocar em todo lugar "pra não parar o app" e deixar pra revogar a antiga depois. Depois vira nunca. Enquanto a antiga vive, o prejuízo corre. Revogar vem primeiro, sempre. ## Quanto isso vai me custar? A regra dura: o uso feito com a sua chave é cobrado da sua conta, mesmo que não tenha sido você. Quem abusa de chave vazada costuma consumir rápido — revenda de acesso e bots drenam milhares de requisições em horas. Por isso a revogação imediata é a única ação que de fato estanca a conta. Depois de revogar, vale contestar: o suporte da OpenAI analisa caso a caso e já estornou usos claramente fraudulentos — mas trate estorno como possibilidade, não como direito garantido. E um alívio honesto: se a chave vazou num repositório público do GitHub, a OpenAI costuma detectar e desativar sozinha, avisando por e-mail. Não conte com isso — nem todo vazamento é num lugar que os scanners varrem. ## Por onde ela vazou: os 5 lugares de sempre Revogar sem descobrir a origem é enxugar gelo — a próxima chave vaza pelo mesmo cano. Na nossa experiência escaneando apps, a origem é quase sempre uma destas: - Commit no GitHub: o arquivo .env (ou um config com a chave dentro) foi parar num repositório público. Vale pra repositório "que era privado e virou público" também. - Código do site/app no navegador: a chave foi colocada no frontend — em apps Vite/Next, qualquer variável com prefixo VITE_ ou NEXT_PUBLIC_ vai junto no código que todo visitante consegue ler. É o furo nº 1 dos apps vibe-coded. - Chamada direta à OpenAI a partir do navegador: se o app chama a API da OpenAI sem passar por um servidor seu, a chave está viajando pro cliente — mesmo "escondida", ela é visível na aba de rede. - Print, vídeo ou tutorial: a chave apareceu na tela durante uma gravação, um pedido de ajuda num grupo, um screenshot de erro. - Documento compartilhado: Notion, planilha, chat do projeto — lugares com mais gente (e mais vazamento) do que você imagina. > **A regra que evita 90% disso.** Chave de API nunca vai pro navegador. Toda chamada à OpenAI (ou a qualquer serviço pago) passa por um backend seu — uma função no servidor que guarda a chave e repassa só o resultado. Se o seu app chama a OpenAI direto do frontend, não existe "esconder direito": a arquitetura está errada, e é ela que precisa mudar. ## E se o vazamento expôs mais do que a chave? Chave da OpenAI vazada, sozinha, é em geral um problema financeiro — não um vazamento de dados pessoais. Mas cheque duas coisas antes de arquivar o susto: primeiro, se o mesmo lugar que expôs a chave (o .env commitado, o código público) expôs também outras credenciais — banco de dados, e-mail, gateway de pagamento; cada uma pede a mesma sequência de revogar e trocar. Segundo, se o seu app envia dados de clientes nos prompts: as conversas comuns não ficam listáveis por quem pegou a chave, mas recursos que o projeto armazena na OpenAI — arquivos enviados, threads de assistentes, fine-tunes — podem ser acessíveis dependendo das permissões da chave. É mais um motivo pra substituta nascer com escopo mínimo, e um bom lembrete de revisar o que você manda pra APIs de terceiros. Se dados pessoais de clientes foram de fato expostos por tabela, aí o assunto muda de nome — vira incidente de dados sob a LGPD, com dever de avaliar risco e, em casos graves, notificar. Não entre em pânico por antecipação; entre em ação pela verificação. ## Quando NÃO é grave (a parte anti-pânico) Falando contra o alarme que gera clique: nem todo vazamento é emergência. Se a chave era de um projeto de teste sem cartão cadastrado ou com limite de gasto zerado, o prejuízo possível é zero — revogue e siga a vida. Se a OpenAI já desativou a chave sozinha (você recebeu o e-mail), o incêndio já está apagado; seu trabalho é só criar a substituta direito e fechar o cano por onde vazou. E se o "vazamento" foi a chave aparecer pra alguém do seu próprio time, rotacione por higiene e transforme o episódio em regra de onde as chaves podem viver. O critério é um só: essa chave podia gastar dinheiro ou acessar coisa sensível? Sem as duas coisas, foi um ensaio de incêndio — de graça. ## Se o app é seu, mas quem fez foi outra pessoa Cenário comum: você pagou alguém (ou usou uma ferramenta de IA) pra construir, e agora descobriu a chave exposta. Três perguntas pra quem construiu resolvem o diagnóstico: onde exatamente as chaves do projeto ficam guardadas? As chamadas a serviços pagos passam por um servidor nosso ou saem do navegador? E o que mais está exposto além dessa chave? A resposta — e a velocidade dela — te diz se foi um deslize pontual ou o sintoma de um app inteiro construído sem a camada de segurança. No segundo caso, a chave é o menor dos problemas: banco aberto e dados de clientes acessíveis costumam morar na mesma casa. **Pra fechar as outras portas** - [Seu app é seguro? As 10 perguntas pra fazer a quem constrói](/blog/app-seguro-10-perguntas) - [Criar um app com IA sem saber programar: onde está o muro silencioso](/blog/criar-app-com-ia-sem-programar) - [De quem é o código do seu app? Como não virar refém](/blog/de-quem-e-o-codigo-do-app) [Quer saber se o seu app expõe chaves, banco ou dados — antes que alguém descubra por você? Rode o scan gratuito da iatize: em minutos você recebe o raio-X do que está público.](/security) ## Perguntas frequentes ### O que é uma chave sk-proj? É o formato atual das chaves de API da OpenAI criadas por projeto — todas começam com sk-proj-. Ela permite que um app use os modelos da OpenAI (GPT e afins) e todo consumo feito com ela é cobrado da conta dona da chave. As chaves antigas começavam só com sk-. ### Minha chave da OpenAI vazou. O que eu faço primeiro? Revogue a chave em platform.openai.com/api-keys — antes de qualquer outra coisa, inclusive antes de criar a substituta. Revogar é instantâneo e é a única ação que interrompe o consumo indevido. Depois: chave nova com permissão mínima, checar o painel de uso, definir limite de gasto e descobrir por onde vazou. ### Vou ter que pagar pelo que usaram com a minha chave vazada? Por padrão, sim — o consumo da chave é cobrado da sua conta, mesmo sendo abuso. Você pode contestar no suporte da OpenAI apresentando o pico de uso que não reconhece; estornos acontecem, mas não são garantidos. Por isso revogar rápido e manter limite de gasto configurado importa mais que a contestação. ### A OpenAI avisa quando a chave vaza? Às vezes. Quando a chave aparece num repositório público do GitHub, a OpenAI costuma detectar, desativar a chave e avisar por e-mail. Mas isso só cobre vazamentos em lugares varridos por scanner público — chave exposta no código do seu site, em prints ou em documentos internos não gera alerta nenhum. ### Posso usar a chave da OpenAI no frontend do meu site? Não. Tudo que está no frontend é legível por qualquer visitante — inclusive variáveis "de ambiente" com prefixo VITE_ ou NEXT_PUBLIC_, que são embutidas no código público na hora do build. Chave de serviço pago vive no servidor: o navegador fala com o seu backend, e só o backend fala com a OpenAI. ### Como sei se meu app está expondo chaves de API? Três checagens: procure a chave no código que chega ao navegador (abra o site, veja o código-fonte e os arquivos JS), procure nos repositórios do projeto por sk- e arquivos .env commitados, e rode um scanner — o scan gratuito da iatize em iatize.tech/security faz exatamente essa varredura num app publicado.