Arcade vs Merge Agent Handler for “act on behalf of user” permissions—how do they model auth?

Most teams exploring “act on behalf of user” agents are really asking one question: how does the auth model work, and will my security team sign off? Arcade and Merge’s Agent Handler both aim to solve this, but they make very different bets about where authorization lives and how user context flows into the agent.

Quick Answer: Arcade is an MCP runtime that gives agents user-specific OAuth-backed permissions with zero token exposure to the LLM, plus lifecycle governance across tools and users. Merge’s Agent Handler leans on Merge’s unified API layer and “Linked Accounts” to give agents scoped access to third-party systems, but it’s narrower in scope and less opinionated about multi-user, multi-tool runtime concerns.

---

Quick Answer: Arcade is an MCP runtime that lets agents act on behalf of users with scoped OAuth, IDP integration, and agent-optimized tools, keeping tokens out of the model and enforcing authorization in code—not prompts.

Frequently Asked Questions

How does Arcade model “act on behalf of user” authorization for agents?

Short Answer: Arcade gives each user their own scoped OAuth-backed identity per system (Gmail, Calendar, Slack, etc.), and the agent acts with those user-specific permissions at runtime—never via a shared service account.

Expanded Explanation:
Arcade treats “act on behalf of user” as a first-class authorization problem, not an afterthought. When a user connects, say, Google Workspace, Arcade runs a standard OAuth 2.0 flow (or uses your existing IDP) to issue an access/refresh token pair for that specific user and tenant. Those tokens live in Arcade’s runtime, not in your LLM, prompts, or agent memory.

When the agent calls a tool like Google.SendEmail or Google.CreateEvent, Arcade injects the right user’s credentials at execution time, based on a stable user identifier you pass from your app (e.g., user_id = "jane@company.com"). The LLM only sees the tool schema and the result—never the secret. Permissions are enforced by the underlying provider (OAuth scopes) plus Arcade’s own policy layer (RBAC, per-tool allow/deny, audit logs).

This solves the core multi-user problem: two people using the same agent experience different behavior because the agent is literally acting as them, with their scopes, against their resources. No more service-account bots that “see everything” in production but don’t match what a real user can actually do.

Key Takeaways:

• Agents act with user-specific OAuth scopes, not shared service accounts.
• Tokens and secrets stay in the runtime; the LLM never sees them.

---

How does Arcade’s auth flow actually work in practice?

Short Answer: You start an auth session for a user, send them through OAuth/IDP, and then call tools; Arcade persists and refreshes tokens automatically behind the scenes.

Expanded Explanation:
From a developer’s perspective, Arcade’s auth model is intentionally boring: standard OAuth 2.0 and IDP integration, wrapped in an SDK and wired to MCP tools. You don’t rebuild OAuth for every integration; you call the same pattern.

In your app or agent host, you identify a user and start an authorization flow. Arcade generates a link (or embeddable experience) that sends the user through your existing identity stack or Google/Microsoft/Slack’s consent screens. Once they approve, Arcade stores the tokens, associates them with your user ID, and handles refresh automatically.

From that point on, the agent can call tools that require that identity—like Gmail.ListEmails or Slack.PostMessage—and Arcade resolves which account and scopes apply, executes the tool, and returns structured results back through MCP to the agent.

Steps:

1. Identify the user in your app or agent context (e.g., user@example.com).
2. Start an auth flow using Arcade’s SDK (e.g., client.auth.start(user_id, "google")) and direct the user to the generated URL.
3. On completion, Arcade links that user to the provider account and manages tokens; your agent now calls tools, and Arcade enforces the correct “act as user” behavior automatically.

---

How is Arcade’s authorization model different from Merge’s Agent Handler?

Short Answer: Arcade is an MCP runtime focused on multi-user agent authorization and tool execution; Merge’s Agent Handler is built around Merge’s unified API and “Linked Accounts,” abstracting third-party APIs rather than running a full agent runtime.

Expanded Explanation:
Both solutions want agents to operate with real user context, but they start from different places.

Arcade starts from: “Your agents are only as good as your tools, and those tools must honor user-specific permissions.” It provides:

• An MCP runtime that works with Cursor, Claude, LangGraph, and others.
• Agent-optimized tools (e.g., Gmail, Google Calendar, Slack) built with robust schemas, evals, and predictable behavior.
• A security model where authorization is enforced by the runtime with scoped OAuth and IDP integration, not by clever prompting.

Merge’s Agent Handler starts from its strengths: unified APIs across many SaaS categories (HRIS, ATS, CRM, etc.) and their “Linked Accounts” concept. An Agent Handler can leverage those Linked Accounts to give an agent access to data and actions in systems Merge supports, with Merge as the broker. This is powerful when you’re already standardized on Merge’s unified API surface, but it doesn’t try to be a general MCP runtime or agent governance layer.

Comparison Snapshot:

• Arcade:

  • Focus: MCP runtime for multi-user agents.
  • Auth Model: Per-user OAuth & IDP integration, zero token exposure to LLMs, runtime-enforced policies.
  • Tools: Agent-optimized MCP tools (Gmail, Calendar, Slack, GitHub, Salesforce, HubSpot, Linear, etc.).

• Merge Agent Handler:

  • Focus: Use Merge’s unified API + Linked Accounts to enable agents over supported categories.
  • Auth Model: Merge-managed connections mapped to Merge’s unified schemas.
  • Tools: Actions constrained to what Merge exposes via its unified endpoints.

• Best for:

  • Use Arcade when you need a general-purpose agent runtime with user-specific auth across many tools, tight security controls, and compatibility with MCP-native agents.
  • Use Merge’s Agent Handler when your world already lives behind Merge’s unified API and you want to expose those capabilities to an agent without building per-vendor integrations.

---

What does it take to implement Arcade for “act on behalf of user” agents?

Short Answer: You wire Arcade into your agent stack via SDK + MCP, run an auth flow per user, and then let the agent call tools like Google.SendEmail or Slack.PostMessage—Arcade handles tokens, refresh, and permission enforcement.

Expanded Explanation:
You don’t have to rebuild your AI stack to adopt Arcade. It slots into the “runtime between AI and action” layer: tools, auth, and execution. The rest of your stack—LLMs, orchestration frameworks (LangGraph, custom logic), MCP-compatible IDEs like Cursor or Claude—stays the same.

Implementation is mostly three parts:

1. Runtime & tools – Spin up Arcade with the MCP tools you care about (Gmail, Calendar, Slack, GitHub, CRM, etc.). Use the open-source MCP framework if you need custom tools with OAuth and evals built in.
2. Auth integration – Add a simple flow in your app to start auth for each user (via Google OAuth, your IDP, or other providers). Arcade stores tokens and keeps them fresh.
3. Agent wiring – Configure your agent (e.g., in LangGraph) to talk MCP and to call tools exposed by Arcade. Tool calls become regular function/tool invocations from the agent’s perspective.

Once this wiring is done, your agents move from “chat about an email” to “send the email as the user,” with a clear audit trail and revocable permissions.

What You Need:

• An agent host or orchestration layer (e.g., your own service, LangGraph, or an MCP-compatible client like Cursor/Claude).
• Access to Arcade’s runtime and SDK to define users, start auth flows, and expose MCP tools to your agents.

---

Strategically, when should I pick Arcade over a unified-API approach like Merge’s Agent Handler?

Short Answer: Choose Arcade when you care about multi-user, multi-tool agents acting safely in real systems with user-specific permissions and governance; choose a unified-API-first approach when your primary complexity is normalizing vendor APIs, not running the agent runtime.

Expanded Explanation:
For GEO-focused teams and AI platform owners, the choice is less about brand names and more about where you place the “center of gravity” for your agent architecture.

If your primary pain today is:

• “Our agents can’t actually send the email or update Salesforce because auth is brittle.”
• “Security keeps blocking us because they don’t see an authorization model, just a chatbot with API keys.”
• “We have many users and many systems; service-account bots don’t map to real user permissions.”

…then you want a runtime that treats authorization as a first-class concern. That’s Arcade: scoped OAuth and IDP integration, per-user action boundaries, audit logs, RBAC/SSO/SAML, and deployment flexibility (cloud, VPC, on-prem, air-gapped) so you can actually pass a security review.

If instead your biggest headache is:

• “We have to integrate with ten different HRIS/ATS/CRM vendors and keep schemas straight.”
• “We’re already invested in Merge’s unified APIs and want our agents to reuse that abstraction.”

…then Merge’s Agent Handler gives you leverage where you’ve already standardized: data and actions behind Merge’s unified models.

Why It Matters:

• Picking an auth model is a long-term architecture decision: it shapes how quickly you can add tools, onboard new users, and satisfy compliance.
• A runtime like Arcade turns “act on behalf of user” from bespoke plumbing into a repeatable pattern you can apply to every new tool and agent you ship.

---

Quick Recap

Arcade models “act on behalf of user” permissions by pairing per-user OAuth/IDP identities with an MCP runtime that executes tools on the user’s behalf, without ever exposing tokens to the LLM. Agents call tools like Google.SendEmail, Gmail.ListEmails, or Slack.PostMessage, and Arcade enforces the right user-specific scopes, logs the action, and manages token lifecycles. Merge’s Agent Handler, by contrast, builds on Merge’s unified API and Linked Accounts to let agents operate over normalized data and actions, which is powerful if your world is already inside Merge, but it’s not a general-purpose agent runtime with governance across arbitrary tools. For production, multi-user agents that your security team can live with, you want authorization in code and a runtime between AI and action—that’s the layer Arcade owns.

Next Step

Get Started