ForgeNEX

Vercel wants to kill static credentials, but its own token is still alive

Vercel is pushing to eliminate static API keys with OIDC, but its own deployment flow in GitHub Actions still uses a persistent token. We analyze what this implies for SMBs.

4 min read

In this article

Vercel has put on the table a crusade against static credentials, those long-lived API keys that cause so many headaches when they leak. The company wants its Marketplace providers to migrate to OpenID Connect (OIDC) and short-lived tokens before January 2027, on pain of being removed from the catalog. The news, published by The New Stack, comes at a time when supply chain attacks that steal credentials—including a recent npm worm that extracted tokens directly from CI pipelines—keep demonstrating the damage a single leaked secret can do.

Vercel's CTO, Malte Ubl, explained that they surveyed more than 1,000 SaaS providers and only 8.4% supported authentication methods that the company considers secure. That is why they are pushing OIDC and short-lived identity tokens as an alternative to static keys that can remain valid indefinitely. The CEO, Guillermo Rauch, amplified the message on X: "it's time to kill static credentials," arguing that, even if attacks continue to occur, stolen credentials should behave like "self-destructing keys" that expire before an attacker can continue using them.

Illustrative detail: Vercel moved to kill static credentials. Then developers spotted its own deployment token.

Vercel's double standard

The paradox surfaced quickly. Yordis Prieto, a senior engineer at Fanatics, pointed out on social media that Vercel had "invented" OIDC federation but that he still depended on "a long-lived access token" in his CI pipeline. Vercel's deployment guide with GitHub Actions still instructs developers to authenticate deployments with a VERCEL_TOKEN secret. In Thursday's announcement, Ubl says the company is extending OIDC support to its API and CLI to retire long-lived tokens from deployment flows, but for now Vercel is asking Marketplace providers to adopt a standard that its own deployment tool has not fully implemented.

In addition, starting November 30, Marketplace integrations that do not meet the authentication requirements will display an "Unsecure" warning in their listing. The company has not published the methodology of its survey, nor named the companies surveyed, nor disclosed how many current Marketplace partners will have to change their authentication systems. These are data points that, for the moment, remain up in the air.

Short-lived tokens for AI agents

As AI agents access more external services, credential management becomes a critical aspect for agent harnesses. One way to reduce the risks of persistent access keys is to use short-lived, just-in-time credentials that expire instead of leaving agents with continuous access. Vercel's Connect service addresses part of that problem by allowing applications and agents to request scoped credentials at runtime using their deployment identity, instead of storing secrets in application environments. Connect also handles token exchange and renewal. An October 15 update added company-managed authorization in public beta, allowing administrators to control access to supported services through identity providers such as Okta.

However, Connect still supports static API keys for providers that lack OAuth or another identity-based option. Its documentation describes the centralized storage of those credentials and their retrieval at runtime, but the underlying keys can still live indefinitely. The company also introduced GitHub OIDC authentication for its Container Registry in late September, although that work does not eliminate the VERCEL_TOKEN requirement in its documented GitHub Actions deployment flow.

What it means for an SMB or an IT team

Beyond Vercel's specific case, the underlying debate is relevant for any organization that deploys software: static credentials are a cumulative risk. Every long-lived token stored in a repository, in an environment variable, or in a CI pipeline is a door that can remain open forever if it leaks. Supply chain attacks that steal tokens in CI are increasingly common, and a single compromised secret can give access to critical infrastructure.

For an SMB, the recommendation is to start by identifying where static credentials exist in their workflows: deployment tokens, cloud service API keys, secrets in GitHub Actions, etc. From there, prioritize migration to OIDC or short-lived tokens with those providers that already support it. It will not always be possible (as Vercel itself demonstrates), but reducing the exposure surface is an achievable goal. It is also advisable to review the expiration of existing tokens and establish periodic rotations, even if manual, as a containment measure.

At ForgeNEX we recommend approaching credential management as part of a broader security strategy. It is not just about adopting OIDC, but about understanding which identities need which access and for how long. Tools such as identity providers (Okta, Azure AD) and federation with OIDC can help, but they require planning. If your team has not started yet, a good first step is to audit stored secrets and eliminate those that are no longer used. As we have seen in recent cases, such as the compromise of CA keys, careless credential management can have serious consequences.

The lesson from Vercel's case is that practicing what you preach is not easy, but the direction is clear: fewer static secrets and more ephemeral identities. SMBs that take steps in that direction will be better prepared for the attacks that will undoubtedly keep coming.

Source: The New Stack. Analysis and adaptation: ForgeNEX.

Keep reading