Netlify Calls the Model for You: What Zero-Key Agent Runners Teach Self-Hosted MCP Servers About Auth

Netlify will call the model for you so your app never touches an API key. On your own machines, nobody offers to do that — and that turns out to be a feature, not a gap.

Netlify's Agent Runners let you pick Claude, Gemini, Codex, or OpenCode from a dashboard dropdown — no API keys, no external accounts. Underneath, the AI Gateway handles authentication automatically: you use the OpenAI or Anthropic SDK directly inside a Netlify Function, and inference costs draw from the same unified credit balance as the rest of the platform.

Nothing to copy into an env var, nothing to leak. Here is the whole argument in one table — who holds the key, who meters the bill, and where the blast radius lands — plus the verdict this post defends: a self-hosted deploy-from-chat platform should not copy the broker. It should let the tenant hold the model key and spend its auth budget on short-lived, per-agent MCP credentials instead.

The short version: credential-free is a billing feature wearing a security costume. The security problem — keys leaking — has a cheaper, structurally simpler answer when you own the machines.

How Netlify's zero-key actually works​

The mechanics are admirably boring, which is the point. Agent Runners run coding agents on Netlify's production infrastructure from the first prompt: describe the task, choose your agent, review the Deploy Preview before anything ships. The agent arrives with project context — code, environment variables, build settings, deployment pipeline — and runs in an isolated environment governed by the same role-based access that governs deployments. Every change is tracked, reversible, and auditable.

The model-access half is the AI Gateway. Each model announcement repeats the same sentence: use the vendor SDK directly in your Netlify Functions without managing API keys or authentication, because the gateway handles everything automatically. New models — GPT-5.4, GPT-5.6, Claude Opus 4.6 and 4.8, Gemini 3.8 Flash — arrive in both surfaces at once. The tenant never creates a provider account, never pastes a key, never wonders which env var the agent can read. Usage is metered against platform credits, the way bandwidth and build minutes already are.

That design makes total sense for a hosted PaaS. Netlify sits between the tenant and the model vendor by construction: it already bills the tenant, already isolates the runner, already owns the audit trail. Folding model-credential custody into that existing position is nearly free for Netlify and removes an entire support category — "where do I put my OpenAI key" — for the tenant. Credential-free is not charity; it is the platform monetizing the seam it already occupies.

The risk it is solving is real and measured​

None of this is theater. Hardcoded secrets are getting worse every year, and agents make every leak travel faster.

• 23,770,171 new hardcoded secrets were added to public GitHub repositories in 2024, up 25% year over year (GitGuardian State of Secrets Sprawl 2025).
• 28,649,024 followed in 2025, up 34% — the largest annual jump in the report's history.
• 70% of secrets leaked in 2022 were still valid when re-checked, meaning a leak is a standing credential, not a transient embarrassment.
• 24,008 unique secrets were found specifically in MCP configuration files in 2025 — API keys, database credentials, and service tokens sitting in the exact JSON files agents are taught to read.
• ~12,000 live API keys and passwords were found baked into Common Crawl web data used to train AI models (Truffle Security, February 2025), including one WalkScore key repeated 57,029 times across 1,871 subdomains.
• 18.1 million exposed API keys and tokens were captured in 2025 (SpyCloud 2026 Identity Exposure Report).
• Mobile is no better: 815,000 hardcoded secrets across 156,000 iOS apps — 71% of apps leaking at least one, averaging 5.2 each (Cybernews).

The MCP number deserves a second look from anyone building agent tooling. If agents read config files and config files hold long-lived keys, every agent run is an exfiltration path you installed on purpose. Netlify's answer — the tenant's agent never holds a key worth stealing — deletes that path by construction. The question is what deleting it costs when you are the platform.

What matching it self-hosted would really cost​

To offer "no API key" on machines you own, you must become the model vendor's customer on every tenant's behalf. That means building a credential-brokering layer with at least five parts, each of which is a small product:

1. A gateway proxy. Every model call flows through your code so your key — never the tenant's — reaches the vendor. The open-source shape is LiteLLM; the hosted pattern is Vercel's AI Gateway (hundreds of models at provider list price, 0% markup) or Cloudflare's AI Gateway (a free control plane in front of your own provider keys with caching, routing, and spend limits). Self-hosting the proxy means you own its uptime, tail latency, streaming behavior, and provider-outage failover.
2. Per-tenant metering and quota. Netlify deducts inference from a unified credit balance. Your broker needs the same ledger — per-tenant usage, dollar-denominated spend limits, overage policy — or one tenant's runaway agent spends your shared vendor balance. This is billing infrastructure, not auth code.
3. A key vault with rotation. Your vendor keys become the highest-value secret in the fleet. They need sealed storage, rotation without downtime, and separation from tenant-readable config. A leak now compromises every tenant at once — the exact correlated blast radius the tenant-holds-key model avoids.
4. An audit trail per agent identity. "Who prompted what, when" must extend to "which agent spent how many tokens on which model for whom." Tenants will dispute bills; you will need the receipts.
5. Abuse controls. Rate limits, cost caps, model allow-lists per tenant, and a kill switch per agent. A hosted platform amortizes this over millions of runs. A self-hosted fleet of ten teams pays the same build cost for a hundredth of the traffic.

None of this is impossible — OpenRouter proves buyers will pay roughly a 5% fee for "one balance, no key management" across 400+ models. But OpenRouter is the business. For a deploy-from-chat PaaS, the broker is overhead between the tenant and a bill the tenant could pay directly. You would be rebuilding Netlify's meter without Netlify's scale, and converting many small, uncorrelated tenant-key risks into one large, correlated platform-key risk.

The simpler answer: the tenant holds the key, the agent holds nothing long-lived​

Here is the structural difference the TODO item names honestly. On your own infrastructure, the tenant already owns the model account, the machines, and the bill. There is no seam for the platform to monetize — so do not build one. Instead, spend the auth budget where self-hosting wins: short-lived, narrowly-scoped credentials between the agent and your MCP server.

The protocol work is already done. The March 2025 MCP specification (2025-03-26) standardizes authorization on OAuth 2.1: authorization-code flow with PKCE (S256 only), RFC 8414 authorization-server metadata, RFC 9728 protected-resource metadata, and RFC 8707 resource indicators. Treat every MCP client as an OAuth client and the MCP server as a resource server against an existing authorization server — that is the whole pattern. The community guidance converges on the same numbers:

• Short-lived access tokens: 15–60 minutes. Long enough for an agent run, short enough that a leaked token is nearly worthless. Refresh via the authorization server, never by re-reading a static secret.
• Least privilege per tool. The deploy agent gets deploy:staging, not admin:*. Scope tokens to the tenant, the agent identity, and the action — so a compromised sandbox cannot pivot to another tenant's fleet.
• HTTPS everywhere, no plaintext config secrets. Never commit credentials to version control or leave them in ~/.config/mcp/config.json equivalents. The 24,008 MCP-config secrets above are the failure mode you are designing out.
• Read/write split. Safe queries (list apps, get deploy status, tail logs) run on the agent's ambient credential; every mutation (deploy, scale, delete, rotate secrets) requires the short-lived scoped token plus explicit approval and an audit entry.

Concretely, the shape looks like this: the tenant pastes their own provider key once into your platform's secret store (or brings their own vault). Your MCP server never shows that key to the agent. When the agent needs to act, it completes the OAuth flow against your authorization server, receives a minutes-lived token scoped to one tenant and a handful of tools, and spends it. If the token appears in a log, a prompt transcript, or a training corpus, the finder gets an expired string — compare that with the 70%-still-valid standing credentials above.

What you explicitly do not build: no unified credit ledger, no per-model markup, no vendor-key vault shared across tenants, no failover matrix across 400 models. The tenant's provider relationship stays theirs. Your platform owns the layer it is actually good at — machine-readable fleet state, scoped tool boundaries, and the audit log that says which agent did what.

Should you ever build the broker? A three-question checklist​

There are fleets where credential brokering earns its keep. Ask all three before writing the proxy:

1. Do your tenants lack provider accounts? If you serve non-technical teams who cannot or will not create vendor accounts, "no key" is onboarding, not overhead. If your tenants are engineering teams who already hold keys, you are solving a problem they do not have.
2. Can you price the margin? The broker only survives if metered inference pays for the vault, the ledger, the abuse team, and the correlated-risk insurance. Netlify folds it into platform credits at scale. If you cannot name the markup, you are donating infrastructure.
3. Does one key materially reduce support load? Count last quarter's "where does my key go" tickets. If key handling dominates support, a broker may pay for itself in tickets avoided. If it does not, ship the OAuth flow and the docs instead.

If all three answer yes, build the broker — starting from LiteLLM or an OpenRouter-style aggregator, not from raw HTTP. Otherwise, the tenant-holds-key design is not a stopgap. It is the architecture that matches who owns what.

Netlify's zero-key runners are the right answer for a hosted PaaS that already sits between tenants and vendors. A self-hosted, agent-operated platform sits somewhere else: next to the tenant, on machines the tenant owns, with agents as first-class operators of typed tools. Give those agents minutes-lived, narrowly-scoped credentials, keep the model key in the tenant's vault, and let the platform compete on what it alone provides — a fleet whose every fact is machine-readable and every mutation is attributable. That is credential discipline without the billing company attached.

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.