Arcade vs Composio: how do they prevent tokens from being exposed to the LLM?

Most teams deploying production agents eventually hit the same wall: how do you let an LLM call real APIs without ever letting tokens touch the model? This is the core design question behind both Arcade and Composio, and it’s the difference between a cute demo and something your security team will sign off on.

Quick Answer: Both Arcade and Composio prevent tokens from being exposed to the LLM by acting as an execution layer between the model and third‑party APIs. The LLM only sees tool schemas and results, while each platform handles OAuth, stores tokens, and injects credentials at runtime outside the model context — but they differ in how deeply they focus on authorization, MCP runtime behavior, and multi‑user governance.

Frequently Asked Questions

How does Arcade keep OAuth tokens away from the LLM?

Short Answer: Arcade terminates OAuth flows, stores tokens, and injects them into tools at runtime, with zero token exposure to LLMs. The model only sees MCP tools like Google.SendEmail and their outputs, never raw credentials.

Expanded Explanation:
Arcade is an MCP runtime purpose‑built to sit between AI and action. When an agent wants to do something in a real system (send Gmail, create a Calendar event, post to Slack, update Salesforce), the LLM calls an Arcade MCP tool. Arcade then:

• Runs a secure OAuth 2.0 flow with scoped access (least‑privilege)
• Stores and refreshes tokens server‑side
• Executes the API call on behalf of the user
• Returns only the structured result back to the LLM

Tokens are exchanged “behind the scenes,” never serialized into the model prompt, tool arguments, or logs that the LLM can see. Auth only runs when a tool is needed; there’s no blanket “log in to everything up front” step. This design means the LLM cannot leak tokens in its output, because they’re never in its context window to begin with.

Key Takeaways:

• OAuth tokens terminate in Arcade’s runtime, not in the LLM or client.
• Arcade injects credentials at tool execution time, keeping tokens completely out of prompts and model-visible logs.

---

What is the typical process for an agent call with Arcade so that tokens stay hidden?

Short Answer: The LLM calls an Arcade MCP tool, Arcade handles just‑in‑time OAuth and API execution, then returns sanitized results — with all identity, token, and secret handling isolated in Arcade’s backend.

Expanded Explanation:
Think of the flow as “model → tool schema → Arcade runtime → provider API,” with strict boundaries. The agent never holds tokens; it just requests an action. Arcade’s SDK and runtime handle auth, execution, and governance.

Steps:

1. Tool call from the LLM
   The agent decides to act and calls a tool like Google.SendEmail or Gmail.ListEmails via MCP. The LLM passes only high‑level parameters (recipient, subject, filters), not any secrets.

2. Auth & token resolution in Arcade
   Arcade checks whether this user has already authorized Gmail/Google Workspace with the right scopes. If not, it starts a scoped OAuth 2.0 flow (auth.start, redirect to Google, etc.), stores tokens server‑side, and ties them to the user and tool.

3. API execution & safe response
   Arcade injects the appropriate access token into the outgoing API request, calls Gmail/Google Calendar/Slack/etc., and returns a structured response back through the MCP tool. The LLM only sees the result (e.g., “email sent, id=1234”), never the token or raw headers.

---

How is Arcade’s approach different from Composio’s when it comes to LLM token exposure?

Short Answer: Both isolate tokens from the LLM, but Arcade does it as an MCP runtime centered on secure, user-specific authorization and governance, while Composio is more integration‑layer focused; Arcade emphasizes multi-user auth, scoped permissions, and zero token exposure as first‑class runtime behavior.

Expanded Explanation:
At a high level, both Arcade and Composio share the same core pattern: keep credentials off the model and centralize API execution in a separate service. The differences are in emphasis and surface area:

• Arcade is the “runtime between AI and action,” designed around MCP, multi‑user authorization, and tool reliability. Tokens never leave Arcade’s controlled environment; OAuth, IDP integration, RBAC, and audit logs are part of the runtime itself.
• Composio acts as an integration and tool layer so LLMs can call external services via tools or functions, with token management handled by Composio instead of your model. It also avoids putting tokens directly into prompts.

From a token‑exposure standpoint, both aim for a similar outcome (tokens never reach the LLM), but Arcade goes deeper on enterprise controls and per‑user authorization models for agents that need to operate safely across many users and systems.

Comparison Snapshot:

• Option A: Arcade MCP Runtime
  • Zero token exposure to LLMs, enforced by design.
  • Scoped OAuth with user-specific permissions, IDP integration, RBAC/SSO/SAML, tenant isolation, and audit trails.
  • MCP-native tools (Google.SendEmail, Google.CreateEvent, Slack, GitHub, Salesforce, etc.) optimized for reliability and multi-user agents.
• Option B: Composio
  • Integration-first tool layer that also keeps tokens away from the model.
  • Focus on connecting LLMs to many services with a unified tool abstraction.
  • Governance and auth semantics depend more on how you wire it into your stack.
• Best for:
  • Arcade fits teams that need production-grade, multi-user agents with clear auth boundaries, scoped permissions, and governance.
  • Composio fits teams primarily optimizing for faster integration coverage with LLM tools, with security models layered on top.

---

How do you actually implement Arcade so that agent tools run with user-specific tokens, not service accounts?

Short Answer: You plug Arcade’s MCP runtime into your agent (Claude, Cursor, LangGraph, etc.), use its SDK to start OAuth flows (auth.start) and call tools, and Arcade handles per‑user tokens, permission scopes, and token refresh behind the scenes — without exposing tokens to the LLM.

Expanded Explanation:
The implementation pattern is deliberately minimal‑ceremony: Arcade gives you SDK calls plus MCP‑compatible tools, and you wire them into your existing agent loop. The LLM sees “here’s a Gmail tool” – Arcade sees “this is user X, with these OAuth scopes.”

Typical setup looks like:

• Register your app with Google, Slack, GitHub, Salesforce, etc. and plug client IDs/secrets into Arcade.
• Use Arcade’s SDK to kick off and complete auth flows when tools are needed (no “DIY OAuth” glue).
• Let your MCP client (Cursor, Claude, LangGraph, LangChain) call Arcade tools; Arcade enforces which user is acting, with what scopes.

Tokens are isolated in Arcade’s runtime, so your application code never has to serialize them into the prompt or expose them to the LLM.

What You Need:

• An agent framework that can talk MCP (e.g., Claude, Cursor, LangGraph, LangChain with MCP).
• Arcade account + SDK configured with your OAuth credentials and desired tools (Gmail, Calendar, Slack, Salesforce, GitHub, etc.).

---

Strategically, why does token isolation and user-specific authorization matter for production agents?

Short Answer: Keeping tokens out of the LLM and enforcing user-specific permissions is what turns a demo into a deployable system; it prevents data leaks, matches real-world access controls, and keeps security teams from blocking your rollout.

Expanded Explanation:
Most agent demos cheat on auth: they rely on a single service account, hardcoded tokens, or tokens shoved into the prompt. That works in a sandbox, but it breaks the moment you need:

• Multiple users with different permissions
• Clear audit trails of who did what, when, and under which scopes
• Compliance with internal security policies and external regulations

By centralizing token handling in a runtime like Arcade, you get:

• User-specific authorization: Agents act as the actual user, not a flat service account, so Gmail/Slack/CRM actions respect existing permissions.
• Zero token exposure to LLMs: Tokens can’t leak via model outputs, logs, or prompt injections, because they never enter the model’s context.
• Governance & observability: Security teams see scopes, tool calls, tenants, and can apply RBAC, SSO/SAML, and audit policies across agents.

This is why teams like LangChain and Snyk explicitly call out Arcade’s sweet spot: it nails the intersection of AI, auth, and developer experience so you’re not debugging refresh tokens at 2 a.m. or losing weeks in security review explaining why your LLM never sees tokens.

Why It Matters:

• Impact on security: Reduces the blast radius of any agent or prompt failure by keeping secrets out of the model entirely.
• Impact on adoption: Makes it realistic to move from a single demo agent to multi‑user, production deployments your security and compliance teams can approve.

---

Quick Recap

Arcade and Composio both prevent tokens from being exposed to the LLM by inserting a runtime between the model and external APIs. The LLM calls tools; the runtime handles OAuth, stores tokens, injects them into API calls, and returns only sanitized results. Arcade leans in as an MCP runtime focused on secure, user-specific authorization, zero token exposure to LLMs, and governance features like scoped OAuth, IDP integration, RBAC/SSO/SAML, and audit trails — especially suited for multi-user agents that need to operate safely across Gmail, Google Calendar, Slack, GitHub, Salesforce, and more.

Next Step

Get Started