Vercel has launched Connect in public beta, a product designed to replace the long-lived provider tokens many apps use today to give agents access to external services. The company says the new approach is meant to reduce risk by issuing short-lived credentials at runtime instead of storing a single powerful secret in environment variables.
The release is aimed at applications built around agents that need to work across multiple systems such as Slack, GitHub, Linear, and Snowflake. Vercel argues that the traditional model of keeping a provider token on hand for every possible task is too broad. If that token is exposed, the credentials can unlock everything it has access to, even if the original job was narrow in scope.
With Connect, developers register a connector once and then reuse it across projects and environments. When an agent needs to act, the app proves its identity to Vercel Connect and receives a temporary token tied to the task. Vercel says the agent no longer holds a permanent provider secret, but still gets access to the service when needed.
Vercel Connect uses a credential exchange model rather than static storage. According to the company, developers can create connectors from the dashboard or via the CLI, then attach them to the projects and environments that need access. Each connector is managed as a single relationship between a Vercel team and a provider, which Vercel says should make it easier to track and rotate access than searching through multiple environment variable settings.
The product also includes support for an SDK, @vercel/connect, which requests a token only when the application needs to perform work. Vercel says those credentials are short-lived and refreshed automatically, depending on the provider. The company presents this as a way to avoid manual secret rotation and to reduce the chance that a token is copied between environments or checked into code.
Vercel says the app proves its identity through OIDC. Every deployment on the platform gets an OIDC identity, and the SDK presents that identity when it requests a token. Vercel Connect then checks whether the project and environment are allowed to use the connector before returning the credential. The same identity can be used in local development through vercel link and vercel env pull. Outside Vercel, the SDK can use a Vercel access token.
The company is also emphasizing finer-grained access controls. Token requests can include provider scopes, installation IDs, resource restrictions, and other provider-specific authorization details. Vercel says this is especially useful for GitHub, where access can be limited to a specific repository and a specific permission level rather than an entire organization.
In the examples shared by Vercel, a request can be scoped so that an agent can read from one repository but not write to it, or interact with only the resources required for a single step in a workflow. The company says that approach is meant to align permissions more closely with the work being performed.
Vercel Connect is now available in public beta. The launch positions it as an infrastructure layer for agent-driven apps that need authenticated access to third-party tools without relying on permanent provider secrets stored in the application itself.