¿Por qué importa esto ahora?
¡Hola Devs! Imagínate el panorama: equipos creciendo, agentes de IA levantando proyectos en segundos, y un montón de configuraciones olvidadas acumulándose en silencio. Un preview deployment público por acá, un token de API de larga duración por allá... nada de eso rompe tu build, pero cada uno amplía tu superficie de ataque.
Vercel respondió con el Security Dashboard, ahora GA (generally available) en todos los planes. Te da una vista única de tu postura de seguridad en todas las cuentas y proyectos, ordenada por riesgo. Lo abres desde la UI o disparas los mismos checks desde la terminal con vercel security check.
El dashboard te marca cosas como:
- Miembros del equipo sin 2FA activado
- Credenciales de larga duración que pueden reemplazarse con OIDC federation
- Preview deployments públicos
- Variables de entorno no-sensibles y obsoletas
Cada hallazgo te lleva directo a la pantalla de configuración donde lo corriges. Los hallazgos que son puro ruido para tu equipo se pueden silenciar, y el reporte completo se exporta a CSV para triage o compliance.
Si te late entender cómo la psicología de producto influye en la adopción de herramientas, checa este análisis de behavioral design en UX.
![]()
El CLI: hecho para agentes, no solo para humanos
La parte más interesante de este release es el comando vercel security check. Está diseñado para que agentes de IA lean los hallazgos, apliquen fixes y re-verifiquen — un loop cerrado que antes necesitaba a un humano en medio.
# Corre todos los checks de seguridad en la cuenta/equipo actual
vercel security check
# Limita el check a un solo proyecto (cambio más quirúrgico)
vercel security check --project mi-app
# Emite los hallazgos como JSON para consumo de agentes
vercel security check --findings
En CI o cualquier ambiente no-interactivo, el comando escribe el reporte automáticamente a stdout como JSON — sin flags extra. O sea, tu pipeline puede parsear fallas y abrir tickets, o un agente puede iterar en los fixes.
Fixes que un agente puede aplicar programáticamente:
- Activar Git fork protection
- Marcar variable de entorno como sensible
- Reemplazar credencial estática por OIDC federation
Un loop típico de agente se ve así:
# 1. El agente lee los hallazgos estructurados
vercel security check --findings > findings.json
# 2. El agente parsea findings.json y aplica fixes vía API/CLI
# 3. El agente corre el check de nuevo para confirmar
vercel security check --findings
Ese paso de re-check es lo que hace que esto sea realmente útil — el agente no adivina, verifica.
Si también le entras a la performance del lado de GPU, el deep dive del CUB single-call API es una buena lectura complementaria sobre cómo reducir boilerplate en código de bajo nivel.

Qué cubre — y qué no cubre
| Check | Auto-fix por agente | Notas |
|---|---|---|
| 2FA faltante en el equipo | No | Requiere acción del usuario |
| Credenciales de larga duración | Sí (OIDC) | Mejor candidato para automatizar |
| Preview deployments públicos | Parcial | Depende de la config del proyecto |
| Env vars obsoletas/no-sensibles | Sí | Marcar como sensibles |
| Git fork protection | Sí | Toggle vía API |
Limitaciones que debes tener en mente
- Es un scanner de postura, no un WAF en runtime. No detecta inyección, SSRF ni fallas de lógica en tu app.
- Los hallazgos son heurísticos. Un "preview deployment público" puede ser intencional en un sitio demo; silenciar es tu amigo, pero silenciar de más derrota el propósito.
- El auto-fix por agente es poderoso pero riesgoso. Si dejas que un agente active OIDC federation en un proyecto de producción sin revisión, te puedes dejar fuera. Pon los fixes basados en
--findingsdetrás de un PR o aprobación. - La salida JSON solo va a stdout en modo no-interactivo — cuidado con filtrar detalles sensibles en logs públicos de CI.

¿Vale la pena activarlo hoy?
Sí — el costo de correr vercel security check una vez es casi cero, y el primer scan normalmente saca al menos un token olvidado o un preview público perdido. Empieza en modo lectura: corre el check, exporta CSV, triage con tu equipo, y solo después habilita fixes por agente para las categorías de bajo riesgo (sensibilidad de env var, fork protection).
Próximos pasos
- Corre
vercel security checken tu proyecto más grande primero. - Conecta la salida JSON a tu CI como reporte no-bloqueante.
- Cuando confíes en la señal, migra OIDC a modo asistido por agente.
- Re-scan semanal — las malas configuraciones regresan conforme crece el equipo.
Referencia oficial: changelog del Vercel Security Dashboard.