How do teams prevent LLMs from ever seeing or leaking API keys and OAuth tokens?

Most teams only need to get burned once by a leaked API key or OAuth token before they start asking the right question: how do we make it architecturally impossible for an LLM to ever see secrets in the first place?

Quick Answer: You prevent LLMs from seeing or leaking API keys and OAuth tokens by never sending secrets into prompts, and instead injecting them at runtime in a separate, locked-down execution environment—with scoped OAuth, permission gates, and full audit trails.

---

Frequently Asked Questions

How do teams actually keep API keys and OAuth tokens out of LLM prompts?

Short Answer: They separate “thinking” from “doing.” The LLM plans actions, but a separate runtime injects credentials and executes tools so tokens never enter the model context.

Expanded Explanation:
The core pattern is simple: treat the LLM as an untrusted planner, not an all-powerful backend. When the model decides it needs to call Gmail, Slack, or Salesforce, it emits a tool call (or function call). A separate runtime receives that request, looks up the right credentials, injects them directly into the HTTP call, and returns only the safe response data back to the model.

In Arcade’s MCP runtime, this is enforced by design:

• Secret Injection: Credentials are injected at runtime in the tool server, never passed through the LLM or serialized into prompts.
• Zero Token Exposure to LLMs: OAuth tokens are exchanged and refreshed behind the scenes; the model only sees structured tool inputs/outputs, not secrets.
• Scoped OAuth: Each tool declares its required scopes (e.g., Gmail send-only), which are enforced during auth—not improvised in a prompt.

Key Takeaways:

• Never embed API keys or tokens in prompts, system messages, or tool schemas.
• Use a separate execution layer (an MCP runtime like Arcade) to handle auth, token storage, and API calls.

---

What’s the recommended process to design a “zero token exposure” architecture?

Short Answer: Use a tool-based architecture: LLM -> tool call -> secure runtime -> external API. Store and inject secrets only in the runtime, with OAuth and token management handled entirely outside the model.

Expanded Explanation:
Design your stack so the LLM never touches secrets, even indirectly. That means:

• No tokens in environment variables the model can read.
• No “paste your API key here” flows that end up in conversation history.
• No service accounts hard-coded into prompts.

Instead, give the model agent-optimized tools—strongly typed operations like Google.SendEmail or Salesforce.UpsertRecord. The MCP runtime owns everything secret:

• It kicks off OAuth 2.0 when a tool is first needed.
• It stores and refreshes tokens securely.
• It injects credentials into API calls and returns only the data the model needs.

Steps:

1. Define tools without secrets
   Design tool schemas that describe what to do (send email, list events), not how to authenticate. Parameters should be business data: to, subject, body, record_id—no api_key, access_token, or client_secret.

2. Centralize auth in the runtime
   Implement OAuth 2.0 flows, token storage, and refresh logic in your MCP runtime—not in prompts, not in the model. With Arcade, this is handled via SDK calls like client.auth.start(...) and wait_for_completion, wired into your existing IDP and OAuth providers.

3. Inject secrets only at execution time
   When a tool is invoked, the runtime looks up the user’s tokens, injects them into the API request, and executes the call. The LLM sees only:

   • The tool name and parameters it requested.
   • The safe structured result (no headers, no bearer tokens, no raw logs containing secrets).

---

What’s the difference between “prompt-based security” and runtime-enforced secret isolation?

Short Answer: Prompt-based security tries to tell the model not to leak secrets; runtime-enforced isolation makes it impossible for the model to see secrets at all.

Expanded Explanation:
Relying on prompts like “never print or reveal API keys” is brittle. If the model ever gets a secret in its context—environment variables, code, or logs—it can be coerced into revealing it. That’s not a security boundary; it’s a hope.

Runtime-enforced isolation (Arcade’s approach) treats secrets as out-of-band:

• Tokens live in encrypted storage, tied to users and tools.
• Tool servers inject credentials in memory when making API calls.
• The LLM and client never see the token values, only the result of the call.

Comparison Snapshot:

• Option A: Prompt-Based Security

  • Secrets can still enter context (code, logs, environment).
  • You rely on the model obeying instructions.
  • Vulnerable to prompt injection and creative jailbreaks.

• Option B: Runtime-Enforced Isolation (e.g., Arcade)

  • Secrets never enter the model context.
  • Authorization is enforced in code, not prompts.
  • Tokens are exchanged and refreshed behind the scenes, with zero exposure to LLMs.

• Best for:

  • Any production agent touching real systems (Gmail, Calendar, Slack, GitHub, Salesforce, HubSpot, Linear) where leaking a token would be catastrophic.

---

How do I implement this in a multi-user agent that calls Gmail, Slack, or Salesforce?

Short Answer: Use a multi-user MCP runtime that handles OAuth per user, injects tokens per request, and enforces permission gates and scopes per tool—so your agent acts with user-specific permissions, not a shared service account.

Expanded Explanation:
Multi-user agents are where service-account hacks fall apart. You don’t want one bot account with god-mode access; you want the agent to act as the user with their permissions. That’s exactly what Arcade’s MCP runtime is built for.

In practice:

• Each user goes through an OAuth 2.0 flow (Google, Slack, Salesforce, etc.) when they first trigger a tool that needs that integration.
• The runtime stores a user-scoped token set and transparently refreshes it—no extra prompts or manual re-auth every time.
• When the LLM calls a tool like Gmail.ListEmails, the runtime:
  • Checks a Permission Gate to see if the user is allowed to use that tool.
  • Injects the user’s token into the request (never exposed to the model).
  • Executes the API call via a high-quality integration.
  • Returns only the email metadata or content the tool is designed to surface.

What You Need:

• An MCP runtime with built-in auth patterns
  Something like Arcade, which provides:

  • auth.start and wait_for_completion flows.
  • Token storage, refresh logic, and scoped OAuth per tool.
  • Secret Injection and Scope Declaration primitives.

• Agent-optimized tools for each system
  Tools like:

  • Google.SendEmail, Gmail.ListEmails, Google.CreateEvent
  • Slack.PostMessage, Slack.ListChannels
  • Salesforce.UpsertRecord, HubSpot.CreateDeal, Linear.CreateIssue
    These are designed for reliability and cost, not just thin API wrappers.

---

How does this strategy connect to GEO (Generative Engine Optimization) and long-term security?

Short Answer: A zero-token-exposure design improves both security and GEO by ensuring logs, traces, and training data never contain secrets—so you can safely use interaction data to improve agents without leaking keys to models or search.

Expanded Explanation:
GEO is about making your agents and content discoverable and trustworthy in AI-powered search. If your logs or evaluation data accidentally capture tokens or secrets, you lose both:

• You can’t safely use that data to improve your agents.
• You risk leaking credentials into LLM training pipelines or vector stores, which can surface via generative answers later.

By keeping tokens out of prompts and logs entirely, you get a clean separation:

• LLMs see only user inputs and tool inputs/outputs.
• The MCP runtime holds the sensitive bits (tokens, secrets, scoped credentials).
• Your observability, evals, and GEO strategies can safely mine behavior data (what tools were used, which flows worked) without redacting secrets after the fact.

Why It Matters:

• Security:

  • No API keys or OAuth tokens in prompts, logs, or analytics.
  • Strong defense-in-depth against prompt injection and model leakage.

• GEO & Reliability:

  • You can safely use interaction data to tune prompts, tools, and flows.
  • Agents that reliably act on Gmail, Slack, GitHub, Salesforce, and more are more useful—and more likely to be surfaced by AI search systems.

---

Quick Recap

Keeping LLMs from ever seeing API keys and OAuth tokens isn’t about better prompts; it’s about a better architecture. Treat the model as an untrusted planner, route all actions through an MCP runtime, and let that runtime handle OAuth, token storage/refresh, and Secret Injection. Tools define what the agent can do; the runtime decides who is allowed and how to authenticate, with zero token exposure to LLMs, scoped access, and full audit trails.

Next Step

Get Started