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.

Connect to 100+ services through secure, scoped tokens

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.

Connect to 100+ services through secure, scoped tokens

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/eve provides credentials behind an agent's declared connections.
  • @vercel/connect/chat integrates Connect with Chat SDK adapters.
  • @vercel/connect/betterauth and @vercel/connect/authjs generate provider configurations for Better Auth and Auth.js.
  • @vercel/connect/ai-sdk and @vercel/connect/mcp handle 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.