Vercel launched Connect in public beta on June 18, replacing the long-lived API tokens that most agent deployments store in environment variables with runtime credential exchange that generates a short-lived credential at the moment of each task.
The problem Connect solves is structural. When an agent holds a stored Slack or GitHub token, that token typically carries full access to everything the bot was provisioned for, shared across every user and every task, with no expiry. A vault protects it in storage. It does nothing for the blast radius if that token leaks in production. Every system the token can touch becomes reachable by whoever has it.
Vercel’s answer is a connector model. A developer registers a connector once, linking their Vercel team to a provider like Slack, GitHub, or Linear. When the agent has work to do, the app calls the @vercel/connect SDK’s getToken, which presents the deployment’s OIDC identity to Vercel Connect. The platform verifies the project and environment are authorized, then returns a short-lived provider credential. The provider secret never lives inside the application.
The scoping is the meaningful part. A single agent handling multiple steps can request different permissions at each step, restricting a GitHub token to one repository and read-only access for one call, then requesting issue-write access for the next. Vercel’s documentation uses a GitHub App installation as the sharpest example: a standing installation is a broad, persistent grant; a Connect token exists for one request, one task. Least privilege becomes the shape of the request rather than something an administrator has to configure separately.
The security stake is higher for teams running autonomous agents than for traditional API integrations. A conventional web app calls an API synchronously, in a defined flow, on behalf of a human who just initiated something. An autonomous agent operates across extended task sequences, sometimes in parallel, often with broader tool access than any single action requires. A leaked bot token in that context is not a credential compromise in one service; it is a pivot point across every service the agent was provisioned to reach. Runtime credential exchange with per-task scope limits the window and the surface area simultaneously.
Vercel Connect also handles the inbound direction. Trigger forwarding (currently in beta for Slack, GitHub, and Linear) routes verified provider webhooks to the application, re-attesting them with an OIDC identity the app can verify. The Slack signing secret moves server-side to Vercel Connect rather than sitting in the application’s environment.
Token revocation works at the connector level: one command pulls back all issued tokens, or only the caller’s own. The release announcement notes an honest limit: where a provider does not support a revocation API, Connect stops issuing new tokens but cannot recall already-issued ones. Shorter token lifetimes on those providers reduce the exposure window.
Pricing is based on token requests. The Hobby tier includes 5,000 requests per month at no additional cost; Pro and Enterprise plans add $3 per 10,000 requests beyond that. Connectors for Slack, GitHub, Linear, Discord, Notion, Salesforce, Figma, and Snowflake are available today, with Microsoft Teams and others listed as coming soon.
For teams already building agent workflows on Vercel, this changes the default architecture for credential handling. Any agent that currently stores a bot token in process.env and relies on scope restrictions at the provider level should be reviewed against Connect’s per-request scoping model before those agents take on broader autonomous tasks.
Source: Vercel blog, published June 18, 2026, authored by Hedi Zandi.
