Vercel Agent ya instala paquetes privados de npm y registries

Qué cambia en Vercel Agent con paquetes privados

Vercel Agent ya puede instalar dependencias privadas desde npm y desde registros personalizados sin que el equipo de desarrollo tenga que improvisar workarounds. La novedad llega por el changelog oficial de Vercel publicado el 30 de septiembre: el agente ahora reutiliza las credenciales que ya existen en los builds de Vercel para autenticar instalaciones dentro de sus sesiones. En la práctica, cualquier paquete interno o de un registry propietario puede instalarse automáticamente, igual que ocurre cuando corres npm install en un deploy normal de Vercel.

El anuncio cierra una de las fricciones más comentadas desde el lanzamiento del agente en junio: la imposibilidad de trabajar con dependencias internas. Para founders y equipos que mantienen componentes propietarios, SDKs compartidos o paquetes publicados en un registro corporativo, esto cambia el alcance de lo que un coding agent puede hacer en su nombre.

Cómo funciona el acceso a dependencias privadas

La mecánica es directa. Vercel Agent reconoce tres package managers — npm, pnpm y el modo clásico de Yarn — y los autentica en sus sesiones exactamente como lo haría un build tradicional. Para configurarlo hay que declarar una variable de entorno compartida en el dashboard, disponible para Development o Preview, según documenta Vercel.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Hay dos variables oficiales:

NPM_TOKEN: pensada para paquetes privados alojados en registry.npmjs.org.
NPM_RC: útil cuando trabajas con un registro propio o con múltiples registros en paralelo.

El detalle clave es que el agente solo lee variables compartidas a nivel de equipo, nunca las que estén definidas a nivel de proyecto. Esto es deliberado: la jerarquía de permisos del entorno de Vercel se respeta, y los proyectos individuales no pueden exponer secretos a sesiones del agente que no les correspondan.

El modelo de seguridad: credenciales fuera del sandbox

La parte más interesante del anuncio no es la compatibilidad con npm, sino el tratamiento del secreto. Vercel fue explícito en su changelog: los valores de las credenciales permanecen fuera del sandbox del agente. Es decir, el agente puede usar el token para autenticarse y descargar paquetes, pero no puede leerlo ni imprimirlo en logs, respuestas o archivos de la sesión.

Esto resuelve un problema que la propia Vercel llevaba meses señalando como prioritario. En una entrevista con TechCrunch tras su conferencia ShipNYC de junio, su CEO Guillermo Rauch describió el sandbox como «una pequeña jaula» en la que el agente puede actuar con libertad, pero donde se aplica política sobre qué datos puede leer y qué datos pueden salir. El acceso a credenciales sigue exactamente esa lógica: el secreto se invoca, pero nunca se expone.

Para un founder, eso significa que delegar la instalación de dependencias internas en el agente ya no obliga a entregarle tokens de npm en texto plano dentro del contexto.

El contexto: por qué importa en 2026

La actualización llega en un momento en el que Vercel Agent pasó de ser un experimento a ser la mitad del tráfico de la plataforma. Según datos compartidos por Vercel en Ship y recogidos por SiliconANGLE, a principios de 2026 menos del 3% de los deployments en Vercel eran disparados por coding agents; seis meses después, los agentes ya representan más de la mitad de todos los commits. En paralelo, el volumen de tokens que pasa por el AI Gateway de Vercel creció desde aproximadamente 2 millones hasta 20 millones en el mismo período.

El propio Rauch lo resumió así en Ship: «Cada nueva generación de software necesita una nueva generación de infraestructura. Para la era de los agentes, esa es Vercel». El stack de agentes de Vercel — Agent Stack, Vercel Sandbox, eve como framework open source y Vercel Agent como ejecutor autónomo — se está consolidando como infraestructura de producción para empresas como DoorDash, OpenAI, Stripe, The Weather Company y Helly Hansen, según el comunicado oficial de la compañía recogido por Yahoo Finance.

En ese contexto, soportar dependencias privadas no es una mejora menor: es el paso que faltaba para que equipos con código propietario serio pudieran mover el agente de un entorno de pruebas a flujos de trabajo reales.

Riesgos que esta actualización no resuelve

Sumar credenciales al sandbox del agente no elimina el problema de fondo de los coding agents y la cadena de suministro de paquetes. La propia industria lleva meses documentándolo:

Investigadores de Phoenix Security cifraron en su reporte de cadena de suministro de 2026 que el primer semestre del año superó en más de 2,6 veces el volumen de campañas y en 4,5 veces el de paquetes comprometidos respecto a todo 2025, con los agentes de IA como acelerador documentado.
En enero de 2026, Aikido Security registró en npm un paquete llamado react-codeshift — un nombre que un modelo de lenguaje había «alucinado» y que ya se había filtrado a 237 repositorios en GitHub mediante archivos de configuración generados por agentes. Es el fenómeno conocido como slopsquatting.
En febrero, el incidente Clinejection en Cline demostró cómo un solo issue en GitHub podía terminar ejecutando un npm install malicioso en el pipeline de release, afectando a más de 5 millones de desarrolladores.

La nueva función de Vercel no bloquea paquetes maliciosos por sí sola. Lo que hace es encapsular las credenciales legítimas para que el agente pueda operar sin filtrarlas, lo que reduce un vector de ataque sin sustituir controles de allowlist, SBOM o análisis de comportamiento a nivel de paquete.

Qué significa esto para tu startup

Si tu equipo ya usa Vercel y mantiene un SDK interno, un design system privado o dependencias en un registro corporativo, esta actualización te permite darle al agente el mismo contexto que tiene un build de CI. Eso desbloquea flujos donde el agente puede refactorizar componentes internos, añadir tipos a paquetes propietarios o ejecutar migraciones sobre código que vive detrás de tu npm privado.

Tres acciones concretas para aplicar esta semana:

Audita qué necesitas realmente exponer. Antes de crear el NPM_TOKEN o el NPM_RC, define qué paquetes privados son indispensables para los flujos donde se usará el agente. Si solo lo usas para un design system, el alcance del token puede limitarse a un scope o a un registro dedicado.
Configura la variable a nivel de equipo, no de proyecto. El agente solo lee variables compartidas; aprovéchalo para mantener una separación clara entre las credenciales que un build cualquiera podría usar y las que un agente está autorizado a invocar.
Complementa, no sustituyas, tu postura de seguridad. Mantén una allowlist de paquetes aprobados para entornos sensibles, registra en logs qué dependencias instala el agente y revisa el package.json y el lockfile después de cada sesión, igual que harías con código generado por un PR de un junior.

Para equipos que aún no usan Vercel Agent, la señal más relevante del anuncio es otra: Vercel está cerrando la lista de fricciones que separan a un coding agent de un entorno de producción real. En la segunda mitad de 2026, esperar a que un agente «solo funcione con paquetes públicos» dejará de ser una opción razonable.