Por que isso importa agora?
Olha só o cenário: times crescendo, agentes de IA criando projetos em segundos, e um monte de configuraçãozinha esquecida se acumulando. Um preview deployment público aqui, um token de API de longa duração ali... nada disso quebra o build, mas cada um aumenta sua superfície de ataque.
A Vercel respondeu com o Security Dashboard, agora GA (generally available) em todos os planos. Ele te dá uma visão única da sua postura de segurança em todas as contas e projetos, ordenada por risco. Você acessa pela UI ou dispara os mesmos checks pelo terminal com vercel security check.
O dashboard sinaliza coisas como:
- Membros do time sem 2FA ativado
- Credenciais de longa duração que podem virar OIDC federation
- Preview deployments públicos
- Variáveis de ambiente não-sensíveis e obsoletas
Cada achado linka direto pra tela de configuração onde você corrige. Achados que são só ruído pro seu time podem ser silenciados, e o relatório completo exporta pra CSV pra triagem ou compliance.
Se você curte entender como psicologia de produto influencia adoção de ferramentas, dá uma olhada nessa análise sobre behavioral design em UX.

O CLI: feito pra agentes, não só pra humanos
A parte mais legal desse release é o comando vercel security check. Ele foi desenhado pra que agentes de IA leiam os achados, apliquem correções e re-verifiquem — um loop fechado que antes precisava de um humano no meio.
# Roda todos os checks de segurança na conta/time atual
vercel security check
# Limita o check a um projeto específico (mudança mais cirúrgica)
vercel security check --project meu-app
# Emite os achados em JSON pra consumo por agentes
vercel security check --findings
Em CI ou qualquer ambiente não-interativo, o comando escreve o relatório automaticamente em stdout como JSON — sem flag extra. Ou seja, seu pipeline consegue parsear falhas e abrir tickets, ou um agente consegue iterar nas correções.
Correções que um agente consegue aplicar programaticamente:
- Ativar Git fork protection
- Marcar variável de ambiente como sensível
- Trocar credencial estática por OIDC federation
Um loop típico de agente fica assim:
# 1. O agente lê os achados estruturados
vercel security check --findings > findings.json
# 2. O agente parseia findings.json e aplica correções via API/CLI
# 3. O agente roda o check de novo pra confirmar
vercel security check --findings
Esse passo de re-check é o que faz a parada ser realmente útil — o agente não chuta, ele verifica.
Se você também mexe com performance no lado de GPU, o deep dive no CUB single-call API é uma boa leitura complementar sobre reduzir boilerplate em código de baixo nível.

O que ele cobre — e o que ele não cobre
| Check | Auto-fix por agente | Observações |
|---|---|---|
| 2FA faltando no time | Não | Precisa de ação do usuário |
| Credenciais de longa duração | Sim (OIDC) | Melhor candidato pra automação |
| Preview deployments públicos | Parcial | Depende da config do projeto |
| Env vars obsoletas/não-sensíveis | Sim | Marcar como sensível |
| Git fork protection | Sim | Toggle via API |
Limitações que você precisa saber
- É um scanner de postura, não um WAF em runtime. Não pega injeção, SSRF nem falha de lógica na sua app.
- Os achados são heurísticos. Um "preview deployment público" pode ser intencional num site de demo; silenciar é seu amigo, mas silenciar demais derrota o propósito.
- Auto-fix por agente é poderoso mas arriscado. Se você deixar um agente ligar OIDC federation num projeto de produção sem revisão, pode se trancar pra fora. Coloque os fixes baseados em
--findingsatrás de um PR ou aprovação. - Saída JSON só em stdout no modo não-interativo — cuidado pra não vazar detalhes sensíveis nos logs públicos do CI.

Vale a pena ligar hoje?
Vale — o custo de rodar vercel security check uma vez é quase zero, e o primeiro scan geralmente acha pelo menos um token esquecido ou preview público perdido. Comece em modo leitura: roda o check, exporta CSV, triagem com o time, e só depois habilita fixes por agente pras categorias de baixo risco (sensibilidade de env var, fork protection).
Próximos passos
- Roda
vercel security checkno seu maior projeto primeiro. - Pluga a saída JSON no CI como relatório não-bloqueante.
- Quando confiar no sinal, migra OIDC pra modo assistido por agente.
- Re-scan semanal — más configurações voltam conforme o time cresce.
Referência oficial: changelog do Vercel Security Dashboard.