Runtime credentials replace long-lived agent tokens
Agents are only as useful as the systems they can reach, and that reach has traditionally come with a heavy cost: long-lived provider tokens stored in environment variables. These tokens are typically shared across every user, never expire, and grant full access to everything the agent might ever need. A vault can make such a token harder to steal, but it does not reduce what is at risk when the token leaks.
Vercel Connect, now generally available, takes a different approach. Instead of storing a provider secret, you register a connector once. When your agent needs to act, your app proves its identity to Vercel Connect and receives a short-lived credential scoped to the specific task. The agent requests access each time it does work rather than holding onto permanent access.
One connector, many projects and environments
A connector is a reusable link between your Vercel team and a provider such as Slack or GitHub. You create it from the dashboard or the CLI, then attach it to the projects and environments that need it, with project-level access controls. The provider relationship becomes a single, visible entity rather than scattered copies across environment variable panels. Coding agents can handle the setup themselves: install the skill with npx skills add vercel/vercel-plugin --skill vercel-connect and they can create and attach connectors on your behalf.
vercel connect create slack --name mybot
Tokens are requested, not stored
With a connector in place, the agent asks for a credential only when it has work to do. The @vercel/connect SDK returns a token you use immediately against the provider API, and no provider secret lives in your app.
import { getToken } from '@vercel/connect';
const token = await getToken('slack/mybot', {
subject: { type: 'app' },
});
Tokens are short-lived, with a lifetime that depends on the provider. The SDK refreshes them automatically, so no manual secret rotation is required.
Identity is proven with OIDC
Your app's proof of identity is something it already has. Every deployment on Vercel gets an OIDC identity. When an app requests a token, the SDK presents that identity to Vercel Connect, which verifies it and checks that the project and environment are permitted to use the connector before returning the provider credential. The same identity is available during local development through vercel link and vercel env pull. Outside Vercel, the SDK accepts a Vercel access token as an alternative.
Scoping is per request, not per installation
Not every task needs the same reach, even within a single agent. Each request can specify provider scopes, an installation ID, resource restrictions, and provider-specific authorization details. GitHub demonstrates the sharpest granularity, allowing a token to be restricted to specific repositories and permissions.
import { getToken } from '@vercel/connect';
const token = await getToken('github/mybot', {
subject: { type: 'app' },
authorizationDetails: [
{
type: 'github_app_installation',
repositories: ['myorg/repo1'], // one repo, not the whole org
permissions: ['contents:read'], // read-only, not write
},
],
});
The deployment agent can read exactly one repository and nothing else. This limit exists for one request and one task. Least privilege becomes the shape of the request itself rather than a standing grant.
Act as a specific user
A shared bot token gives every request the same identity and reach. Vercel Connect lets you switch subject from the app to a named user, and the token then acts on that user's behalf, limited to what that user authorized. When a user first grants access, startAuthorization runs the consent flow through a callback URL, a webhook, or a device code.
import { getToken } from '@vercel/connect';
const token = await getToken('linear/mybot', {
subject: { type: 'user', id: 'user_123' },
});
Containment and revocation
Because a connector is attached to the projects and environments you choose, you can run a separate connector for development, preview, and production. A credential compromised in development cannot be replayed against production. If you need to pull back access already issued, you revoke the connector's tokens, either your own or all of them.
# Revoke just your own tokens for a connector
vercel connect revoke-tokens slack/mybot --my-tokens
# Or revoke every token, across all users and installations
vercel connect revoke-tokens slack/mybot --all-tokens
Revocation behavior 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. Shorter provider token lifetimes shrink that window.
Verified webhooks drive event-driven agents
Triggers let a connected service push events to your app. Vercel 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 verified webhooks to up to three of your projects.
- A user posts a message in Slack.
- Slack sends the event to Vercel Connect.
- Vercel Connect verifies the event against the Slack signing secret it holds, then forwards it to your Vercel app, re-attested with its OIDC identity.
- Your app verifies that attestation, then requests a scoped runtime token.
- The agent acts and responds.
The Slack signing secret moves server-side to Vercel Connect. Your app holds no bot token to act with and no signing secret to verify against.
Adapters across your stack
Underneath is one call: getToken. Around it are adapters for your existing framework. Better Auth (@vercel/connect/betterauth) and Auth.js (@vercel/connect/authjs) receive provider configs in the shape they expect, while @vercel/connect/ai-sdk and @vercel/connect/mcp do the same for AI SDK tools and MCP clients. A Nuxt starter gives you a working app with GitHub and Linear connected, no provider secret, and no OAuth refresh token stored in its database.
In eve, the open-source agent framework by Vercel, a connection is one declarative file, and the @vercel/connect/eve adapter supplies that connection's credential.
import { defineMcpClientConnection } from "eve/connections";
import { connect } from "@vercel/connect/eve";
export default defineMcpClientConnection({
url: "https://mcp.linear.app/sse",
auth: connect("linear/mybot"),
});
There is no token handling in the agent's code, because connect maps the consent flow, refresh, and error cases onto eve. Any MCP server that supports OAuth can become a connector by its URL. The same adapter wires a Slack channel with one connectSlackCredentials call, covering both bot credentials for sending and webhook verification for receiving.
import { slackRoute } from "eve/channels/slack";
import { connectSlackCredentials } from "@vercel/connect/eve";
export default slackRoute({
credentials: connectSlackCredentials("slack/mybot"),
});
The two secrets a Slack integration usually keeps in your environment, SLACK_BOT_TOKEN and SLACK_SIGNING_SECRET, are gone from your app.
What is available now
Vercel Connect supports generic OAuth and API key connectors, plus managed connectors for Slack, GitHub, and Linear, along with 100+ preset connectors including Notion, Shopify, Resend, Sanity, and Workday. Pricing 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.
Current beta limitations: trigger 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.
Coding agents can get started with a prompt:
Set up Vercel Connect in this app so it can post to Slack without storing a Slack token. Install the vercel-connect skill with `npx skills add vercel/vercel-plugin --skill vercel-connect` and follow it. Read vercel.com/docs/connect.md for anything the skill does not cover. Link the project (`vercel link`) and pull a local OIDC token (`vercel env pull`), create a Slack connector with `vercel connect create slack --name mybot`, and attach it to this project. Then install @vercel/connect and request a token at runtime with getToken('slack/mybot', { subject: { type: 'app' } }). Use the token to post a test message to a channel I choose. Verify with the project's typecheck, and do not commit unless I ask.
