Vercel define prazos para fornecedores: chaves estáticas saem de cena até 2027

A Vercel quer fazer com as chaves de API o que o Google e o Let's Encrypt fizeram com a criptografia de tráfego. A empresa consultou mais de 1000 fornecedores de SaaS e descobriu que apenas 8,4% oferecem autenticação segura entre serviços. Os demais continuam distribuindo senhas de bancos de dados e chaves de API sem prazo de validade. Para mexer com o mercado, a Vercel estabeleceu prazos rígidos para os parceiros do seu Marketplace: a partir de 30 de novembro de 2026, fornecedores que não oferecem suporte à autenticação OIDC da Vercel e dependem de segredos de longa duração passarão a exibir a marcação “Not secure” na listagem. Em janeiro de 2027, esses provedores serão removidos do catálogo.

Por que a chave estática virou um problema justamente agora

Um segredo estático de longa duração é uma chave de API ou senha que o aplicativo usa repetidamente, muitas vezes sem data de expiração. Essa chave pode vazar para um repositório ou chat, e também pode ser roubada por meio de uma dependência comprometida. Agora há mais um caminho: a prompt injection, em que o agente é induzido a entregar as próprias credenciais. Além disso, os agentes recebem acesso a sistemas e dados por meio de chaves cujas permissões costumam ser mais amplas do que a tarefa exige.

Criptografar segredos em disco não resolve: um código malicioso em produção lê as variáveis de ambiente da mesma forma que o próprio aplicativo. Enquanto a chave não expira nem é revogada, qualquer pessoa pode usá-la. E a rotação sai cara. Segundo a Vercel, a equipe já fez várias rotações dolorosas por precaução e gastou milhares de horas de engenharia nelas. A empresa não quer repetir a experiência.

O que a Vercel propõe no lugar das chaves

A alternativa é conhecida há tempos: OIDC. Um emissor confiável gera um token assinado e de curta duração que identifica o aplicativo, e o serviço receptor o valida e decide que acesso conceder. Um token roubado deixa de funcionar quando expira. O aplicativo obtém novos tokens de forma programática, então não é preciso distribuir nem trocar manualmente uma chave permanente.

A federação OIDC na Vercel está disponível desde 2024: os aplicativos trocam tokens da plataforma por credenciais temporárias da AWS, do Google Cloud e do Azure, de acordo com políticas de confiança configuradas por projeto e ambiente. Agora a empresa estende a abordagem aos próprios serviços Blob, AI Gateway e Sandbox, além da Vercel API e da CLI, para eliminar tokens de longa duração dos processos de deploy.

Conjunto de novas ferramentas:

• OIDC UI — registro de componentes shadcn/ui com configurador de trust-policy e verificador de tokens no servidor. Há formulários prontos para Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure e emissores OIDC personalizados.
• Vercel Connect — aplicativos e agentes solicitam tokens de provedores em runtime, com base na identidade do deploy. No código, basta uma chamada getToken indicando o usuário e os scopes, por exemplo para acessar o Linear.
• Custom audience — o token fica vinculado a um único serviço receptor.
• Exemplo com Azure — o ClientAssertionCredential troca o token da Vercel por acesso ao Cosmos DB, sem a chave do banco.

Latência e incentivos

A Vercel reconhece que a chave estática tem uma vantagem: ela já está na variável de ambiente e dispensa requisição de rede. Obter e trocar tokens adiciona latência. Por isso, as funções da Vercel recebem o token da plataforma no cabeçalho da requisição, e o SDK o lê sem nenhuma chamada extra. A plataforma reaproveita tokens que ainda não expiraram, e o Vercel Connect mantém em cache, no processo, os tokens dos provedores e os renova perto do fim da validade. As chamadas de rede ficam restritas à custom audience e à troca por tokens de provedores.

Além da conveniência e da velocidade, a Vercel aponta um terceiro obstáculo: os fornecedores têm poucos incentivos para tratar do assunto. É aí que entra o exemplo do Chrome, que primeiro marcou o HTTP como “Not secure” e depois fixou prazos. A Vercel pretende seguir o mesmo caminho e promete os mesmos requisitos para a sua própria API e para as integrações nativas. A empresa também quer que as integrações do Marketplace configurem a autenticação segura automaticamente ao conectar o serviço, sem uma etapa separada.

O que fazer: desenvolvedores e provedores

Se você desenvolve um produto para clientes da Vercel, até 30 de novembro é preciso decidir se vai aceitar tokens OIDC diretamente ou trocá-los por credenciais temporárias. Os componentes do OIDC UI permitem não escrever do zero nem o formulário de configuração de confiança nem a validação de tokens. Se você apenas usa serviços pelo Marketplace, vale verificar com antecedência em quais provedores conectados você mantém chaves permanentes nas variáveis de ambiente e montar um plano para substituí-las.

Para aplicativos com agentes, o ponto de partida lógico é o Vercel Connect: um token emitido para um usuário específico e scopes específicos limita o estrago em caso de prompt injection. Depois da migração, as chaves antigas devem ser revogadas, e não apenas abandonadas.