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 hit the same wall fast: the model can reason, but actually sending an email, creating a calendar event, or updating Salesforce as the user turns into a thicket of OAuth flows, refresh tokens, and permission edge cases. Both Arcade and Merge’s Agent Handler aim at this problem, but they model auth in very different ways.

This FAQ breaks down how each approach handles “act on behalf of user” permissions, where they’re similar, and where they diverge if you’re trying to ship multi-user, production agents—not one-off demos.

Quick Answer: Arcade models auth as a dedicated MCP runtime for agents with user-specific permissions, OAuth/IDP integration, and zero token exposure to LLMs. Merge’s Agent Handler hangs auth off their unified API model, making it easier to connect SaaS APIs but with a more traditional integration-style abstraction rather than an agent-optimized runtime.

---

Frequently Asked Questions

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

Short Answer: Arcade models auth around user-specific OAuth and IDP-based identity, so agents act exactly as the end user would, with scoped permissions, token lifecycle handled by the runtime, and no tokens ever exposed to the LLM.

Expanded Explanation:
Arcade treats authorization as the core of the runtime, not an afterthought. Every agent action runs inside an MCP runtime that knows which human user it’s acting for, what OAuth scopes were granted, and what tools are allowed. When your agent calls something like Google.SendEmail or Google.CreateEvent, Arcade uses industry-standard OAuth 2.0 behind the scenes to obtain and refresh tokens for that specific user, then injects credentials at runtime—never into prompts or model context.

The model only ever sees tool schemas and high-level results, not raw secrets. Authentication is kicked off with simple SDK calls (client.auth.start(...) plus wait_for_completion) wired into your existing OAuth and SSO/IDP flow. Once a user has authenticated, Arcade persists and refreshes tokens automatically, so they don’t have to re-consent every time the agent sends an email or touches their calendar.

Key Takeaways:

• Agents act with user-specific permissions—not shared service accounts.
• OAuth, token storage/refresh, and permission scoping are handled in the runtime, not in your prompts or app glue code.

---

How does the Arcade auth flow actually work end-to-end?

Short Answer: You associate a user with a provider, start an OAuth flow, wait for completion, and then let the agent call tools; Arcade manages token storage, refresh, and permission enforcement automatically.

Expanded Explanation:
Arcade’s flow is intentionally minimal-ceremony. From your code, you call the Arcade SDK to initiate auth for a user and a provider (e.g., Google). Arcade generates a link that plugs into your existing OAuth/IDP UX. Once the user grants scopes, Arcade stores the resulting tokens in a tenant-isolated vault and marks that user+provider as authorized.

From that point on, your agents can safely call Gmail, Calendar, Slack, etc. tools for that user. Every tool call passes through the runtime, which injects the right credentials, enforces scopes, and records an audit trail. If a refresh token expires or breaks, Arcade handles re-auth or refresh logic so you don’t end up debugging token issues at 2 a.m.

Steps:

1. Start auth from your app:

   from arcadepy import Arcade
   
   client = Arcade()
   user_id = "user@example.com"
   
   auth_response = client.auth.start(user_id, "google")
   # auth_response contains the URL to send the user to
   

2. Send the user through the auth link using your existing web/app flow (or IDP-initiated SSO) to grant scopes like Gmail/Calendar.
3. Wait for completion (wait_for_completion or webhook-style callback), then let your agent call tools such as Gmail.ListEmails, Google.SendEmail, or Google.CreateEvent—Arcade injects tokens and enforces permissions at runtime.

---

How does Arcade’s auth model compare to Merge’s Agent Handler?

Short Answer: Arcade is an MCP runtime focused on agent-safe, user-specific authorization; Merge is a unified API + agent handler focused on normalizing third-party integrations, then exposing them to agents.

Expanded Explanation:
At a high level, both products want your agent to “act on behalf of a user” in external SaaS systems. The difference is what they optimize for:

• Arcade is built as the runtime between AI and action. It assumes you’re running multi-user agents and need user-specific scopes, SSO/IDP integration, audit trails, RBAC, and strict token isolation from the LLM. Tools are designed as “agent-optimized tools” under MCP—not just API wrappers—so that agents behave predictably and cheaply at scale.

• Merge’s Agent Handler rides on top of Merge’s unified API. You get a normalized data and action model across systems (HRIS, CRM, ATS, etc.), and the agent handler adds a bridge between that API surface and an LLM/agent. It’s closer to “make our integrations agent-friendly” than “build a full authorization runtime for agents.”

In practice: if your biggest pain is mapping dozens of different SaaS APIs into one schema, Merge is attractive. If your biggest pain is safely letting agents send emails, post to Slack, or update CRM as individual users—and convincing security to sign off—Arcade’s authorization-first runtime is the tighter fit.

Comparison Snapshot:

• Option A: Arcade
  • Auth model: user-specific OAuth + IDP, scoped permissions, zero token exposure to LLM.
  • Surface: MCP runtime + agent-optimized tools (Gmail, Google Calendar, Slack, GitHub, Salesforce, HubSpot, Linear, etc.).
  • Governance: audit trail, RBAC/SSO/SAML, tenant isolation; designed for multi-user agents.
• Option B: Merge Agent Handler
  • Auth model: unified API auth model across many SaaS systems, with agent handler as a layer to interpret and route actions.
  • Surface: normalized data/actions via Merge’s unified APIs, then fed into an agent.
  • Governance: focused on making integration auth simpler and unified; agent-specific governance is layered on top of that.
• Best for:
  • Arcade: teams building production, multi-user agents that must strictly enforce “act as the user” permissions and pass security review.
  • Merge Agent Handler: teams whose primary complexity is many disparate third-party APIs and who want a normalized, integration-centric surface that agents can call.

---

How do I implement Arcade in an existing agent stack (Cursor, Claude, LangGraph, etc.)?

Short Answer: You deploy Arcade as your MCP runtime, wire its tools into your agent framework, and run auth flows through your app so each user gets their own scoped credentials.

Expanded Explanation:
Arcade is MCP-native. That means if you’re already using MCP-aware tools or clients (Cursor, Claude, LangGraph, and others), Arcade slots in as the runtime that hosts tools and enforces authorization around them. For example, in LangGraph or LangChain-style architectures, your agent doesn’t hit raw APIs; it calls MCP tools like Gmail.ListEmails or Slack.PostMessage, and Arcade handles the auth and execution.

You don’t rebuild OAuth from scratch for each integration; you use Arcade’s SDK and config to describe providers and scopes. Arcade’s open-source MCP framework lets you define new tools with OAuth and evals built in, then deploy them to the runtime with managed secrets and configuration. Credentials stay in Arcade, not in your LLM prompts or vector stores.

What You Need:

• An MCP-aware client/agent framework (e.g., Cursor, Claude, LangGraph, or your own MCP client) that can call Arcade-hosted tools.
• Arcade account + SDK integration in your backend to:
  • Start user auth (auth.start, wait_for_completion).
  • Configure which tools and scopes are available to which agents.
  • Monitor usage via audit logs and governance controls.

---

Strategically, when should I choose an authorization-first runtime like Arcade vs. a unified API approach like Merge?

Short Answer: Choose Arcade when your primary risk is authorization and governance for multi-user agents; choose a unified API like Merge when your primary risk is wrangling inconsistent SaaS APIs and schemas.

Expanded Explanation:
In practice, most real-world agent projects fail not because the LLM can’t reason, but because they can’t get through security review, or they break the moment real users and tokens show up. Service-account bots don’t match real user permissions, refresh tokens expire, and secrets leak into logs or prompt histories.

Arcade is built from the assumption that:

1. “Your agents are only as good as your tools.” Tool contracts and auth boundaries matter more than clever prompts.
2. Authorization must be enforced in code, not prompts. Permission gates, scoped access, and audit logs should be runtime features, not system prompt suggestions.
3. Production agents are multi-user systems. Service accounts are a dead end if you want real “act as the user” semantics.

Merge, by contrast, starts from a different pain: every SaaS has a different API and data model. If you’re building a system-of-record app with AI assistance on top, a unified API plus an agent handler helps normalize all of that. You can still support “act on behalf of user,” but auth is one concern among many—schema unification is the center of gravity.

Why It Matters:

• Impact on delivery: An authorization-first runtime like Arcade lets you go from chat-only prototypes to “send the email, create the event, update the deal” in production, with the same auth model as your core app (OAuth + IDP).
• Impact on trust: Security teams care less about “it worked in the demo” and more about scoped OAuth, audit logs, RBAC/SSO, and token isolation. Arcade is explicitly designed to check those boxes for agent workloads.

---

Quick Recap

Arcade and Merge’s Agent Handler both help agents “act on behalf of users,” but they start from different assumptions. Arcade is an MCP runtime focused on secure agent authorization, user-specific permissions, and zero token exposure to LLMs—so you can let agents send emails, manage calendars, and touch systems like Slack, GitHub, HubSpot, Salesforce, and Linear exactly as your users would. Merge focuses on unified APIs and schema normalization, then exposes that surface to agents via its agent handler.

If your biggest challenge is auth, governance, and making multi-user agents production-ready, an authorization-first runtime like Arcade is likely the better foundation. If your biggest challenge is normalizing dozens of SaaS APIs, a unified API like Merge can simplify that layer, with agent support added on top.

Next Step

Get Started