Agents Deploy, Agents Never Hold the Keys: What Arcade.dev's OAuth-Handling MCP Runtime Means for Deploy-from-Chat

Every deploy-from-chat demo ends the same way. The agent scaffolds the app, writes the Dockerfile, pushes the branch — and then it asks for your API key. Paste a GitHub personal access token into the chat box. Drop your cloud credentials into the prompt. The audience laughs, the presenter hurries past it, and the dream of "an agent that deploys apps" quietly becomes "a chatbot with god-mode access to your infrastructure."

That moment is the whole ballgame. Secrets that pass through a prompt end up in conversation logs, eval traces, and training-data pipelines — places no rotation policy can reach. Until agents can act on a user's accounts without ever holding the user's tokens, deploy-from-chat is a demo trick, not a product. This post is about the machinery that closes that gap: what Arcade.dev built as an MCP runtime, how its OAuth-handling flow works step by step on a concrete deploy, and what a self-hosted PaaS should borrow versus build.

The N×M auth problem, quantified​

Strip away the marketing and every agent platform faces the same matrix: N users × M integrations, each cell needing its own OAuth dance, token vault, refresh timer, scope check, and audit entry. For one user and one GitHub connection, hand-rolling this is an afternoon. For production, the line items stack up fast:

• OAuth flows per provider. Every integration (GitHub, Slack, Gmail, Salesforce, your PaaS) has its own consent URLs, scopes, PKCE handling, and token endpoint quirks. Each one is a small snowflake; a catalog of dozens is a maintenance burden.
• Vaulting and refresh. Access tokens expire; refresh tokens rotate. Somewhere a service must store secrets encrypted, refresh them ahead of expiry, and survive rotation without dropping the user's 2am deploy.
• Per-call scoping. The agent asked to push code, not delete repos. Enforcing least privilege means checking scopes on every call, not just at login.
• Revocation and audit. When a user disconnects GitHub or an employee leaves, every derived credential must die promptly — and there must be a log tying each agent action back to a real user, not a shared service account.

Arcade.dev's own homepage frames the failed alternatives exactly this way: give agents shared service accounts and you lose per-user accountability; let agents inherit full user identity and you over-provision every action; build the security layer yourself and you now own "the consequence of every action." Their pitch — "you don't try to build your own SSO anymore, nor should you build internal agent governance systems" — lands because every platform team that has hand-rolled per-provider OAuth eventually reaches the same conclusion.

What Arcade.dev actually is​

The fact-box first, since the rest of the post assumes it:

• The Arcade Engine is a hosted-or-self-hostable runtime that sits between agents and third-party systems. It coordinates OAuth flows, stores and refreshes tokens, enforces scopes, and executes tool calls — the agent asks for an action by name and never touches a credential.
• The catalog is "thousands of pre-built MCP tools," in Arcade's own wording, covering the apps an org already runs on, plus a framework for authoring custom tools with OAuth built in.
• Framework adapters are first-class for LangChain, CrewAI, OpenAI Agents, Google ADK, AG2, Vercel AI, Mastra, and others — the runtime meets agents where they already live rather than demanding a new framework.
• URL elicitation, co-developed with Anthropic and accepted into the MCP spec in November 2025, lets an MCP server hand the user a secure login page mid-task: granular, context-specific consent delivered as a URL exactly when the agent needs the authorization.
• The company raised a $12M seed round in March 2025 led by Laude Ventures (Perplexity co-founder Andy Konwinski's fund), founded by Alex Salazar and Sam Partee on the thesis of authenticated tool-calling — "SSO for AI agents."

Two spec-level details matter for what follows. MCP's own authorization spec — developed with Anthropic, Arcade, Microsoft, and Okta/Auth0 — defines OAuth-style protected resources with audience binding via Resource Indicators (RFC 8707) and delegation via Token Exchange (RFC 8693). In other words: MCP standardizes the handshake, and the runtime layer above still has to do the unglamorous work of vaulting tokens, collecting just-in-time consent, and verifying users. That unglamorous work is the product.

The core deliverable: a deploy without keys, step by step​

Concrete target: a user tells a chat agent, "deploy repo acme/shop to my staging project." The agent needs write access to the user's GitHub repos and deploy rights on the platform. Here is the naive flow versus the runtime-vaulted flow.

Before: the agent holds the keys. The user pastes a GitHub personal access token (classic, probably repo + delete_repo because nobody scopes PATs carefully) and a platform API key into chat or env config. The agent now holds two long-lived, broadly-scoped secrets. They persist in chat history, appear in debug logs, and grant far more than "deploy this repo to staging" — including every private repo the token can read and every project the API key can destroy. Revocation means the user must remember everywhere the secret went. They won't.

After: the agent holds names, the runtime holds tokens. The agent calls tools by name; the Engine resolves credentials per call, per user:

1. The agent invokes GitHub.ListRepos / Platform.Deploy for user u-4821. It presents no credential — just the user identity and the requested action.
2. The Engine finds no GitHub authorization for u-4821 and returns a consent URL (URL elicitation). The user clicks it, lands on GitHub's real OAuth page, and approves narrow scopes — repo for code, nothing more.
3. The Engine vaults the tokens, schedules refresh, and executes the call with the just-issued credential. The agent receives only the result: branch listed, deploy started, URL returned.
4. On the platform side the same pattern repeats: the deploy tool executes under the user's platform identity with a scope like deploy:staging, not a master API key.

Authoring the tool side looks like this — authorization declared, not implemented:

@tool(requires_auth=GitHub(scopes=["repo"]))
def deploy_preview(repo: str, project: str) -> str:
    # No token handling here. The runtime injects a
    # short-lived, per-call credential and refreshes it.
    ...

The unhappy paths are the point, so here they are explicitly. If the user denies consent, the call fails closed with a clean refusal and the agent asks whether to proceed without GitHub access — it cannot retry with a stored secret because it holds none.

If the user revokes GitHub access mid-run (settings page, token-leak scare, offboarding), the next call fails closed and the agent surfaces a fresh "reconnect GitHub" link instead of a mysterious 401. If the granted scope is insufficient (read-only token, deploy needs write), the error names the missing scope so the agent can request exactly that elevation — least privilege as a user-visible flow, not a support ticket.

Every one of these paths is safe by construction for the same reason: there is no secret in the agent's context to leak, replay, or over-reuse.

Runtime vs gateway: why the distinction matters​

"Something between the agent and the tools" now has two competing names, and buying the wrong one hurts. A gateway proxies and governs MCP traffic: discovery, routing, rate limits, threat detection, audit. A runtime additionally executes with the user's authority: it owns the OAuth lifecycle and injects per-call credentials. Arcade is the latter — one comparison table puts it bluntly: "per-user OAuth runtime," with threat detection marked "N/A (runtime, not gateway)."

The honest read: these compose. An identity provider can be the authorization server, a runtime can execute behind it, and a gateway can sit in front — the question is which layer owns the user's tokens, and the answer should be exactly one purpose-built layer, never the agent's prompt context.

What a deploy-from-chat PaaS borrows vs builds​

For a self-hosted platform whose roadmap says "agents deploy apps," the borrow/build line is now drawable:

• Borrow: consent, vaulting, refresh, per-call scoping. This is undifferentiated heavy lifting with a spec trail (OAuth 2.1, RFC 8707, RFC 8693, URL elicitation) and at least one runtime that deploys into your own VPC or air-gapped — so "we can't send tokens to a vendor" is not a blocker.
• Build/keep: the platform's own deploy credential model. How a tenant-scoped deploy token is minted, what deploy:staging versus deploy:production means, and how agent-initiated deploys appear in your audit trail must live in your control plane — a third-party runtime cannot define your authorization semantics.
• Keep on owned infra: the audit log. The runtime logs what the agent did as the user on third-party systems; your platform logs what happened to the tenant. Both must exist; neither substitutes for the other.
• Don't build: another per-provider OAuth snowflake collection. Every week spent hand-rolling your twentieth provider integration is a week not spent on the deploy path itself.

Note the deployment detail that makes this advice practical for self-hosters rather than just SaaS buyers: the Engine's VPC/on-prem/air-gapped option means the vault can live on machines you own, under the same reconciliation and backup discipline as the rest of the fleet.

Agents are about to be your heaviest API users​

The direction is one-way. Agent frameworks already treat tool-calling as the default interface, registries already count MCP servers in the thousands, and every "deploy from chat" demo that still asks for an API key is a breach report waiting for a date.

The platforms that survive the transition will be the ones where the agent is a first-class operator with less ambient authority than a human — consented per action, scoped per call, revoked in one click. That is exactly the machine Arcade built; whether you buy it, self-host it, or reimplement its contract, the shape of the answer is now settled. Agents deploy. Agents never hold the keys.

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.