Runtime Credentials Replace Stored Secrets for Agents
Agents earn their keep by reaching beyond the codebase—posting to Slack, opening pull requests, querying Snowflake, calling internal APIs. That reach creates risk, because conventional credential management has meant minting a long-lived token and hoping it never leaks. Vercel Connect, now generally available, inverts the model: code requests a credential at runtime, scoped to the immediate task and expiring automatically.
During the public beta, the ecosystem grew past 100 connectors and gained governance features for production use. Managed connectors cover services like Slack, GitHub, Linear, and Salesforce; presets cover more than 100 additional providers including Notion, Shopify, and Workday. Custom OAuth and API Key authentication extend the same model to in-house services, and any OAuth-capable MCP server can act as a connector.
Vaults Never Solved the Real Problem
A secret stored in a vault is harder to steal, but once stolen it remains just as dangerous: it never expires, and no vault constrains what a leaked credential can do. The industry response has been rotation scripts, cross-environment secret copying, and shared tokens across users—credential management as its own full-time workload. Agents worsened the situation by touching more systems with more autonomy, while the containment tools stayed static.
Vercel Connect removes the stored secret from the application altogether. The workflow:
- Register a connector once for a provider (Slack, GitHub, Snowflake, Shopify, or your own OAuth service).
- Attach it to the specific projects and environments that need it.
- Request a token at runtime from application code; the SDK refreshes it automatically.
- The application contains no provider secret that could be committed by accident.
vercel connect create slack --name acme-slack
Create a Slack connector named acme-slack:
import { getToken } from '@vercel/connect';
const token = await getToken('slack/acme-slack', {
subject: { type: 'app' },
});
Requesting a token requires no secret of its own. Every deployment on Vercel carries an OIDC identity, and the SDK presents that identity to prove what is asking.
What Changes When Access Is a Request
The difference is visible in the properties of the credential itself:
Property | Stored token | Vercel Connect |
Lifetime | Never expires | Short-lived, refreshed automatically |
Reach | Everything the agent could need | Scoped to the task in the request |
Identity | One shared bot for every user | App or a specific named user |
Rotation | Mint, update copies, redeploy | None to perform |
Revocation | Rotate and redeploy | One command, per user or all tokens |
Credentials that previously sat in environments long after the task completed now expire independently. Scope is also assigned per request: one agent step might read a repository, the next open an issue, each asking for only what that step requires. The fineness of the grant depends on the provider; GitHub is the clearest example, where a request can restrict a token to read-only access on a single repository rather than trusting a standing organization-wide grant. The open-source GitHub Tools SDK uses this by exposing presets like code-review that mint tokens with only the necessary scopes.
Identity is likewise a per-request decision. Tokens act as the app by default, but the SDK accepts a named user as the subject parameter, and the token then operates on that user's behalf, limited to what they authorized in a one-time consent flow.
"Minting short-lived tokens instead of keeping provider credentials in paused sandboxes has removed a whole class of security risk for us."
![]()
Fraser Brown, BuildPass
Governance for Larger Teams
Beyond scoped tokens, production teams need control over who manages connectors and visibility into how access is used. The GA release adds fine-grained RBAC for connector creation and management, audit logs covering authorization and connector activity, and token and trigger observability across projects. Per-environment attachment and one-command revocation round out the governance story: when an auditor asks who had access and when, the answer is a log query rather than an investigation across projects and chat threads.
"Vercel Connect allowed us to quickly deploy new AI agents and channel integrations to our teams, while saving us the time and headache of rolling our own secure token management."
![]()
Pat Dunn, EF World Journeys USA
Reaching Agents Where They Run
The model extends beyond Vercel's own runtime. Custom Environments are supported, so a qa environment gets its own connector alongside production, preview, and development. eve supports Connect natively with connections declared per agent, and Chat SDK support brings the model to conversational applications.
Apps built in v0 follow the same path. Telling v0 which service the app needs causes it to set up the connector during the build, with no provider-side setup for Slack, GitHub, and other managed connectors. Because tokens are minted at runtime, the generated app has no secret to manage.
"v0 handles all the auth wiring with Connect, so instead of getting stuck managing API keys, I could just let anyone bring their own AI Gateway and KERNEL access via OAuth and start playing."
![]()
Danny Prevoznik, KERNEL
Inbound Events Without a Bot Secret
The token request is half of the connection; an agent also needs to receive events. Triggers handle the inbound path with no secret stored in the application. When a user posts in Slack, the provider sends the event to Vercel Connect, which verifies the signature server-side, re-attests the event with an OIDC identity, and forwards it to the project. Forwarded events arrive even with Deployment Protection enabled, and the application holds neither a bot token nor a webhook signing secret.
"We're using Connect in production today. Our internal legal agent handles Slack, Jira, and Google Drive through Connect, so we don't manage tokens, secrets, or event subscriptions ourselves."
![]()
Jorian Kalse, Moonpig Group
One Call Underneath It All
At the core sits getToken from the Vercel Connect SDK. Whether the agent is built on eve or the AI SDK, runs as a background job in Vercel Workflows, or is a hand-written loop, credential acquisition is the same call:
@vercel/connect/eveprovides credentials behind an agent's declared connections.@vercel/connect/chatintegrates Connect with Chat SDK adapters.@vercel/connect/betterauthand@vercel/connect/authjsgenerate provider configurations for Better Auth and Auth.js.@vercel/connect/ai-sdkand@vercel/connect/mcphandle the same integration for AI SDK tools and MCP clients.
For eve agents and Chat SDK applications specifically, the two secrets a Slack integration normally keeps in the environment—SLACK_BOT_TOKEN and SLACK_SIGNING_SECRET—are absent from the application entirely.
Availability and Pricing
Vercel Connect is available on all plans. Pricing is usage-based, tied to token requests and trigger events. The Hobby plan includes 500 token requests and 1,000 triggers per month at no charge. Pro plans bill at $3 per 1,000 token requests and $0.95 per 1,000 triggers; Enterprise customers receive custom pricing. Beta users keep their existing billing terms until September 25, 2026, when the updated pricing takes effect.



