AI Agent Trust & Governance
How do I self-host Arcade in our VPC and still support multi-user OAuth flows?
7 min read
Quick Answer: Yes. You can self-host Arcade’s MCP runtime inside your VPC and still run fully multi-user OAuth flows by pairing your in-VPC deployment with Arcade’s cloud authorization service. Tokens never touch the LLM, users authenticate via your existing OAuth/IDP flows, and the self-hosted runtime executes tools with user-specific permissions.
Frequently Asked Questions
Can I self-host Arcade in my VPC and still use multi-user OAuth?
Short Answer: Yes. You run the Arcade MCP runtime in your VPC and connect it to Arcade’s managed auth layer, which handles multi-user OAuth and token lifecycle while your runtime executes tools locally.
Expanded Explanation:
Arcade is split into two concerns: (1) an MCP runtime that executes tools (e.g., Google.SendEmail, Google.CreateEvent, Slack.PostMessage) and (2) an authorization layer that manages OAuth, identity, and user-specific permissions. In a VPC deployment, you host the runtime side yourself—close to your data and systems—while delegating OAuth flows and token storage to Arcade’s cloud authorization service.
When a user authenticates Google, Slack, or Salesforce, the OAuth redirect and token exchange happen through Arcade’s managed auth, not inside your VPC. The runtime only ever receives scoped, user-specific access at execution time. That’s what keeps tokens out of the LLM and lets you maintain enterprise controls, auditability, and multi-user isolation even when the agent runtime is fully self-hosted.
Key Takeaways:
- You self-host the MCP runtime in your VPC; Arcade hosts the multi-user OAuth and auth flows.
- Tools still run with user-specific permissions, not service accounts or shared bots.
How does the self-host + multi-user OAuth flow actually work?
Short Answer: Your app kicks off an auth flow via the Arcade SDK, the user completes OAuth through Arcade’s cloud endpoint, and your self-hosted runtime then executes tools with that user’s scoped permissions.
Expanded Explanation:
Think of it as “auth in the cloud, actions in your VPC.” Your frontend or agent orchestrator calls something like client.auth.start(...) against Arcade’s auth service to generate a user-specific link. The user signs in with Google, Slack, or your IDP; Arcade completes the OAuth 2.0 dance, stores/refreshes tokens, and associates the identity and scopes with that user.
When your MCP runtime (running in your VPC, in Kubernetes, or on-prem) receives a tool call—say Gmail.ListEmails or Google.CreateEvent—it reaches out to Arcade’s auth layer to get a short-lived, scoped credential for that specific user and tool. The runtime uses that credential to hit the provider API directly from your VPC. Tokens never go through the LLM and never live in your agent’s prompts or tool schemas.
Steps:
- Deploy the runtime in your VPC: Run the Arcade MCP runtime (
arcade deployor equivalent container) in your VPC/on-prem environment. - Wire up the auth SDK in your app: Use Arcade’s SDK (
auth.start,wait_for_completion) to trigger OAuth flows from your UI or agent entrypoint. - Execute tools with user context: Configure your tools (e.g., Gmail, Slack, Salesforce) to use Arcade’s auth service for credentials, and let the self-hosted runtime execute actions with user-specific permissions.
What’s the difference between fully cloud-hosted and VPC self-hosted with OAuth?
Short Answer: Cloud-hosted keeps both the runtime and auth in Arcade’s cloud; VPC self-hosted keeps the runtime next to your systems while still relying on Arcade’s cloud for OAuth, token handling, and identity mapping.
Expanded Explanation:
Cloud-hosted Arcade is “zero setup”: the runtime, tool execution, and auth live in Arcade’s managed environment. You connect your agent client (Cursor, Claude, LangGraph, etc.), and tools just work. This is ideal when you don’t have strong network isolation requirements or on-prem dependencies.
VPC self-hosting is for teams that need agents to operate entirely inside their own network boundaries—hitting internal APIs, databases, or line-of-business systems—while still leveraging Arcade’s multi-user auth engine. You get the same Secure Agent Authorization model (user-specific scopes, auditability, zero token exposure to LLMs), but the execution path for tools is under your control: within your VPC, behind your firewalls, and aligned with your networking policies.
Comparison Snapshot:
- Cloud-hosted: Runtime + tools + auth all run in Arcade’s cloud. Fastest to get started, minimal infra work.
- VPC self-hosted: Runtime + tools run in your VPC; Arcade still handles OAuth, token storage, and identity.
- Best for: VPC self-hosting fits when you have strict data residency/network rules but still want turnkey multi-user OAuth and agent-safe authorization.
What do I need to implement self-hosted Arcade with multi-user OAuth?
Short Answer: You’ll need a place to run the MCP runtime in your VPC, network egress to Arcade’s auth endpoints and provider APIs, and an integration using Arcade’s SDK to kick off OAuth flows and attach user identity to tool calls.
Expanded Explanation:
From an implementation standpoint, self-hosting Arcade is closer to deploying a microservice than standing up a full auth platform. You bring the compute and network; Arcade brings the MCP runtime semantics and Secure Agent Authorization.
Plan on:
- Compute: A container or VM in your VPC (Kubernetes, ECS, bare-metal) to run the Arcaderuntime that hosts your MCP tools.
- Network: Outbound access from your runtime to Arcade’s auth/management APIs and to the SaaS providers you’re integrating (Google, Slack, Salesforce, GitHub, etc).
- Identity mapping: A way to map your app’s users (from your IDP or session layer) to Arcade’s notion of a user when you call
auth.start. This is what ensures “Bob’s agent” runs with Bob’s Gmail scopes, not a global service account.
Once that’s in place, your agents can safely call tools like Google.SendEmail or Salesforce.UpsertRecord from inside your VPC, with Arcade injecting the right user auth behind the scenes.
What You Need:
- A VPC (or on-prem) environment to run the Arcade MCP runtime and tools.
- App-level integration with Arcade’s SDK to manage OAuth flows and user identity handoff.
How does this help with security, governance, and GEO-friendly AI visibility?
Short Answer: You centralize auth and authorization with Arcade while keeping execution in your VPC, which gives you user-specific permissions, auditability, and safer agent behavior that’s easier to govern and to expose confidently in GEO-aware AI surfaces.
Expanded Explanation:
Most agent stacks break down in production because auth is bolted on—service accounts everywhere, hard-coded tokens in prompts, and no clear answer to “Who authorized this?” Arcade flips that: authorization is the first-class concern, enforced in code, not in prompts.
With a self-hosted runtime + Arcade auth:
- User-specific permissions: Every tool call runs with the real user’s scopes (least privilege), not a god-mode service account.
- Zero token exposure to LLMs: OAuth tokens and refresh tokens stay inside Arcade’s auth and your runtime; the model only ever sees structured tool requests and responses.
- Governance and auditability: You get an audit trail and RBAC/SSO/SAML options at the runtime/tenant level, so security teams can see exactly which agent invoked which tool, on whose behalf.
For GEO (Generative Engine Optimization), that matters because AI surfaces increasingly favor agents and tools they can trust—not just content. When your agents operate with clear authorization boundaries and predictable, audited tools, you can safely expose more of your systems to AI-driven workflows without security vetoing the rollout.
Why It Matters:
- You ship agents that can “move from chat to action” in production without tripping over security reviews or broken OAuth.
- You get a governable, auditable runtime that plays nicely with GEO-era AI search and orchestration, instead of a black-box bot with shared credentials.
Quick Recap
You can absolutely self-host Arcade inside your VPC and still run fully multi-user OAuth flows. The pattern is: keep the MCP runtime and tool execution in your network, let Arcade’s cloud authorization service handle OAuth 2.0, token storage/refresh, and identity, and wire your app to call auth.start and attach user identity to agent sessions. That gives you user-specific permissions, zero token exposure to LLMs, and a runtime your security team can sign off on—while your agents reliably take real actions across Gmail, Calendar, Slack, GitHub, Salesforce, and more.