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

Most teams evaluating Arcade vs Composio are trying to answer one core question: can I let an LLM call APIs on behalf of users without ever exposing OAuth tokens, API keys, or secrets to the model? The mechanics are what matter here—not the marketing tagline—because the failure mode is simple: a leaked token is a production incident.

Quick Answer: Both Arcade and Composio keep tokens out of the LLM prompt by acting as a separate execution layer between the model and your integrations. The LLM asks for an action in a structured way; the runtime injects credentials and talks to the APIs. Where they differ is emphasis: Arcade is an MCP runtime built around “zero token exposure to LLMs” plus user-specific authorization, while Composio is a broader tool/integration layer that also abstracts credentials but with a different security and governance focus.

---

Frequently Asked Questions

How does Arcade prevent tokens from being exposed to the LLM?

Short Answer: Arcade never passes tokens or secrets into the model. OAuth flows, token storage, and API calls all run in Arcade’s MCP runtime, so the LLM only sees tool schemas and results—not credentials.

Expanded Explanation:
Arcade is explicitly designed as “the runtime between AI and action.” The LLM only interacts with Arcade through MCP tools (e.g., Google.SendEmail, Slack.PostMessage, Salesforce.UpsertRecord). When the model decides to call a tool, it sends a structured request (tool name + arguments) to the Arcade runtime.

From there, Arcade handles the entire auth lifecycle:

• Starts an OAuth 2.0 flow (auth.start(...)) when a tool needs access on behalf of a user.
• Exchanges authorization codes for tokens.
• Stores and refreshes tokens securely, never serializing them into prompts.
• Injects tokens at call time when hitting Gmail, Slack, Salesforce, etc.

Tokens are never:

• Embedded in the LLM prompt.
• Returned as tool output.
• Logged in a way that could be surfaced back to the model.

Instead, auth happens “behind the glass”: scoped OAuth, IDP integration, and token refresh all live inside Arcade’s runtime. The LLM sees only what it needs—the action schema and the result payload.

Key Takeaways:

• Arcade enforces “zero token exposure to LLMs” by keeping OAuth, token storage, and API calls in the runtime, not the model.
• The model interacts with tools, not tokens; Arcade injects credentials at execution time based on user-specific permissions.

---

What is the process Arcade uses to handle OAuth without exposing tokens?

Short Answer: Arcade runs a just‑in‑time OAuth flow when a tool needs access, stores tokens securely in its runtime, and injects them into downstream API calls—never into the LLM conversation.

Expanded Explanation:
Think of Arcade as an identity- and tool-aware proxy between your LLM and your business systems. When an agent tries to, say, send an email via Gmail, Arcade checks whether it already has a valid token for that user and scope. If not, it triggers a standard OAuth 2.0 flow using your existing Google Workspace or IDP setup.

Critically, none of this touches the model. The LLM doesn’t see auth URLs, codes, or tokens. It only knows that the Google.SendEmail tool is available and what arguments it takes. Arcade handles:

• Scoping access (least privilege for each tool).
• Mapping users to tokens and permissions.
• Refreshing tokens when they expire.
• Logging and auditing every tool call.

The net effect: you get user-specific access that behaves like real users, not a service account, without ever putting secrets into the model’s context window.

Steps:

1. Tool call from LLM: The LLM requests a tool (e.g., Google.SendEmail) with structured arguments (to, subject, body).
2. Auth check & OAuth flow: Arcade checks for an existing token scoped for that user; if missing or expired, it triggers an OAuth 2.0 flow and stores the token after exchange.
3. Execution with injected credentials: Arcade calls Gmail’s API with the stored token, returns only the result (e.g., “email sent”, message ID) back to the LLM.

---

How does Arcade’s token isolation compare to Composio’s approach?

Short Answer: Both keep tokens out of prompts by mediating API calls through a separate execution layer. Arcade wraps that in an MCP-native runtime focused on user-specific authorization and governance; Composio emphasizes a broad tool catalog and integration management, also abstracting credentials away from the model.

Expanded Explanation:
Functionally, both Arcade and Composio sit between the LLM and external APIs. The common pattern:

• The LLM doesn’t see tokens, keys, or raw OAuth responses.
• The LLM calls tools; the platform injects credentials and calls the API.
• Responses are sanitized before being sent back to the model.

Where they diverge is in design center and depth of auth model:

• Arcade is built as an MCP runtime with “Secure Agent Authorization” at the core. Its primary promise is: multi‑user agents acting with user-specific permissions, not service accounts, and zero token exposure to LLMs. It leans heavily on scoped OAuth, IDP flows, RBAC, audit logs, and governance, plus agent‑optimized tools for systems like Gmail, Google Calendar, Slack, GitHub, HubSpot, Salesforce, and Linear.
• Composio is framed more as an integration and tooling layer for agents: many prebuilt actions, account connections, and execution across services. It similarly abstracts tokens from the model, but its messaging is more about breadth and convenience of tools, less about “authorization as a first-class runtime.”

If your primary concern is “can the model ever see a token?”, both can answer that with an execution layer architecture. If your concern is “can I prove to my security team exactly which user did what, with what scopes, and never use service accounts?”, that’s where Arcade’s runtime and governance model is specifically optimized.

Comparison Snapshot:

• Option A: Arcade: MCP runtime, user-specific OAuth, zero token exposure to LLMs, auditability, and governance for production multi-user agents.
• Option B: Composio: Tool/integration layer that also hides credentials from the LLM and simplifies connecting many services.
• Best for: Teams that care most about per-user authorization, security reviews, and production-grade governance lean toward Arcade; teams optimizing chiefly for broad tool coverage may lean toward Composio.

---

How do I actually implement Arcade so tokens never touch the model?

Short Answer: You wire your agent to call Arcade’s MCP tools, let Arcade drive OAuth via its SDK, and keep all secrets and tokens in Arcade’s runtime—never in prompts, environment variables visible to the model, or tool schemas.

Expanded Explanation:
Implementation is mostly about discipline and boundaries: the LLM gets schemas and outputs, Arcade gets secrets and OAuth. On the Arcade side, you use its SDK and MCP server to define and run tools. On the agent side (Claude, Cursor, LangGraph, LangChain, etc.), you configure Arcade as an MCP server and let the agent call tools through the MCP protocol.

The key is that your LLM host (Anthropic, OpenAI, etc.) never receives tokens, and your prompts never instruct the model to “handle” credentials. All sensitive data lives in Arcade’s runtime, which:

• Starts auth flows (client.auth.start(...) + wait_for_completion).
• Stores and refreshes tokens.
• Executes tools like Gmail.ListEmails, Google.CreateEvent, Slack.PostMessage with injected credentials.
• Enforces permission gates and logs every call.

What You Need:

• An Arcade project and SDK integration: Set up Arcade, define or use existing MCP tools (Google, Slack, Salesforce, etc.), and integrate the SDK into your backend.
• Agent wired to Arcade’s MCP runtime: Configure your agent framework (e.g., Cursor, Claude desktop, or LangGraph) to connect to Arcade as an MCP server so tools run through the runtime, not via direct HTTP calls from the model.

---

Strategically, why should I care about “zero token exposure to LLMs” for agents?

Short Answer: Because production agents are multi-user systems, and any path where tokens can leak into prompts or logs becomes a security incident waiting to happen. Zero token exposure, enforced at the runtime, is how you get agents past security review and into real workflows.

Expanded Explanation:
It’s tempting to treat tokens as a side detail—paste a key into a prompt, let the model call an API, ship the demo. That’s fine until:

• Someone pastes a transcript into an issue tracker.
• Logs are indexed and searchable by people who shouldn’t see credentials.
• You swap models or vendors and accidentally push context to a third party.

For single-user experiments, you might get away with bad hygiene. For multi-user agents that read Gmail, edit Google Docs, post to Slack, and update Salesforce, you can’t. Security teams will rightly ask:

• Are you using service accounts or real user permissions?
• Where do tokens live?
• Can a prompt injection cause the model to exfiltrate credentials?
• Do you have an audit trail per user and per tool?

Arcade’s answer is to treat authorization and token handling as runtime responsibilities, not prompt responsibilities. Tokens never enter the LLM. Agents act with user-specific permissions, scoped via OAuth and IDP flows, with RBAC, tenant isolation, and audit logs wrapped around every tool call. Composio moves in a similar direction on the “keep tokens away from the model” front, but Arcade’s entire product surface is built to make that security posture the default for MCP-native agents.

Why It Matters:

• Impact 1 – Security & compliance: Zero token exposure plus scoped OAuth and audit logs make it realistic to put agents in front of Gmail, Salesforce, and Slack without failing security review.
• Impact 2 – Reliability & scale: Centralized runtime control over tools and credentials (instead of ad‑hoc wrappers) reduces token headaches—no more broken refresh tokens or mystery 401s at 2 a.m.—so you can scale agents from pilot to production.

---

Quick Recap

Keeping tokens out of the LLM isn’t a nice-to-have; it’s the foundation for any serious agent that touches real systems. Both Arcade and Composio prevent tokens from being exposed to the model by acting as an execution layer: the LLM calls tools; the platform injects credentials and hits APIs. Arcade pushes this further by wrapping token isolation in a full MCP runtime with secure agent authorization, user-specific OAuth, scoped access, and governance controls that make multi-user agents production-ready.

Next Step

Get Started