Vercel lança tokens com escopo por projeto para reduzir superfície de ataque

A Vercel anunciou no changelog de 30 de julho de 2026 um recurso pequeno no tamanho, mas importante no impacto: os project-scoped tokens, Access Tokens que só conseguem ler e escrever recursos de um projeto específico. Qualquer requisição para outro projeto, ou para recursos de nível usuário ou de time, é negada. Segundo a própria fonte, isso garante que "jobs, tools, or workflows only ever access the projects they are scoped to".

O problema que isso resolve

Até aqui, um Access Token da Vercel carregava as permissões do usuário ou do time. Na prática, um token gerado para automatizar o deploy de um único site tinha, por padrão, acesso a tudo que aquela conta enxergava. Isso é o oposto do princípio do menor privilégio: se o token vaza em um log de CI, num arquivo .env comitado por engano ou numa variável de ambiente mal protegida, o atacante herda alcance sobre toda a organização, não sobre um projeto.

Para quem gerencia vários projetos sob o mesmo time, cenário comum em agências e squads que tocam múltiplos produtos, o token amplo era uma bomba-relógio. O escopo por projeto reduz o raio de explosão (blast radius): um token comprometido só compromete o projeto ao qual foi vinculado.

Como criar

O fluxo descrito na fonte é direto e fica na página de Account Tokens, dentro de Settings da conta:

1. Dê um nome descritivo ao token (vale a disciplina de nomear por uso, algo como ci-checkout-prod).
2. Abra o dropdown de Scope e selecione o time que é dono do projeto.
3. Entre no time e escolha o projeto ao qual o token ficará limitado.
4. Defina uma expiração e clique em Create.

Um detalhe operacional que a Vercel reforça: o token só é exibido uma vez. Se você não copiar na hora, terá que gerar outro. Na prática, isso significa que o passo de guardar a credencial no cofre de segredos (o GitHub Actions Secrets, o Vault, o gerenciador de segredos do seu provedor) precisa acontecer no mesmo momento da criação.

Por que importa para CI/CD

O caso de uso mais óbvio é o pipeline. Se você dispara deploys ou consultas à API da Vercel a partir de um workflow, um token com escopo de projeto encaixa quase perfeitamente no modelo de segredos por repositório: um repositório, um projeto, um token que só toca aquele projeto. Combinado com a expiração obrigatória, você ganha rotação natural das credenciais em vez de tokens eternos que ninguém lembra de revogar.

Algumas recomendações práticas para tirar proveito disso sem se enganar:

• Um token por finalidade. Evite reaproveitar o mesmo token entre projetos ou entre ambientes; o ganho de escopo se perde se você centralizar de novo.
• Expirações curtas onde der. Prefira janelas curtas para automações críticas e planeje a renovação como parte do processo, não como incidente.
• Nomeie para auditar. Nomes descritivos facilitam identificar qual token revogar quando algo dá errado.

Trade-offs honestos

Não é bala de prata. O escopo por projeto não resolve o problema de recursos de nível de time, integrações ou domínios que naturalmente vivem acima do projeto; para essas operações você ainda precisará de tokens mais amplos, e é aí que a disciplina de segurança continua sendo humana. Há também um custo operacional: mais tokens significam mais itens para gerenciar, rotacionar e revogar. Para times pequenos com um projeto só, o benefício é marginal. O valor real aparece em ambientes multi-projeto, exatamente onde o token amplo era mais perigoso.

É uma mudança discreta que segue uma tendência saudável nas plataformas de deploy: dar granularidade fina de permissão em vez do tudo-ou-nada. Para quem opera deploys sérios, o esforço de migrar automações para tokens com escopo por projeto tende a compensar rápido no primeiro susto de segurança evitado. A referência completa está no changelog da Vercel.

Fonte: Vercel Changelog