What AI Agents Actually Deploy: Vercel's Ship 2026 Numbers and the PaaS Defaults They Break

Six months before Vercel Ship 2026, fewer than 3% of deployments to Vercel's infrastructure were triggered by coding agents. By the time Guillermo Rauch took the stage in London in June, agents accounted for more than half. Over the same six months, monthly token volume through Vercel's AI Gateway grew tenfold, from roughly two trillion to twenty trillion.

A month later Rauch told TechCrunch the platform was seeing 6 million deployments a day — half of them agent-triggered — with more than a trillion tokens a day flowing through the gateway.

Read those numbers together and they say something more specific than "agents write a lot of code now." The deployment count and the inference count moved together: what agents deploy is disproportionately software that calls a model at runtime. "We are deploying software that can think," as Rauch put it in the keynote. The wave of agent-triggered deployments is not more deployments of the same CRUD apps humans always shipped — it is a workload-composition shift toward AI-native apps with a third-party inference API on their critical path.

That shift breaks PaaS defaults that were designed around the human-deployed CRUD profile: open outbound egress, API keys in plaintext env vars, and a cost model of compute plus bandwidth plus storage. Vercel's own product response at Ship — a model gateway, short-lived task-scoped credentials, agent identity — is the tell for which defaults had to move. This post names the three that matter most for anyone running a self-hosted platform, with the caveats for where the old defaults still hold, and ends with a scorecard you can apply to your own fleet.

What an agent-built app looks like at runtime​

The old default app — the shape every PaaS default was tuned for — receives an inbound request, queries a local database, and returns HTML or JSON. Its risk surface is inbound: TLS termination, request auth, rate limits. Its outbound traffic is an afterthought: a webhook here, an SMTP relay there.

The inference-calling app inverts that. Its defining runtime behavior is outbound: streaming HTTPS calls to a third-party model endpoint, often long-lived, with spend metered in tokens rather than bytes and availability chained to a provider the platform does not control. Failures look different too — a deploy that passed every check still breaks at runtime when a provider rate-limits, deprecates a model string, or has an incident of its own.

Three scope notes before going further, because Vercel's aggregate is not universal and your fleet's mix decides which rows below apply to you:

• External-inference apps are the branch this post is about: tenants calling OpenAI-, Anthropic-, or gateway-style APIs over the public internet. This is where Vercel's numbers bite.
• Local-model apps keep inference on infrastructure the platform controls — a GPU node pool serving tenants' agents. The traffic stays internal, so the egress default below mostly does not apply, but secrets and metering still do.
• Agent-deployed plain CRUD is real and common: an agent scaffolds a marketing site or an internal dashboard that never calls a model. Old defaults handle it fine. The mistake is assuming it is still the only shape and tuning every default for it.

With those branches named: if any meaningful share of your tenants looks like the first branch, three defaults need to move.

Default #1: inference egress becomes first-class​

The CRUD-era default for outbound traffic is "allow everything, meter barely anything." Egress allowlisting exists in most platforms as an enterprise compliance feature, not a day-one primitive, because outbound calls were rare and cheap.

Inference traffic breaks the assumptions behind that default. It is voluminous (trillions of tokens a month on one platform alone), it is spend-bearing (every call burns metered provider budget), and it is a security boundary (a compromised app exfiltrating via a model API looks like normal traffic unless the platform can distinguish it). Vercel productized exactly this realization as AI Gateway: one endpoint across hundreds of models with automatic failover when a provider goes down — egress to inference treated as platform-managed infrastructure rather than each app's private business.

For a self-hosted PaaS, the egress checklist is:

• An allowlist-friendly outbound posture. Tenants should be able to declare which inference endpoints their app may reach, so a compromised dependency cannot quietly redirect calls — or leak prompt data — to an attacker's endpoint. Default-open with no per-app egress story is the posture that makes prompt-data exfiltration invisible.
• A per-tenant gateway chokepoint with failover. Routing tenant inference calls through a platform-managed proxy buys provider failover, retry policy, and a single place to enforce the allowlist — the self-hosted equivalent of what AI Gateway sells. It is also the metering point Default #3 needs.
• Per-deploy attribution of inference traffic. When token spend spikes, the platform should answer "which deployment, which route, which key" without the tenant instrumenting it themselves.

When the old default still holds: on a single-tenant hobby host, a full gateway is over-engineering — direct provider calls plus spend alerts get you 90% of the value. And on air-gapped or local-model fleets where inference never crosses the internet boundary, the external-egress half of this checklist does not apply at all; keep the attribution half, since internal GPU contention still needs a "who spent what" answer.

Default #2: secrets go sensitive-by-default and short-lived​

The CRUD-era default for secrets is an env var in plaintext: readable from the dashboard, the API, and every tool with project access. Vercel learned what that costs in April 2026, when attackers compromised the third-party AI tool Context.ai, rode a stolen OAuth connection into a Vercel employee's Google Workspace account, and pivoted into Vercel environments — where they read environment variables that were not marked "sensitive." Variables with the sensitive flag are stored so they cannot be read back, and Vercel found no evidence those were accessed. The plaintext ones were the escalation path.

The remediation guidance is the part every platform operator should study: rotate every non-sensitive variable, enable MFA, turn on the teamwide policy that forces new variables to be created sensitive by default, and raise deployment protection. Note the shape of the fix — it closes the classification gap for future secrets by changing the default, because asking every developer to remember to tick "sensitive" had already failed at scale.

Then Ship 2026 showed the second half of the answer. Vercel Connect gives an app or agent a temporary credential scoped to the one task in front of it, so there is no standing secret left to leak. And Vercel Passport plus the Auth0-demoed identity patterns (agents as first-class principals, token vaults, on-behalf-of delegation) move authorization from "whoever holds the shared key" to "which identity, scoped to what, traceable to which human decision." The direction is unambiguous: standing shared keys are the legacy posture; scoped, short-lived, identity-bound credentials are the replacement.

For a self-hosted PaaS, the secrets checklist is:

• Sensitive-by-default at creation. Tenant LLM keys must land in non-readable storage from the moment they are created — not after someone remembers to flip a flag. The April breach is the case study for what the flag-forgetting window costs.
• Rotation as a tool, not a runbook. One-click rotation of a tenant's provider keys, plus audit of which deployments consumed which key version, so a suspected leak is a button press rather than a weekend.
• Short-lived task-scoped credentials for agents. Anything an agent holds should expire and should be scoped to the task — the Connect pattern — so a leaked agent credential has a blast radius measured in minutes and one task, not permanent and everything.
• Agent identity distinct from human identity. Agent-triggered deploys and agent-held credentials must be attributable to an agent principal, not blended into whoever's key the agent borrowed.

When the old default still holds: the Bring-Your-Own-Key versus platform-provided-keys choice changes who owns rotation. If tenants bring their own provider keys, the platform owns storage hygiene and scoping but the tenant owns rotation — document that split explicitly or both sides will assume the other rotates. If the platform provides keys (a pooled gateway credential), the platform owns all of it, and per-tenant sub-scoping becomes mandatory rather than nice-to-have.

Default #3: inference spend is the new bandwidth bill​

The CRUD-era cost model is compute plus bandwidth plus storage — all metered by the platform, all roughly proportional to traffic the platform can see. Inference spend breaks that model twice: the meter lives at a third-party provider, and the unit (tokens) has no stable relationship to anything the platform already measures. A tiny webhook payload can trigger a million-token agent loop; request count tells you nothing about cost.

That is why the gateway from Default #1 doubles as the metering point. The platform cannot itemize what it cannot see, and provider dashboards attribute spend to an API key — not to the tenant, deployment, and route that burned it. Routing through a platform chokepoint is what lets the "which deploy spent what" question have an answer at all.

For a self-hosted PaaS, the metering checklist is:

• Per-tenant, per-deploy token accounting at the gateway: input/output tokens per route and key, retained long enough to settle disputes.
• Budget caps with teeth: per-tenant spend ceilings that throttle or block before the invoice lands, not alerts that arrive after it.
• Anomaly surfacing: a deploy whose token burn is 100x its baseline is either compromised or buggy — either way the platform should say so before the tenant's finance team does.

When the old default still holds: full chargeback-grade metering is a multi-tenant billing requirement. A single team running its own fleet does not need per-deploy invoices — spend alerts plus a dashboard get the job done. Build the metering point (you will want the data the first time spend spikes), but do not build the invoicing until someone is actually being billed.

The agent-era PaaS scorecard​

One table, five rows, each with its escape hatch:

Run your platform down the middle column, and be honest about the right column — adopting a gateway you do not need is as much a mistake as skipping the secrets default you do.

What this means if you own the machines​

Vercel's numbers are a leading indicator, not a universal law: 6 million deploys a day with half agent-triggered and a trillion gateway tokens a day is the far end of the distribution. But the direction is one-way. Every platform in this space — managed or self-hosted — is converging on the same workload mix, just at different speeds. The operators who update their defaults while inference-calling apps are 10% of their fleet will have a calmer year than the ones who wait until it is 50%.

The cheapest place to start is Default #2: sensitive-by-default storage and a rotation button cost little and pay off the day the first tenant key leaks. Egress and metering follow as inference traffic grows — but build the gateway chokepoint before you need its metering, because retrofitting attribution onto direct-to-provider calls is the kind of migration nobody schedules voluntarily.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.