On this page · 11 sections
- What actually shipped on 21 August 2026
- The long-lived secret claim, against the docs
- Revocation is provider-dependent, and the docs say so
- Project links scope who may ask, not what the token can reach
- What it costs, which the launch post never says
- What is still unknown
- What to do this week
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
Summary. Vercel's changelog of 21 August 2026 says apps built in v0 can reach "100+ third-party services" through Vercel Connect, and that "each connection mints a short-lived token, so there's no long-lived secret to store or rotate." Vercel's own Connect documentation, last updated 31 July 2026, describes 8 connector ownership models, and 2 of them do store a long-lived secret: the API key connector holds "a static, long-lived API key" you paste in at create time, and the Custom OAuth connector requires you to bring your own client ID and client secret. The changelog post contains the word "beta" 0 times, the string "$" 0 times and the phrase "token request" 0 times. The Connect pricing page, last updated 9 June 2026, bills Pro and Enterprise teams $3 per 10,000 token requests, with 5,000 per month included on Hobby. The @vercel/connect npm package reached 1.0.0 on 22 August 2026 under Apache-2.0, one day after a launch post for a product the docs still label beta.
None of that makes the feature bad. It makes the announcement an incomplete basis for a procurement decision, and the gap between the two documents is where teams get hurt.
What actually shipped on 21 August 2026
The changelog post, credited to Vercel software engineer Vishal Yathish with contributions from Ben Sabic and Hedi Zandi, is a one-minute read. It states four things: v0 apps and agents can connect to 100+ services including Slack, Google, Notion, GitHub and Salesforce; prompting v0 walks you through creating a connector; connectors belong to your team and are reused across apps; and for Slack and GitHub, Vercel handles the app registration so "there's nothing to set up on the provider's side."
The first three hold up against the docs. The fourth is scoped correctly to Slack and GitHub, but reading it as a general property of Connect is a mistake, and the Vercel Connect overview says why. Microsoft connectors use a Microsoft Entra app that Vercel registers in your own tenant, and app-only tokens plus any delegated scope Microsoft flags as administrator-level "require a tenant administrator to grant admin consent once." If your target service is Microsoft Graph rather than Slack, the setup work is not zero and it is not yours to complete alone.
The long-lived secret claim, against the docs
The security claim is the one worth checking, because it is the reason a team would move off environment variables in the first place.
| Connector type | Who registers the client | What you store | Source page, last updated |
|---|---|---|---|
| Slack, GitHub, Linear | Vercel (Managed Connector) | Nothing on the provider side | /docs/connect, 31 Jul 2026 |
| Microsoft | Vercel, inside your Entra tenant | Nothing, but admin consent required | /docs/connect, 31 Jul 2026 |
| Custom OAuth | You (Customer Managed) | Your client ID and client secret | /docs/connect, 31 Jul 2026 |
| API key | You (Customer Managed) | "A static, long-lived API key" | /docs/connect, 31 Jul 2026 |
| Snowflake, Salesforce | Vercel, via Partner Connect or managed OAuth | Nothing on the provider side | /docs/connect, 31 Jul 2026 |
The connectors concepts page, also last updated 31 July 2026, is blunter about the API key path: "Vercel links you to where the provider issues keys. Generate the key there, then paste it into the connector when you create it." That is a long-lived secret. It has moved from your environment variables into Vercel's store, which is a real improvement in blast radius and rotation discipline, but the changelog's phrasing describes a property the product has for 6 of its 8 connector models, not all of them. The v0 documentation page repeats the same shorthand in its own description line: "no API keys required."
Revocation is provider-dependent, and the docs say so
The second claim worth testing is rotation. The v0 page presents a comparison table whose rotation row reads "Automatic refresh; revoke anytime from the dashboard or API." The tokens concepts page, last updated 9 June 2026, adds the qualifier: "Whether revocation actually invalidates the token depends on the provider. If the provider exposes a revocation endpoint, Vercel Connect calls it. If not, Vercel Connect marks the token for deletion in its own store, but the underlying provider credential may continue to work until it expires naturally."
For an incident-response runbook this is the single most important sentence on the whole product, and it appears on a concepts page dated more than 2 months before the v0 launch. If you are writing a "revoke agent access" procedure, you cannot write it against Connect alone. You have to know, per provider, whether revocation is enforced at the source or is a bookkeeping entry, and the answer is not in the changelog.
The same page sets the token cache behaviour that governs your bill: an in-process LRU cache of 100 entries, keyed by connector and request parameters, with a default validityBufferMs of 30 seconds. A cached token is reused until it falls inside that buffer.
Project links scope who may ask, not what the token can reach
Connectors are team-owned, as the changelog says. What authorizes a runtime token request is a project link. The project links page, last updated 28 July 2026, describes the check: when a deployment calls getToken, Connect matches the calling project's OIDC token against the connector's project links, and rejects the request if no link exists or the link excludes the calling environment.
Then it states the limit plainly: project links "do not add restrictions to a provider token after it is issued, and environments on the same connector can use the same provider installation." A Preview deployment linked to your Slack connector receives a token against the same Slack installation as Production. The recommended fix is a separate connector per environment, installed separately, with the narrowest scopes each one needs. That is 2 or 3 installations to create and maintain per provider, and no v0 prompt will do it for you.
RBAC is finer-grained than most teams expect and worth reading before you delegate. The authentication page, last updated 31 July 2026, says viewing a connector, mutating it, attaching it to a project and revoking tokens are each separately permissioned on the team. It also notes that an access token can only request subjects it represents, so requesting a token for another user requires an OIDC token that represents the project.
What it costs, which the launch post never says
| Plan | Connect token request pricing | Source |
|---|---|---|
| Hobby | 5,000 token requests per month included | /docs/connect/pricing, 9 Jun 2026 |
| Pro | $3 per 10,000 token requests | /docs/connect/pricing, 9 Jun 2026 |
| Enterprise | $3 per 10,000 token requests | /docs/connect/pricing, 9 Jun 2026 |
A token request is defined as a single call that returns a provider token, so in-process caching is the whole cost control: the pricing page says a typical agent making many provider calls in one invocation pays for one token request, not many. An agent that constructs a fresh client per call, or runs in a worker that dies between calls, defeats the cache and pays per call instead. At $3 per 10,000 the absolute numbers stay small at prototype scale, but the ratio between a cached and an uncached agent is the difference between 1 and n, and n is set by your loop.
The same page lists limits that apply during beta: 3 trigger destinations per connector, 100 projects returned by ?include=projects before pagination, and the 30-second default validity buffer. It carries a last_updated of 9 June 2026, so the beta ceilings were published 73 days before the v0 launch that will push volume through them.
What is still unknown
Vercel has not published a date for Connect leaving beta, and the changelog post does not mention beta at all, while both the Connect overview and the v0 documentation do. The catalogue size is also worth pinning down before you plan around it: the changelog says 100+ services, and the docs enumerate 8 connector ownership models, with the full catalogue living at Vercel's connector browse page rather than in the reference docs. Those are different counts of different things, and a 100+ figure in a launch post is a catalogue count, not a promise that a given provider is a Vercel Managed Connector.
What to do this week
If a v0 prototype is already calling a provider, check which of the 8 models the connector uses before you promote it. If it is API key or Custom OAuth, you still own a credential and still need a rotation schedule, so keep it in your secrets inventory. If you rely on revocation for incident response, test it against the specific provider and record whether the token dies at the source. If Preview and Production share a connector, split them now rather than after a staging agent posts to a customer-facing Slack channel. Then update @vercel/connect deliberately: 1.0.0 landed on 22 August 2026, one day after the launch post, and a 1.0 on a beta product is a version number, not a stability guarantee.
The pattern here is the one we keep seeing across Vercel's August releases, from Vercel's always-on tracing span pricing to custom metrics billing and event limits: the changelog carries the capability, the docs carry the cost and the caveat, and the two are written months apart. Read both.
India-specific considerations
For teams building agents in India, the credential model matters for DPDP Act obligations as much as for security hygiene. A Connect user token acts as a specific signed-in person against a third-party service, so the personal data that flows back into your app arrives with that person's permissions attached. Under the Digital Personal Data Protection Act 2023, the notice and purpose limitation you gave the user has to cover what the agent then does with that data, and the Connect Observability tab, which logs token requests, authorizations, trigger deliveries and revocations with tokenId, authorizationId and triggerRequestId correlation IDs, is the artefact an auditor will ask for. Retention beyond your plan window requires forwarding those events to a Drain, available on Pro and Enterprise.
FAQ
How eCorpIT can help
We build and govern production AI agents, and credential models like this one are the part that decides whether an agent survives a security review. Our senior engineering teams map every third-party connector an agent touches to its real credential owner, rotation duty and revocation guarantee, then separate Preview and Production installations before anything reaches a customer channel. eCorpIT is ISO 27001:2022 certified and CMMI Level 5 appraised, and we design applications aligned with DPDP Act requirements. Talk to our AI engineering team about an agent credential review.
Related reading on this cluster: enterprise AI agent governance layers, AI agent security and prompt injection guardrails and the pillar guide to enterprise AI agents in production.
References
Last updated: 24 August 2026.
