Governança de chaves da OpenAI API: criação, propriedade, expiração e rotação sem indisponibilidade
Em setembro de 2026, a OpenAI adicionou controles de organização e projeto para a criação e a expiração de novas chaves de API. Este guia explica a precedência das políticas, a escolha entre conta de serviço e usuário, a migração de chaves antigas e uma rotação com sobreposição para evitar interrupções.
Conteúdo
Você quer colocar prazo de validade nas chaves da OpenAI API, mas não quer que uma regra nova derrube uma aplicação nem descobrir, na próxima rotação, que a credencial substituta correta não pode mais ser criada. Também precisa decidir se produção deve usar conta de serviço enquanto cada desenvolvedor mantém uma chave própria.
Este guia oferece uma ordem prática: escolha a propriedade conforme a carga, defina uma validade que o time realmente consiga operar e substitua chaves antigas com uma sobreposição controlada. Comece com dois fatos: regras novas de criação não alteram chaves existentes, e a política da organização prevalece sobre a do projeto.
Comece pela resposta: os novos controles governam chaves futuras, não as antigas
Você pode entender as mudanças de setembro como dois controles: quais tipos de chave nova podem ser emitidos e por quanto tempo novas chaves de projeto podem permanecer válidas.
| Data | Atualização da OpenAI | Significado operacional |
|---|---|---|
| 10 de setembro de 2026 | Chaves de API de projeto podem ser criadas com data de expiração. Administradores podem impor uma vida útil máxima no nível da organização ou do projeto. | Novas chaves podem deixar de ser permanentes, mas o time precisa de uma rotação repetível antes de adotar um prazo curto. |
| 15 de setembro de 2026 | Organização e projeto podem permitir apenas service-account keys, apenas user-owned project keys ou desativar toda criação de nova chave de API. | Produção, desenvolvimento individual e projetos congelados podem usar regras de emissão diferentes. |
| 15 de setembro de 2026 | As restrições da organização prevalecem sobre as configurações do projeto. | Um projeto pode ser mais restritivo, mas não pode tornar a regra da organização mais permissiva. |
| 15 de setembro de 2026 | Chaves de API existentes não são afetadas pelos novos controles de criação. | Ativar a regra não revoga credenciais antigas nem conclui a migração do legado. |
Dois limites importam. “Desativar a criação de novas chaves” não significa “revogar todas as chaves atuais”. Além disso, a descrição de 10 de setembro aplica a vida útil máxima às chaves recém-criadas. Não presuma que uma chave antiga receberá uma expiração retroativa sem verificar o projeto real.
Separe três decisões: quem cria, quanto tempo a chave dura e como ela sai de uso
Projete essas três decisões separadamente; um único controle da Platform não completa a governança do ciclo de vida.
A política de emissão define se o projeto permite chaves de conta de serviço, chaves de projeto pertencentes a usuários ou nenhuma chave nova.
A política de expiração define se uma chave nova precisa expirar e qual é o prazo máximo permitido pela organização e pelo projeto.
A execução do ciclo de vida define quem cria a substituta, onde o segredo é armazenado, como chega às aplicações, quais evidências validam a troca, quando a chave antiga é revogada e como reverter uma implantação com problema.
As duas primeiras decisões podem ser impostas na OpenAI Platform. A terceira continua dependendo do gerenciador de segredos, do processo de deploy, da observabilidade, da atribuição de responsabilidades e dos procedimentos de incidente. Impor uma vida útil máxima sem responsável e sem tempo para entregar a mudança transforma um controle de segurança em uma indisponibilidade programada.
Escolha pelo uso: conta de serviço para produção, chave de usuário para desenvolvimento pessoal
Priorize uma service-account key para produção e cargas compartilhadas, uma user-owned project key para trabalho local ou temporário e desative a emissão apenas em projetos realmente congelados ou em encerramento.
| Carga de trabalho | Geralmente combina melhor com | Por quê | Risco principal |
|---|---|---|---|
| Serviço de produção, backend compartilhado, tarefa agendada, agente operado pelo time | service-account key | A credencial pertence à carga, e não a uma pessoa; mudanças na equipe afetam menos a continuidade. | Uma conta de serviço compartilhada por várias aplicações aumenta o raio de impacto. Separe por projeto ou carga. |
| Desenvolvimento local, depuração temporária, script exploratório | user-owned project key | O proprietário e a responsabilidade individual ficam claros, e o desligamento pode incluir as credenciais do usuário. | Uma chave pessoal não deve virar silenciosamente uma dependência compartilhada de produção. |
| Projeto arquivado, em desativação ou temporariamente congelado | Desativar novas chaves | Impede o crescimento do inventário durante encerramento ou investigação. | Congelar cedo demais pode bloquear a chave substituta necessária para rotação ou recuperação. |
Uma pergunta útil é: a aplicação deve continuar funcionando depois que uma pessoa específica sair do time? Se a resposta for sim, a credencial de produção normalmente não deve depender da conta desse funcionário. No sentido oposto, distribuir uma chave de serviço compartilhada para todos os notebooks reduz a rastreabilidade e multiplica as cópias do segredo.
Nenhum tipo é seguro por si só. O risco real depende de escopo, armazenamento, acesso, vida útil, rotação e revogação. Uma chave de serviço duradoura copiada para dezenas de aplicações continua sendo um grande ponto único de exposição.
A organização define o teto: o projeto pode apertar, não afrouxar
A restrição da organização é o teto de todos os projetos, então ensaie a próxima rotação antes de aplicá-la de forma ampla.
Se a organização permite apenas chaves de conta de serviço, um projeto de desenvolvimento não pode flexibilizar sua configuração para emitir chaves de usuário. O projeto pode restringir mais dentro do limite da organização, mas não torná-lo mais permissivo.
Antes de alterar uma regra para toda a organização:
- Liste os projetos e classifique-os como produção, homologação, desenvolvimento, teste, temporário, arquivado ou em desativação.
- Registre o tipo de chave necessário na próxima rotação de cada projeto, e não apenas os tipos atuais.
- Identifique a credencial substituta de cada carga ativa e confirme que a regra planejada permitirá criá-la.
- Ensaie criação, distribuição, validação e revogação em um projeto de baixo risco.
- Aplique a restrição da organização somente depois de provar que a rotação normal continua possível.
Como chaves antigas seguem funcionando, uma regra rígida demais pode parecer inofensiva no dia em que é ativada. O problema aparece depois, quando uma chave se aproxima da expiração e o time descobre que a política não permite criar a substituta correta. Teste a próxima rotação, não apenas o tráfego atual.
Não use a mesma validade para tudo: comece pelo tempo real de rotação
A vida útil máxima deve ser maior que todo o tempo necessário para aprovar, emitir, distribuir, implantar, observar e reverter a substituição.
Defina pelo menos:
| Campo | Pergunta que deve responder |
|---|---|
Vida útil máxima N | Quanto tempo uma chave nova pode existir entre a criação e a expiração? |
Antecedência R | Quanto tempo antes da expiração a substituição deve começar? |
| Responsável principal e reserva | Quem executa e quem assume em caso de ausência? |
| Método de distribuição | A aplicação carrega uma nova versão do segredo ou exige reinício/redeploy? |
| Evidência de validação | Quais requisições, logs, erros e sinais de uso comprovam a mudança de tráfego? |
| Janela de rollback | Por quanto tempo a chave antiga fica disponível depois da troca? |
| Processo de exceção | Quem aprova uma extensão, por quanto tempo e com quais controles compensatórios? |
R precisa cobrir toda a cadeia. Uma vida útil muito curta, combinada com cópia manual, aprovações entre fusos e ausência de substituto, é menos confiável que um prazo um pouco maior com alertas automáticos e runbook ensaiado.
Use o máximo da organização como teto comum. Projetos de maior risco podem adotar um limite menor, nunca maior. Produção, desenvolvimento pessoal, teste temporário e projeto em encerramento têm impacto e velocidade de recuperação diferentes e não precisam compartilhar mecanicamente o mesmo número.
Faça a rotação sem indisponibilidade com estes sete passos
O padrão mais seguro é manter a chave antiga e a nova em paralelo por pouco tempo e revogar a anterior somente quando o tráfego real comprovar a troca.
1. Monte um inventário das chaves atuais
Registre projeto, tipo de proprietário, carga, aplicação, ambiente, responsável, local do segredo, método de deploy, data de criação, expiração conhecida e último uso observado. Uma chave com finalidade ou proprietário desconhecidos deve entrar em uma investigação prioritária, e não em uma revogação em massa às cegas.
A entrada de 4 de agosto de 2026 informa que os painéis Usage e Costs, a Usage API e a Costs API permitem filtrar e agrupar por chave de API. Essa dimensão ajuda a identificar se uma credencial ainda gera requisições. Ela é apenas uma evidência: tarefas mensais, caminhos de recuperação e jobs de baixa frequência podem ficar silenciosos por bastante tempo.
2. Crie uma substituta compatível com a política
Crie a nova chave no projeto correto, com o tipo de propriedade permitido pelas regras vigentes, e atribua uma expiração dentro do máximo aplicável. Verifique a capacidade de emissão antes da janela de manutenção.
3. Armazene como nova versão do segredo
Não sobrescreva imediatamente a única cópia do valor antigo. Mantenha as duas versões durante a transição controlada, com estados claros como “produção atual”, “candidata à rotação” e “aguardando revogação”. Não coloque chaves em código-fonte, imagens, tickets, logs ou chats.
4. Mude o tráfego gradualmente
Comece com uma instância, um job de baixo risco ou uma pequena parcela do tráfego. Valide autenticação, atribuição ao projeto, permissões e comportamento das requisições antes de ampliar. Se a aplicação lê o segredo apenas na inicialização, inclua reinícios e capacidade no plano.
5. Observe a saúde e o uso por chave
Monitore requisições bem-sucedidas, erros de autenticação, limites, latência e resultado de negócio. Ao mesmo tempo, confirme que a chave nova começa a registrar o uso esperado e que o uso da antiga cai. Um deploy concluído não prova que o tráfego mudou.
6. Limite a janela de rollback
Mantenha a chave antiga por um período definido após a estabilização e depois a revogue. A janela deve cobrir workers atrasados, regiões e tarefas raras, mas não permanecer aberta indefinidamente. Duas chaves válidas para sempre apenas duplicam a exposição.
7. Revogue, verifique e programe a próxima rotação
Depois da revogação, confirme que a chave antiga falha e a nova continua funcionando. Atualize inventário, instruções de plantão, responsável, expiração e próxima data de rotação.
Chaves antigas não ficam compatíveis sozinhas: migre por risco
Depois de ativar as novas regras, você ainda precisa de uma fila separada para chaves antigas porque propriedade e validade não mudam automaticamente.
Crie uma fila de migração separada e priorize:
- credenciais encontradas em código, tickets, logs ou chats;
- chaves sem proprietário ou finalidade identificável;
- chaves pessoais de pessoas que saíram ou mudaram de função;
- chaves compartilhadas por várias aplicações de produção;
- chaves com escopo amplo ou alto impacto;
- chaves com responsável claro, uma carga e caminho de substituição testado.
Não meça o sucesso por revogar todas as chaves antigas no mesmo dia. Um critério mais seguro é que cada chave tenha mapa de dependências, substituta aprovada, evidência de corte e data de revogação. Para uma exceção temporária, documente o bloqueio exato, o responsável, o controle compensatório e a data de término. “Sistema legado” não é tratamento permanente de risco.
Sua política interna precisa de pelo menos estes 11 campos
Uma política executável deve indicar a regra, o responsável, as evidências de validação, a janela de rollback e a condição de revogação.
| Item | O que registrar |
|---|---|
| Escopo | Organização, projetos, ambientes e classes de carga |
| Tipo permitido | Apenas serviço, apenas usuário ou nenhuma chave nova |
| Justificativa | Continuidade, responsabilidade individual, congelamento ou outro motivo documentado |
| Vida útil máxima | Teto da organização e limites de projeto mais rígidos |
| Antecedência | Quando criar alerta ou tarefa antes de expirar |
| Armazenamento | Gerenciador de segredos aprovado e papéis de acesso |
| Implantação | Canary ou fases, reinício e rollback |
| Evidência | Requisições corretas, métricas de erro, uso por chave e tráfego antigo em zero |
| Revogação | Chave nova estável, tarefas raras cobertas e janela encerrada |
| Exceção | Aprovador, motivo, compensação e expiração da exceção |
| Auditoria | Criação, alteração de política, deploy, revogação e troca de responsável |
Atribua a responsabilidade duradoura a uma carga ou função do time, mas indique a pessoa que executará cada rotação. “O time de plataforma cuida” não é operacional sem plantão, prazo e escalonamento.
Antes de impor a regra, ensaie a próxima rotação
Aplique restrições de organização ou projeto somente depois de responder a todos os itens abaixo e concluir um ensaio de baixo risco.
- cada aplicação ativa está associada a um projeto e uma credencial específicos;
- o tipo necessário na próxima rotação de cada projeto é conhecido;
- a regra da organização não bloqueará uma substituta crítica;
- produção não depende da chave pessoal de uma única pessoa;
- o cofre de segredos suporta versões ou rollback confiável;
- o carregamento do novo segredo, inclusive reinício, foi testado;
- uso ou custo pode ser observado por chave considerando tarefas raras;
- há responsável principal e reserva;
- os alertas chegam com antecedência suficiente;
- critérios de revogação impedem sobreposição permanente;
- cada chave legada pendente tem bloqueio, responsável e prazo.
Perguntas frequentes
Uma nova restrição quebra aplicações existentes imediatamente?
Segundo a atualização de 15 de setembro de 2026, as chaves existentes não são afetadas pelos controles de criação. Alterar os tipos de novas chaves não revoga automaticamente as credenciais em uso. A regra pode bloquear a próxima rotação, por isso a emissão da substituta deve ser ensaiada.
A vida útil máxima expira retroativamente chaves antigas?
A atualização de 10 de setembro descreve o limite para chaves novas. Não presuma efeito retroativo; verifique os detalhes de cada chave e migre o legado separadamente.
Um administrador de projeto pode flexibilizar a regra da organização?
Não. A restrição da organização tem precedência sobre as configurações do projeto.
Toda organização deveria usar apenas chaves de conta de serviço?
Priorize chaves de conta de serviço para produção, backends compartilhados, tarefas agendadas e agentes operados pelo time. Priorize chaves de projeto de usuário para desenvolvimento local e exploração de curta duração. Uma regra de conta de serviço para toda a organização só faz sentido quando quase todos os projetos pertencem ao primeiro grupo e o desenvolvimento já tem uma alternativa viável.
Quando desativar toda criação de novas chaves?
Em projetos arquivados ou em desativação, ou temporariamente durante uma investigação de segurança. Primeiro confirme que uma chave nova não será necessária para rotação ou recuperação.
O que prova que uma chave antiga pode ser revogada?
Combine estado do rollout, requisições bem-sucedidas com a chave nova, monitoramento de erros, uso por chave, execução de tarefas raras e término da janela de rollback. Um curto período sem tráfego normalmente não basta.
O que fazer primeiro
Comece com três ações: registre o tipo de chave de que cada projeto precisará na próxima rotação, conclua uma rotação com sobreposição em um projeto de baixo risco e só então imponha as restrições de organização e projeto.
A ordem importa. Se você definir o teto primeiro, as aplicações atuais podem continuar funcionando enquanto a política bloqueia silenciosamente a substituta necessária no futuro. Comprove que a próxima rotação funciona antes de apertar as regras.
Fonte oficial:
