Vercel v0 Can Use Private npm Packages Without Exposing Tokens to the Model

Vercel v0 can now install private npm packages and packages from custom registries by reading shared environment variables. Teams can provide NPM_TOKEN for private packages on npm or use NPM_RC for scoped and multiple registries, including GitHub Packages and JFrog Artifactory.

The most important part of the release is the boundary Vercel describes: sensitive credentials are not exposed to the model and are not written to the sandbox filesystem. That is a better design than pasting a token into chat, but it still needs a disciplined setup and a revocation test.

The short setup path

1. Create a read-only or package-download token with the narrowest supported scope.
2. Add NPM_TOKEN as a shared environment variable for packages on registry.npmjs.org.
3. Use NPM_RC when the project needs a scoped registry, several registries or an internal package host.
4. Scope the variable to Development and/or Preview instead of every environment by default.
5. Mark the credential sensitive.
6. Open Settings > Integrations in v0 and confirm the integration state.
7. Run a controlled install, then revoke the token and verify that a later install fails.

NPM_TOKEN and NPM_RC solve different cases

Variable	Use it when	Primary risk
NPM_TOKEN	The dependency is a private package hosted on the public npm registry	A token is broader than the package or team actually needs
NPM_RC	The project uses scoped, private or multiple registries	The configuration sends credentials to an unintended registry

NPM_RC can reference other environment variables. That is useful for configurations such as an @acme scope on GitHub Packages, but it also creates a second review surface: the registry mapping and the secret it references. Check both.

The model boundary is not the whole supply-chain boundary

Vercel’s statement that v0 does not expose a sensitive credential to the model or write it into the sandbox addresses two common leak paths. It does not make every dependency trustworthy. A package installation can still execute lifecycle scripts, pull transitive dependencies, change a lockfile or introduce code that later runs with application privileges.

• Pin package versions and commit the lockfile.
• Review install scripts for internal packages and newly introduced dependencies.
• Use registry and namespace controls that reduce dependency-confusion risk.
• Scan the generated dependency diff before accepting it.
• Keep publish, delete and administrative package permissions out of an install credential.

A private package should not turn Preview into production

The shared variable is scoped to Development and/or Preview in Vercel’s setup. That makes sense for v0’s build workflow, but teams should confirm what the imported package itself can reach. A private design-system package may be low risk; an internal SDK that defaults to production services may not be.

Use non-production endpoints, test accounts and isolated data for preview work. If a dependency selects its backend from environment variables, include that configuration in the review. The package credential should unlock code retrieval, not silently grant access to production APIs.

Test the negative path, not only the happy path

Test	Expected result	What it proves
Correct token and registry	Only the approved package installs	The integration is configured
Revoked token	Install fails cleanly	Revocation is enforced
Wrong package scope	Registry denies the request	The token is not over-broad
Unapproved registry	No credential is sent	The registry mapping is constrained
Generated source and logs	No secret value appears	The expected non-exposure boundary holds in the observed run
Lockfile diff	Only expected packages and versions change	The dependency change is reviewable

Rotation needs an owner and a failure plan

Record who owns the credential, what registry it reaches, which environments receive it and how quickly it can be revoked. Short-lived credentials are preferable when the registry supports them. If a long-lived token is unavoidable, set an expiry reminder and monitor package-download activity for unexpected projects or locations.

A failed rotation should stop the install, not encourage someone to paste a replacement secret into the prompt. Document the correct recovery path in the repository or team runbook.

How this changes a v0 review

Previously, a reviewer could treat most v0 output as source and public dependencies. Private package support adds organizational code, internal release cadence and registry policy to the generated application. Reviewers need to know which package version was installed, why it was selected and whether the generated usage matches the package’s supported API.

Our GitHub Copilot code-review guide explains why an automated resolution is not proof that a finding was fixed. The same principle applies here: a successful build is evidence that the package installed, not that the dependency or generated integration is safe. The WebMCP permission-boundary guide offers a complementary checklist for agent tools that act as a signed-in user.

The practical verdict

Private package support removes a real obstacle for teams using v0 with internal components and design systems. The security claim is also directionally important: the model does not need to receive the token just because the build needs authenticated package access. Treat that as one protected handoff inside a larger software-supply-chain review. Narrow the credential, constrain the registry, inspect the lockfile, test revocation and keep Preview isolated from production.

Primary sources

• Vercel v0 private npm credential announcement
• v0 private dependencies documentation

Checked September 21, 2026. Secret-handling behavior is attributed to Vercel. The threat model and test plan are MustHave.ai analysis.