Stop Giving Agents Passwords: Credential Exchange as the Next Containment Primitive

TV
Thiago Victorino
6 min read
Stop Giving Agents Passwords: Credential Exchange as the Next Containment Primitive

Most agents in production today carry a working password. A GitHub token, a Slack bot secret, a Salesforce key, sitting in an environment variable or a secrets manager, available to every code path the agent runs. We argued in the network-as-sandbox essay that the fix is to keep the credential off the agent entirely. Vercel shipped a product this week that does exactly that for third-party connectors, and it puts a name on the mechanism: credential exchange.

Vercel Connect, announced June 2026, replaces stored long-lived tokens with short-lived, task-scoped credentials issued at execution time. Per Vercel’s announcement, the agent requests access when it needs it, the request is verified through OIDC, and the credential it receives is scoped to the task and expires fast. There is no standing secret in the runtime to steal.

What “Store the Secret Safely” Was Always Missing

The industry spent a decade getting good at protecting stored secrets. Vaults, rotation, encryption at rest, fine-grained access policies on the vault itself. All of it answers one question: how do we keep this token from being read by the wrong process?

Vercel’s framing names the flaw in that question directly. “A vault makes that token harder to steal. It doesn’t make it less dangerous.” A vaulted token is still a token. When the agent pulls it into memory to make a call, it is a plaintext credential in a runtime you do not fully trust. Prompt injection that convinces the agent to exfiltrate its environment finds a real key. A malicious dependency scraping the process for tokens finds a real key. The vault protected the secret at rest and handed it over the moment it was used.

The standing token is also over-scoped by construction. You provision it once, for the broadest set of operations the agent might ever need, because re-provisioning per task was operationally painful. So the agent that should only post to one Slack channel holds a token that can read every channel, because that is the token you minted six months ago.

Credential Exchange Inverts the Question

Connect changes what the agent holds. Instead of a stored token, the agent holds an identity and a way to ask. When it needs to act, it requests a credential at runtime. The request is verified through OIDC, which means the system issuing the credential cryptographically confirms which workload is asking before it grants anything. The credential that comes back is scoped to the task and short-lived.

Vercel puts the shift in one line: “Access becomes something you request, scoped to the task.” That sentence carries the whole design. Access stops being a property the agent owns and becomes an action it performs, checked each time, narrowed each time.

Walk through what that does to the threat model. An attacker who fully compromises the agent runtime now finds an identity and a request mechanism, not a usable secret. To do damage they have to ask for a credential, and the request is OIDC-verified and scoped, so what they can obtain is bounded by what the legitimate task was allowed to do. The credential they manage to pull expires before it travels far. Lateral movement, the part of an incident where a single stolen key opens nine other systems, loses its fuel. There is no long-lived, broadly-scoped token to carry sideways.

This is least privilege made real instead of aspirational. Per-request scoping means the agent gets exactly the access the current task needs, not the union of everything it might ever need. The blast radius of a compromise shrinks to one task window.

The Governance Surface Comes Free

The piece platform teams should notice is what credential exchange gives you beyond security. When access is requested rather than stored, every grant flows through one issuing point, and that point can do four things a vaulted token cannot.

It can enforce per-user consent, so a human authorizes the connection and the agent acts under that person’s grant rather than a shared service account nobody owns. It can revoke, instantly, by refusing to issue the next credential, with no token already loose in the wild to chase down. It can produce an audit trail of who requested what access for which task, because every grant was an event at the issuing point. And it can scope per request, which is the least-privilege property above.

Consent, revocation, audit, and scoping are exactly the controls a compliance team asks for and a stored token cannot provide. A long-lived secret has no consent step, revoking it means rotation and redeployment, and it generates no record of use because using it is just a local read. Credential exchange produces those controls as a side effect of how it works, not as bolted-on logging.

Connect launches with connectors for Slack, GitHub, Linear, Discord, Notion, Salesforce, Figma, and Snowflake, with Resend, Workday, and Microsoft Teams listed as coming. Pricing puts the Hobby tier at 5,000 token requests per month free, and Pro and Enterprise at three dollars per ten thousand token requests. The pricing detail is worth reading as a design signal: charging per token request means the model assumes many small, frequent, ephemeral grants rather than a few standing secrets. The architecture expects access to be a high-frequency action.

Where This Sits in the Containment Stack

This is one product from one vendor, and it covers third-party SaaS connectors, not every credential an agent touches. A database password, a cloud IAM role, an internal service token still need their own answer. The vendor convergence we tracked in May showed the same move arriving across the field; Connect is the SaaS-connector instance of it, now with consent and audit attached and a price list.

Treat it as a pattern that shipped, not a proven outcome. There is no efficacy data here, only a design. But the design is the right one, and it is now buyable for a defined set of connectors. The primitive it adds to the stack is concrete: runtime credential exchange, replacing the stored secret with a scoped, verified, expiring grant requested at the moment of use.

Do This Now

Inventory the long-lived tokens your agents hold for third-party services. For each one, ask what it could do if read out of the runtime right now, and whether the agent needs that full scope for every task or just held it because re-scoping was annoying. Every token that answers “full scope, rarely all needed” is a candidate to replace with an exchanged credential.

For the connectors Connect already supports, the swap is available today: stop storing the token, hold an identity, request a scoped credential per task, and let the issuing point carry consent, revocation, and audit. For the credentials it does not cover yet, adopt the same shape anyway. The question to bring to your next architecture review is simple. For each secret an agent holds, is it stored, or is it requested? Everything stored is a key an attacker can steal. Everything requested is a key that was never there to take.


This analysis synthesizes Introducing Vercel Connect (Vercel, June 2026).

Victorino Group helps teams design agent identity and containment that holds in production. Let’s talk.

All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →

If this resonates, let's talk

We help companies implement AI without losing control.

Schedule a Conversation