{"slug": "introducing-vercel-connect", "title": "Introducing Vercel Connect", "summary": "Vercel announced Vercel Connect, a new service in public beta that replaces long-lived provider tokens with runtime credential exchange for agent access. The system uses short-lived, scoped credentials obtained via OIDC identity verification, reducing the risk of token leaks and enabling least-privilege access. Vercel Connect is available for providers like Slack and GitHub, with support for fine-grained permissions and user-specific authorization.", "body_md": "Giving your agents access to your tools, data, and services is what makes them useful. As agents perform deeper work across systems, authenticating and authorizing that access becomes central to your application architecture.\n\nToday, agent access is usually granted through long-lived provider tokens stored in your environment variables, provisioned for everything your agent might need. These tokens are shared across every user, never expire, and give your agent full reach across every task, no matter how small the job.\n\nA vault makes that token harder to steal. It doesn't make it less dangerous. The problem is what happens when the token leaks: everything it can touch is now exposed.\n\nWe built [Vercel Connect](https://vercel.com/connect) to solve this problem. Now in Public Beta, Vercel Connect replaces the stored token with runtime credential exchange. You register a connector once. When your agent has work to do, your app proves its identity to Vercel Connect and gets back a short-lived credential, scoped to the task. Everything you used the token for still works. The agent just requests access each time instead of holding it.\n\nA connector is a reusable connection between your Vercel team and a provider like Slack or GitHub. You create it once from the dashboard or the CLI, then attach it to the projects and environments that need it, with project-level access controls.\n\nThe relationship with the provider becomes a single entity you can see and manage, not something scattered across a dozen environment variable panels where a rotation means hunting down every copy.\n\nYour coding agent can run this setup too. Install the vercel-connect skill with `npx skills add vercel/vercel-plugin --skill vercel-connect`\n\n, and it can create and attach connectors for you.\n\nWith a connector in place, the agent asks for a credential only when it has work to do. The [ @vercel/connect](https://www.npmjs.com/package/@vercel/connect) SDK returns a token you use immediately against the provider API, and no provider secret lives in your app.\n\nTokens are short-lived, with a lifetime that depends on the provider. The SDK refreshes them automatically, so you never rotate a secret by hand. That leaves one question. If your app holds no secret, what proves it's allowed to ask?\n\nThe proof is an identity your app already has. Every deployment on Vercel gets an OIDC identity, and when your app or agent requests a token, the SDK presents that identity to Vercel Connect. Vercel Connect verifies it, checks that the project and environment are allowed to use the connector, and returns the provider credential. That round trip is the runtime credential exchange.\n\nThe same identity is available during local development through `vercel link`\n\nand `vercel env pull`\n\n, and outside Vercel, the SDK accepts a Vercel access token. Either way, there is no provider secret in your app to leak, commit, or copy between environments.\n\nNot every task needs the same reach, even within a single agent. One step might read a repository while the next opens an issue. Each requests exactly the access it needs, and the request itself sets limits. A request can include:\n\nProvider scopes\n\nAn installation ID\n\nResource restrictions\n\nProvider-specific authorization details\n\nGitHub is the sharpest example because it can restrict a token to specific repositories and permissions.\n\nThe deployment agent can read that one repository and do nothing else. A fine-grained GitHub App install can be narrow too, but an install is a standing grant, set up once and trusted from then on. This limit exists for one request, one task. Least privilege becomes the shape of the request.\n\nA shared bot token gives every user's request the same identity and reach. Vercel Connect lets you set that identity. Switch `subject`\n\nfrom the app to a named user, and the token acts on that user's behalf, scoped to what that user authorized.\n\nWhen a user first grants access, `startAuthorization`\n\nruns the consent flow through a callback URL, a webhook, or a device code. After that, the agent requests tokens as that user.\n\nA connector is attached to the projects and environments you choose, so you can run a separate connector for development, preview, and production instead of pointing one at all three. When each environment has its own connector with an authorization grant and scopes, a credential compromised in development cannot be replayed against production.\n\nSeparate connectors limit where a credential works, but they don't pull back access already issued. That's normally the painful part. With a stored token, that means a rotation. You mint a new secret, update every place the old one lived, and redeploy whatever depended on it. With Vercel Connect, you revoke the connector's tokens, either your own or all of them.\n\nWhat revoking does depends on the provider. Where the provider supports revocation, Vercel Connect revokes the token at the provider. Where it does not, Vercel Connect stops issuing new tokens for that grant, and a token already issued stays valid at the provider until it expires. That is a real limit on any provider without a revocation API, and the shorter the provider keeps its tokens, the smaller that window is.\n\nSo far, your agent has been the one reaching out. It requests a token and calls a service when it has work to do. Triggers run the other way. A connected service sends an event to your app, and your agent responds.\n\nVercel Connect receives the provider's webhook, verifies it, and forwards it to your project. Trigger forwarding is in beta and supports Slack, GitHub, and Linear today. A Slack connector can forward its verified webhooks to up to three of your projects, so a message in Slack can wake an agent that acts on it.\n\nThe flow runs end to end without a provider secret in your app:\n\nA user posts a message in Slack.\n\nSlack sends the event to Vercel Connect.\n\nVercel Connect verifies the event against the Slack signing secret it holds, then forwards it to your Vercel app, re-attested with its OIDC identity.\n\nYour app verifies that attestation, then requests a scoped runtime token.\n\nThe agent acts and responds.\n\nThe Slack signing secret does not disappear. It moves server-side to Vercel Connect, which verifies the upstream webhook and re-signs the forwarded request with an identity your app can check. Your app holds no bot token to act with and no signing secret to verify against.\n\nUnderneath everything is one call. Whether your agent is built on the AI SDK, runs as a background job, or is a loop you wrote yourself, it asks for a token the same way, with `getToken`\n\n. Around that call are adapters for the stack you already run. [Better Auth](https://www.better-auth.com/) (`@vercel/connect/betterauth`\n\n) and [Auth.js](https://authjs.dev/) (`@vercel/connect/authjs`\n\n) get provider configs in the shape they expect, and `@vercel/connect/ai-sdk`\n\nand `@vercel/connect/mcp`\n\ndo the same for AI SDK tools and MCP clients. The [Nuxt starter](https://github.com/vercel-labs/nuxt-connect-starter) gives you a working app to build on, with GitHub and Linear connected, no provider secret, and no OAuth refresh token stored in its database.\n\nFrameworks can take this further and make the connection itself declarative. In [eve](https://eve.dev/), the open-source agent framework by Vercel, a connection is one file, and the `@vercel/connect/eve`\n\nadapter supplies that connection's credential.\n\nThere is no token handling in the agent's code, because `connect`\n\nmaps the consent flow, refresh, and error cases onto eve. Any MCP server that supports OAuth can become a connector by its URL, which is how `mcp.linear.app`\n\nends up with the same scoped-token model as Slack or GitHub.\n\nThe same adapter wires a Slack channel. One `connectSlackCredentials`\n\ncall covers both directions: the bot credentials for sending and the webhook verification for receiving.\n\nThe two secrets a Slack integration usually keeps in your environment, `SLACK_BOT_TOKEN`\n\nand `SLACK_SIGNING_SECRET`\n\n, are gone from your app. There is nothing left to provision, store, or rotate.\n\nAn agent becomes more useful the more it can reach, which is exactly why access is the part to get right. Every system the agent can touch is a system someone could reach through a leaked token. With runtime credential exchange, nothing is provisioned for everything. Nothing is shared by every user. Nothing lasts forever. Nothing reaches past the task in front of it.\n\nCredential management used to be architecture. It was rotation scripts, secrets copied between environments, and bot tokens broad enough that you hoped no one leaked them. Now you store none of it. You request access the moment the agent needs it, scoped to the task.\n\n**Start building with Vercel Connect**\n\nRegister a connector, request your first runtime token, and connect an agent to Slack or GitHub without storing a provider secret.\n\nCoding agents just need a prompt:\n\n**What is Vercel Connect?**\n\nVercel Connect lets your agents and services access external systems on behalf of your users and teams. Instead of storing provider credentials in long-lived environment variables, you request user-authorized tokens at runtime with project-level access controls.\n\n**What problem does Vercel Connect solve?**\n\nIt removes long-lived third-party secrets from your runtime while still letting agents act on external APIs. You register a connector for a provider, link it to projects and environments, and request provider tokens at runtime.\n\n**When should I use Vercel Connect instead of Integrations?**\n\nUse [Vercel Integrations](https://vercel.com/docs/integrations) for marketplace-managed installs and provider-managed products in the Vercel Marketplace. Use Vercel Connect when you need delegated runtime credentials and user authorization for agent workflows, such as an agent that needs project-scoped access to a Slack workspace.\n\n**Which connectors are available?**\n\nVercel Connect supports generic OAuth and API key connectors, plus dedicated connectors for Slack, GitHub, Linear, Discord, Notion, Salesforce, Figma, and Snowflake. Resend, Workday, Microsoft Teams, and more are coming soon.\n\n**How does pricing work?**\n\nPricing is based on token requests. The Hobby plan includes 5K token requests per month at no additional cost. On Pro and Enterprise plans, token requests are billed at $3 per 10K token requests.\n\n**What are the current Beta limitations?**\n\nTrigger forwarding is limited to Slack, GitHub, and Linear, connector branding fields cannot be fully cleared after you set them, and token revocation, token lifetime, and scope granularity depend on provider support.", "url": "https://wpnews.pro/news/introducing-vercel-connect", "canonical_source": "https://vercel.com/blog/introducing-vercel-connect", "published_at": "2026-06-17 04:00:00+00:00", "updated_at": "2026-06-17 09:23:04.349578+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Vercel", "Vercel Connect", "GitHub", "Slack", "OIDC"], "alternates": {"html": "https://wpnews.pro/news/introducing-vercel-connect", "markdown": "https://wpnews.pro/news/introducing-vercel-connect.md", "text": "https://wpnews.pro/news/introducing-vercel-connect.txt", "jsonld": "https://wpnews.pro/news/introducing-vercel-connect.jsonld"}}