In-depth analysis · About 5 min read
Vercel’s plan to replace persistent agent keys with scoped identities
Vercel combines OIDC tooling, runtime token exchange and planned Marketplace requirements. The security benefit depends on trust policies and correct user scopes.
- Published here
- Source published
- Source checked
In an October 22, 2026 technical essay, Vercel CTO Malte Ubl describes replacing reusable secrets with short-lived service identities. He addresses how AI agents obtain access, how providers validate it, and incentives to change integrations.
Listen to the news
Read this article aloud or keep listening to the news.
Preparing the reader…
Device voice
Speech is handled by your browser or device. AISubHub does not send the text to an audio API. Voice availability and playback with a locked screen vary by device.
Resuming may repeat a short phrase.
At a glance
- Vercel reports 8.4% support for secure authentication in its survey of more than 1,000 SaaS vendors; this is not an industry security score.
- The company plans a Marketplace warning by November 30, 2026 and delisting by January 2027 for vendors failing its stated authentication requirements.
1. A smaller credential lifetime addresses a specific failure
An agent calling several services may inherit keys with more authority than its task needs. A copied key can outlive the conversation. Ubl names repositories, chats, compromised dependencies and prompt injection as exposure paths. Encrypting stored secrets does not stop malicious code reading credentials available to a running application. Both the scope and duration of authority matter.
Vercel’s survey of more than 1,000 SaaS vendors found 8.4% supporting what it calls secure authentication methods. Insufficient sampling and classification details prevent a representative industry estimate. This measures reported support, not breach probability or deployment quality. Vercel’s account of thousands of engineering hours on precautionary key rotations is a company experience, not a measured saving for every customer.
2. Identity requires a receiver that checks the intended boundary
With OpenID Connect, or OIDC, a trusted issuer signs a temporary token identifying the application. The receiver verifies it before authorizing operations. Project and environment rules restrict accepted deployments; the audience identifies the intended receiving service. A valid signature alone does not establish that a token belongs at this API or permits an action.
An exposed temporary token remains usable within its permissions until expiry. A short lifetime limits that copy; it prevents neither exposure nor a compromised workload requesting replacements. Vercel says federation has been generally available since 2024 for obtaining temporary AWS, Google Cloud and Azure credentials. Blob, AI Gateway and Sandbox are existing examples, not launches accompanying this essay.
3. Connect and OIDC UI address different sides of the exchange
Vercel Connect requests provider tokens at runtime using deployment identity. Its Linear example specifies a user subject and read scope. Preconditions include a connector configured and linked to the project, a connected user account, and provider-supported scopes. A function call therefore does not grant arbitrary account access, remove account connection, or unify providers’ permissions.
OIDC UI targets API providers with shadcn/ui trust-policy forms and server-side verification code. The illustrated builder separates issuer, team, project, environment and audience settings. It can reduce repeated implementation. Our analysis: it cannot choose the correct trust boundary. Overly broad project acceptance or a mismatched audience remains a policy problem despite successfully generated forms and verifiers.
4. Faster token handling still includes network dependencies
The essay distinguishes reading an available token from exchanging it. Vercel Functions receive platform identity tokens in request headers; the SDK reads them without fetching another. The platform reuses unexpired tokens. Connect caches provider tokens in-process and refreshes near expiry. Custom-audience requests and provider exchanges still require network calls: authentication does not universally have zero added latency.
The Cosmos DB example requires Azure to trust the Vercel project and default audience. ClientAssertionCredential presents the Vercel token in exchange for an Azure access token, which CosmosClient uses. Renewal and provider availability matter beyond the first successful request. The essay offers no independent latency benchmark or guarantee that caching eliminates authentication outages.
5. Marketplace deadlines are a planned commercial incentive
Ubl identifies difficult setup, request-path latency and weak provider incentives as adoption barriers. Vercel addresses the third through its Marketplace. It plans “Not secure” listing warnings by November 30, 2026 for vendors lacking OIDC authentication from Vercel while using long-lived authentication secrets. Vendors not offering secure authentication are to be delisted by January 2027.
These are announced future ecosystem requirements, not completed enforcement or a universal legal standard. The essay gives no exact January day or execution time. Vercel says its API and native integrations face the same bar; automatic authentication setup when connecting services remains work in progress. Verify actual integration support rather than assuming every Marketplace connection already configures federation.
6. Migration should test authorization, not just token issuance
Consider an illustrative agent that only reads a user’s Linear tasks. We suggest inventorying persistent keys and mapping each service, deployment, user and necessary permission. Configure trust and the user connection; check expected reads succeed while another project, environment, audience or unauthorized operation is rejected. This is a suggested review method, not an AISubHub test or additional Vercel promise.
Before withdrawing the old key, check expiry, renewal, caching and exchange failures, with an explicit recovery plan. Successful token requests can conceal excessive permissions or fragile renewal. The useful shift is limited, renewable authority with observable boundaries. It does not remove credentials, resolve prompt injection, or guarantee every downstream provider supports the protocol.
Why it matters
Our analysis: deployment identity can reduce persistent-key distribution, but receivers must accept and constrain it. Marketplace incentives may expand support; configuration and user authorization remain necessary.
Limits and availability
Analysis of Vercel’s official essay and configuration illustration, without an independent security audit or performance test. Survey methods are incomplete and deadlines are planned. No account, integration or production configuration was changed.
Sources and evidence
Source published: · Source checked:
AI-assisted editorial articles checked against linked primary sources. Vendor claims are attributed; inclusion is not endorsement.