When I first looked at Vercel
Connect, a doubt stuck with me for a long time. Vercel Connect is a
feature released by Vercel in June 2026 for agents running on Vercel.
When an agent calls external services like Slack, GitHub, or Notion,
instead of stuffing a perpetual, full-access token into environment
variables, it calls getToken() at the exact moment it needs
to invoke an API to obtain a short-lived credential that is scoped only
for that specific task.
A doubt immediately crossed my mind: getToken itself
requires authentication—what does it use to prove it is eligible to
receive this short-lived credential? If the authentication itself uses
something long-lived and perpetual, once leaked, how is it any different
from leaking my original full-access token? Short-lived credentials can
be revoked, but original full-access tokens can also be revoked. What
does this feature actually improve over the old way?
Understanding this question requires looking at the standard OAuth workflow first. Usually, when an application integrates a third-party service, completing the authorization yields two things: a short-lived access token used to call APIs, and a long-lived refresh token used to obtain a new access token once the access token expires. The refresh token is the real key—it isn’t used frequently in daily ops, but as long as it exists, it can repeatedly exchange for new access tokens. The common practice is storing the refresh token in the application’s own environment variables or database, pulling it out whenever a token swap is needed.
The first step Vercel Connect takes is removing the refresh token
from the application’s environment variables. After completing the
authorization flow, the refresh token is stored on Vercel’s
infrastructure, completely inaccessible to application code. Application
code can only call getToken(), whereupon Vercel Connect
uses the refresh token to fetch a short-lived access token for the
application, which expires right after use. getToken’s own
authentication relies on the Vercel deployment’s OIDC token. It is
short-lived (expiring in about 12 hours in local development, and
automatically injected and rotated in production), bound to a specific
project and environment. It proves which Vercel project this code
belongs to, not that it holds Slack permissions. Connect uses this
identity to look up the project link, verifies whether the project is
authorized to use this connector and whether the environment is on the
allowlist, and only issues the access token after passing these
checks.
The dangerous, long-lived refresh token disappears from the application environment. A sentence in Vercel’s official documentation hits the nail on the head regarding this difference: “A vault makes that token harder to steal. It doesn’t make it less dangerous.” They didn’t put a vault around the token; they made the dangerous asset never appear in the application code in the first place.
At this point, I thought the line of questioning had ended. Credentials moved away, no long-lived assets left in the application code—the problem seemed solved. But pushing one step further along this line, things are not so simple.
What if an attacker steals this OIDC token? Before the OIDC token expires, if an attacker uses it to request a short-lived access token from Connect, Connect will issue it just the same. On this dimension, once credentials leak, there is no fundamental difference between the new and old models. The consequences of an attacker acquiring an access token within the valid credential window are identical. Under the traditional model, if a refresh token leak is discovered, authorization can likewise be revoked on the provider side.
Then we can only look at scope. Connect allows passing a scope
parameter on every getToken() call, restricting the
acquired access token to just what is needed for the task at hand—surely
this must be its technical innovation?
Looking closely at the OAuth protocol reveals that this is still not
the case. How broad an access token a refresh token can exchange for is
fixed the moment the user consents to OAuth authorization. When
developers integrate OAuth themselves, they can fully configure narrow
scopes; for example, GitHub fine-grained tokens can similarly be
restricted to read-only access for a single repository. Connect merely
exposes scope as an optional parameter on each getToken()
call—it doesn’t magically narrow permissions on its own. If both sides
configure the same narrow scope, storing the refresh token yourself
versus having Connect store it for you carries no fundamental difference
in blast radius after a credential leak.
Only by digging this far do we see Connect’s true focal point. It hasn’t made applications inherently more secure—scopes still require manual configuration, and security best practices cannot be skipped in the slightest. Its real value is consolidating credential requests from all providers into a single egress point, selling centralized management.
This follows the exact same pattern as OpenRouter aggregating model access. OpenRouter doesn’t make model invocations any smarter; it allows developers to maintain only a single API endpoint. Connect is to OAuth integration what OpenRouter is to model APIs. It doesn’t save the effort of security evaluation; it saves the effort of plumbing integrations, at the cost of needing to learn an extra layer of abstraction concepts like project link, environment, and authorizationDetails.
With this framework clarified, the moves of over a dozen companies in 2026 gain a unified interpretation. Not a single one of them is inventing new cryptographic mechanisms; they are competing for who gets to host, who gets to keep the audit logs, and who gets to set boundaries. Ownership is contested because whoever occupies the gateway locks in future migration costs. This is an innovation in business model, not engineering practice.
After clarifying this gateway framework, following the moves of these companies led me to an even more unexpected structure: the shape of authorization has changed. Previously, when building agents, we were used to treating authorization as a static checkpoint happening in an instant. The moment an agent invoked an external API, the gateway or MCP validated identity once, allowed passage, and was done. The instant validation occurred, data reading finished, artifacts were generated, and the authorization act was declared over. Where the data went afterward, who could see it, or when it should be revoked were not tracked at the time.
However, tracing through the wave of company moves in 2026, I found that authorization has extended from a point in the past into a full lifecycle line advancing alongside the physical actions of the agent at work: first acquiring credentials, then invoking APIs, having the retrieved data land in workspaces or artifacts, subsequently sharing, exporting, or handing off these artifacts to other agents, and finally needing to support revocation. Every single link has become a checkpoint that can be individually guarded and audited. Mapping these companies’ solutions onto this line, I realized each vendor actually occupies only a single segment.
Looking at these two products side by side, the difference in the
specific objects managed across segments is crystal clear. Vercel
Connect manages the credentials themselves: when a token is minted, how
narrow its scope is, when it is revoked, and who requested it; the
Observability tab updated on August 11, 2026, serves as the audit log
for this exact stage. Cloudflare OS, open-sourced on
August 5, 2026, manages the data retrieved by those credentials: every
time an agent reads an external data source, it must call
authorizeObservation() to report the data source ID and
required permissions to the kernel, which Overseer persists in an
inventory list; if a peer tries to open or share this workspace, their
identity is used to re-validate each data source on the list
individually, blocking access if permissions are lacking. A sentence
from Cloudflare officially hits the nail on the head regarding the
difference between these two segments: MCP tells you “which tools an
agent is allowed to invoke. It does not tell you which rows, files, or
repositories the agent actually read”. One records credential lifetimes
and invocation actions; the other records data provenance and
post-sharing access permissions. Along the same line, different segments
manage different objects.
Looking further down this line, other segments are occupied by other players as well. GitHub Copilot guards entry admission: its MCP allowlist restricts developers to servers in the enterprise registry, directly blocking any runtime not on the list, with audit logs recording configuration changes while explicitly omitting specific session and tool call details. Microsoft and Google occupy the identity segment, assigning independent non-human identities to agents (Entra Agent ID or Google Cloud Agent Identity based on SPIFFE), plugging them into existing Conditional Access and audit systems respectively—traversing the line, yet landing strictly before invocation occurs. Each vendor occupies only one segment; none manages end-to-end from start to finish.
When mapping out the timeline, I noticed that these actions happening in sync was no coincidence. From March to August 2026, five major platforms plus a line of IAM vendors densely released agent-oriented credential and authorization capabilities over a five-month span. In just the first two weeks of August alone, Cloudflare open-sourcing OS, GitHub adding agent activity metrics, and Vercel adding Observability landed right on top of each other. Though starting from different entry points, their focal points all land on different segments of the same lifecycle line. This status quo of each vendor managing only one segment leads directly to an even deeper question.
Seeing that each vendor only occupies one segment, thinking further down this line brought me to a deeper divergence. Rather than which specific segment to manage, what truly dictates architectural direction is who should be entrusted with storing the credentials capable of directly operating internal systems. Tracing these companies’ solutions, I found they clearly divide into two poles: one faction chooses to hand them to the platform, while the other chooses to keep them in their own hands.
For the platform-hosted faction, Vercel Connect and Anthropic’s Claude Tag are prime examples. Vercel stores refresh tokens on its own infrastructure, with audit logs residing in the Observability tab, delegating long-term retention to Drain forwarding to SIEM. Anthropic released Claude Tag in June 2026, granting agents a dedicated identity where credentials are bound to identity, revocation relies on disabling identity, and all actions are logged under that identity. The shared logic of both is: developers trust the platform to safeguard dangerous credentials in exchange for convenience and out-of-the-box tooling.
Following this faction down, I found the core value it sells leans toward centralized management rather than stronger security, since scope still requires manual configuration by developers. What it sells is centralized management, reducing the plumbing effort from N sets down to 1. Yet this is precisely the entry point for lock-in: once the middleman becomes the sole ingress/egress for N integrations, migration costs jump from 1 to N, requiring reconnecting OAuth across N providers and rebuilding audit pipelines. Lock-in is the engine of this business model, not an unintended side effect. The deeper an application leverages it, the higher the migration barrier grows.
When I saw OpenAI announce its acquisition of Ona, I saw a completely different solution altogether. On June 11, 2026, OpenAI announced it would acquire Ona. Ona’s pattern is customer-controlled execution: agents run within the customer’s own cloud environment, keeping credentials, data, and audit logs entirely on the customer side, while OpenAI supplies only intelligence and orchestration. In its acquisition announcement, OpenAI listed a string of elements enterprises need to control: “where they run, what they can access, how credentials are scoped, how activity is logged, and how work moves through review”. The answer to every single item falls within the customer’s boundaries. This route bets on the assumption that regulated enterprises will never hand credentials capable of directly operating systems over to third-party platforms.
Cloudflare OS occupies a more subtle position. It is an open-source project, allowing developers to self-host, keeping credentials and audits theoretically inside their own infrastructure. However, inspecting its underlying architecture reveals that its Gatekeeper, Overseer, and sandboxes are built on Cloudflare Workers and Durable Objects, running by default on Cloudflare’s platform. An independent article criticized this exact point: “the architecture that trusts no one rests entirely on trusting the one party that poured the ground beneath it” (source). Though the mechanism is open source, unless fully self-hosted, the foundation of trust remains built on Cloudflare’s underlying services.
Comparing these two routes side by side makes it clear that their trade-offs center on whether one is willing to swap lock-in for convenience, rather than which side has safer cryptography. The platform-hosted faction trades away credential custody and accepts N-fold migration cost in exchange for dropping management overhead from N to 1; the customer-boundary faction keeps control and compliance boundaries in its own hands at the cost of building execution environments, maintaining audit pipelines, and writing N sets of OAuth integrations themselves. This polarized architectural opposition manifests even more clearly when summarizing their underlying beliefs next.
Looking at these companies’ moves together, I realized that behind them lie four core beliefs. Each belief defines a yardstick: whatever it believes in dictates where it spends effort; following its design downstream reveals the blind spots it leaves behind.
The first line of thinking believes managing credentials well is enough; Vercel Connect and the MCP authorization specification belong to this category. It believes security risks stem primarily from long-lived full-access tokens, and that switching to short-lived scoped tokens, runtime exchange, and audit logs will solve the problem. All its effort is spent on token minting, scoping, revocation, and event logging. However, I observed that its blind spot lies in the stages after credentials are used: when data retrieved via tokens lands in workspaces, gets shared, or is exported, this mechanism no longer intervenes. Vercel itself acknowledges this boundary: whether revocation takes effect immediately depends on whether the provider offers a revocation API; without such an API, issued tokens remain valid on the provider side until natural expiration. Managing the credential stage well does not mean the data stage gains security guarantees.
The second line of thinking believes managing credentials is still not enough—data destination must be controlled; Cloudflare OS belongs to this category. It believes true leaks happen after data is read: an agent reads a sensitive data table, generates a dashboard, and sends it to an unauthorized colleague; at that moment, credential validation passed long ago, leaving front-end gates powerless to intercept. Its effort concentrates on observation recording and post-sharing access validation. Yet examining its architecture reveals its blind spot in credential minting and scope configuration itself: it relies on existing MCP or API gateways to guard entry prior to invocation without touching the credential lifecycle itself. Furthermore, complete reporting relies on accurate driver implementations; the kernel cannot strictly guarantee that edge paths like pagination, sub-sessions, or caching are leak-free. While the data stage is controlled, the credential and egress stages remain the responsibility of other systems.
The third line of thinking believes the core issue is where management happens, not what is managed; OpenAI announcing the acquisition of Ona belongs to this category. It believes specific details of credentials, data, and audit logs are not the deciding factor—the key is whose boundary these assets physically reside within. Agents run in the customer’s cloud, credentials stay customer-side, audit logs remain customer-side, and the platform supplies only intelligence services. Its effort concentrates on ownership of the execution environment. Pushing through actual implementation, however, I found its blind spot is requiring customers to build execution environments and audit pipelines themselves, creating significantly higher implementation friction than platform-hosted solutions. Moreover, the Ona acquisition has not formally closed, so corresponding capabilities are not yet fully deployed.
The fourth line of thinking believes the core issue is that agents lack an independent identity; Anthropic’s Claude Tag, Microsoft’s Entra Agent ID, and Google Cloud Agent Identity based on SPIFFE belong to this category. It believes that as long as agents are granted first-class identity status, existing IAM, Conditional Access, and auditing infrastructure will smoothly extend to cover them. Its effort concentrates on bringing agents into existing identity infrastructure. But I noted its blind spot: while identity clarifies who the agent belongs to, it cannot directly solve which specific data the agent read on whose behalf, nor can it track where data flows after being read. Identity serves as a baseline anchor traversing the entire line, but having an anchor is not equivalent to guarding every single link along that line.
These four beliefs are not mutually exclusive; looking across the landscape, no single vendor today can cover the full lifecycle based on a single belief alone. Vercel manages credentials but not data flow; Cloudflare manages data flow but not credential minting; Ona emphasizes ownership, but its mechanism maturity will take time; the identity faction defines actors but cannot comprehensively govern behavior. This pattern of each player occupying one corner precisely demonstrates that the entire field remains in a very early jigsaw puzzle phase.
After dissecting these solutions, the most obvious gap is that the credential line and data line have not been integrated together to this day. Vercel Connect can record when tokens are requested, what scopes are assigned, and when they are revoked, but it cannot trace which sensitive sources the retrieved data touches once in a workspace, nor can it perceive who still retains viewing permissions when artifacts are shared with others. Cloudflare OS can record which data sources an agent has read and re-validate permissions upon sharing, but it cannot report how invocation credentials were minted, how narrow their scope constraints were, or where authorization originated. One handles credentials, the other handles data, operating independently; no single solution yet answers completely on whose behalf the agent acted, what credentials it used, what content it read, and to whom it delivered the results afterward. Furthermore, Cloudflare OS itself points out that a unified egress inspection mechanism is not yet complete, and the checkpoint for outbound requests after data reading finishes still needs to be added.
The second gap lies in cross-boundary trust mechanisms. The platform-hosted faction retains audit logs on the platform side; for long-term retention, data must be pulled into one’s own SIEM, but before pulling, the data remains under platform control. The customer-boundary faction keeps logs on the customer side, but Ona has not completed its closing, and the technical barrier to self-hosting Cloudflare OS remains relatively high. Currently, no product smoothly solves the challenge of trust flowing across platform and customer boundaries.
Facing these unresolved gaps, when doing architectural selection, we really only need to draw our boundaries along two core axes. First: which stage of the lifecycle line needs to be controlled? If an agent is merely used to invoke APIs without involving artifact persistence or sharing, focusing on the credential stage alone may already be sufficient, making Vercel Connect or the MCP specification layer appropriate focal points. If the agent reads sensitive data, generates analytical dashboards, and shares them with colleagues, relying solely on the credential stage is clearly inadequate; the observation reporting and post-sharing re-validation used by Cloudflare OS are the exact directions that need evaluation.
Second: where do you want to place your trust? If you accept hosting credentials on a platform in exchange for development convenience, Vercel and Anthropic offer turn-key infrastructure. If you operate in a strictly regulated industry where credentials cannot leave your boundaries, you need to consider the customer-boundary route represented by Ona, or opt to self-host Cloudflare OS.
How far to control and where to place trust are the two genuinely important selection axes in this domain. Memorizing a dozen product names offers no real help; grasping these two axes allows quickly positioning any newly emerging architectural scheme. And the current industry reality is: no single player is yet capable of fully covering both axes.
Digging to this point, I can offer a concluding thought: not a single one of these products makes systems inherently more secure; the change they bring is making management more centralized. Gateway aggregation is the core value they sell, lock-in is the accompanying cost, and “more secure” is merely a narrative at the marketing level. Being able to clearly distinguish these three points ensures we won’t easily follow any vendor’s marketing narrative when making architectural choices.