Vercel Connect GA: agents borrow credentials, not keep them

Every AI agent you run needs to touch something it doesn't own — your GitHub, your Slack, your CRM. For years the only answer was a long-lived token pasted into an environment variable, scoped far wider than the job required, valid until someone remembered to rotate it. Vercel Connect went generally available on August 25 with a different answer: the agent asks for a credential at the moment it needs one, gets a narrow one, and the credential expires on its own. The product is Vercel's. The pattern is yours to steal.

What actually happened

Vercel announced that Connect is out of public beta and generally available across all plans. The mechanism: every Vercel deployment already carries an OIDC identity, so code running there can prove what it is without holding a secret. It trades that identity for a short-lived access token, scoped to the task, that refreshes and expires without anyone managing it.

The scoping is the interesting part. A GitHub token can be issued read-only against a single repository rather than as an org-wide PAT. Access can be attached to a per-user identity through a consent flow instead of one shared bot account that every action gets attributed to. That turns an audit log from "the integration did it" into "this person's session did it."

Connect ships with over 100 preset connectors — managed integrations for Slack, GitHub, Linear, and Salesforce, plus services including Notion, Shopify, and Workday — with custom OAuth and API-key auth for anything proprietary. Governance is RBAC over who can create connectors, audit logs on authorization and connector activity, per-environment attachment, and single-command revocation.

Pricing, per Vercel's post: Hobby includes 500 token requests and 1,000 triggers per month. Pro is $3 per 1,000 token requests and $0.95 per 1,000 triggers. Enterprise is custom. Beta users keep their existing terms until September 25, 2026.

Why short-lived credentials matter for your business

Go look at your .env files and your CI secrets right now. We do this with clients and the result is consistent: a handful of tokens nobody can date, issued by someone who has since left, scoped to an entire workspace because that was the fast path on a Friday.

That was a manageable problem when three services shared four keys. It stops being manageable the moment you run agents, because an agent's whole value is that it touches more systems, more often, with less supervision. A leaked static token is a standing invitation with no expiry. A leaked 15-minute token scoped to one read-only repo is a bad afternoon.

You do not need Vercel to get this. The pattern has three parts and every one of them is available on infrastructure you already run:

Identity instead of secrets. Your workload proves who it is — OIDC from your CI provider, an IAM role, a workload identity — and exchanges that for a token. Nothing long-lived sits on disk.

Scope per task, not per integration. Ask what this specific job needs. One repo. Read-only. One channel. Issue that.

Expiry as the default, not the cleanup task. If revocation depends on somebody remembering, it doesn't happen.

The reason to note the GA is that the tooling for this finally exists at small-team scale. The reason to be careful is the obvious one: a credential broker is a single point of trust, and the pricing above is now a line item that scales with how chatty your agents are. Meter it before you wire fifty connectors into a loop.

Sources: Vercel.