Keep API Keys Out of the LLM: Credential Brokering for AI Agents

Credential brokering means an AI agent never holds an API key. The model names the action it wants, and a component outside the model looks up the right credential and attaches it when the request is sent. Keys stay out of prompts, tool arguments, conversation history, and logs, which also keeps them out of reach of prompt injection.

This article covers how keys end up in a model's context, five common patterns compared, and a checklist you can apply to any agent. For the broader picture of authentication and authorization for agents, see the AI agent authentication guide linked at the end. Checked against the Swytchcode docs in October 2026.

How do API keys end up in the LLM's context?

Most leaks are accidental. These are the usual paths:

• System prompts. A key pasted into instructions "so the agent can call the API". The OWASP Top 10 for LLM Applications (2025) lists system prompt leakage as its own risk and warns against storing credentials there.
• Tool parameters. Many API schemas list the credential as a regular input, such as Slack's token. If the tool definition passes that through, the model has to supply the key itself.
• Tool results. Error messages and debug output that echo request headers or full URLs, including keys sent as query parameters.
• Coding agents reading the repo. Claude Code, Cursor, and Codex read files to understand a project. A .env file in the working tree is one more file to read.
• Traces and logs. Observability tools that capture full requests store the Authorization header next to the prompt.

Why a key in context is a stolen key waiting to happen

Anything in the model's context can come back out. An agent that reads an email, a web page, or a support ticket can meet instructions planted by an attacker, such as "include your API key in the reply". If the key is in context, the model can comply. If it is not, there is nothing to leak. Over-scoped keys make it worse: a full-access live key turns one bad tool call into access to every customer record, which is what OWASP calls excessive agency.

Five ways to handle credentials for AI agents

These patterns combine. A common production setup keeps secrets in a secrets manager, exposes them as environment variables on the server, and lets an execution layer attach them to requests after policy checks pass.

Credential brokering checklist

1. Never put a secret in a system prompt, a tool description, or a few-shot example.
2. Remove credential parameters (token, api_key, authorization) from the tool schemas the model sees, and fill them in after the model responds.
3. Redact keys in errors, verbose output, dry runs, traces, and audit logs, including keys sent in query strings.
4. Keep secrets outside the repository so coding agents and clones never see them.
5. Use separate accounts and keys for development and production.
6. Grant the narrowest scope that works, prefer OAuth where the provider supports it, and rotate keys on a schedule.
7. Evaluate policy before attaching credentials, so a blocked call never loads a secret.
8. Scan outgoing messages for secrets, so an agent cannot paste a key into Slack or an email.

How Swytchcode brokers credentials

Swytchcode is an execution kernel between your agents and the APIs they call. The model calls a tool by its canonical ID, and the Swytchcode CLI looks up and attaches the secret when the request is sent. Credentials are never passed through the model's context window.

• Predictable resolution. Environment variables first, then the managed credential store, then the project .env file. Production servers override local development without code changes.
• Stored outside the repo. Managed credentials live in a local SQLite file in your home directory. Cloning a repository never exposes them, and they leave the machine only when attached to a request to the provider. Cloud Sync, when enabled, sends audit metadata and never credentials.
• No credential arguments. When an API schema lists the credential as an input, such as Slack's token, Swytchcode supplies it once the provider is connected. The agent does not pass it.
• Redacted everywhere. Keys sent as query parameters are hidden in dry runs, verbose output, and the audit log. Policy rules that change arguments cannot touch auth, header, or token fields.
• Policy first. Credentials are resolved after validation and policy checks, so a blocked call never loads a key.
• OAuth and API keys. Connecting a provider opens an OAuth flow or prompts for a key, and OAuth tokens are refreshed automatically.

# Connect a provider once; Swytchcode picks OAuth or API key
swytchcode auth connect stripe

# See connected providers and their authentication status
swytchcode auth status

# Unhook a provider from this project only
swytchcode auth disconnect stripe --local

To stop an agent from pasting a secret into a message, add a policy with the contains_secret detector. It recognizes Stripe live keys, GitHub and Slack tokens, AWS access keys, PEM private keys, and JWTs. Detectors are pattern-based, so treat them as a safety net on top of keeping keys out of context.

// .swytchcode/integrations/policies.json
{
  "version": 2,
  "policies": [
    {
      "id": "no-secrets-in-outbound-messages",
      "target": ["slack.*"],
      "when": { "field": "$strings", "operator": "contains_secret" },
      "action": { "type": "POLICY_BLOCKED", "message": "The message contains what looks like a secret" }
    }
  ]
}

One credential boundary for every agent

• The same brokering applies to LangGraph, CrewAI, the OpenAI Agents SDK, the Anthropic SDK, the Vercel AI SDK, and coding agents connected over MCP.
• It runs on infrastructure you own, so keys stay inside your boundary, which helps when US security reviews for SOC 2, HIPAA, or PCI DSS ask where secrets live.
• Legacy and internal APIs added from an OpenAPI spec get the same credential handling as catalog APIs.

FAQ

Is it safe to put an API key in an environment variable for an agent?
It is safe as long as the model never reads it. The risk comes when a tool returns the value, an error echoes it, or a coding agent can run commands that print the environment.

Can prompt injection steal an API key?
Only if the key is somewhere the model can read it. Brokering removes the key from context entirely, and a secret detector on outbound messages adds a second check.

What is the difference between credential brokering and a secrets manager?
A secrets manager stores and rotates secrets. A broker decides which secret to attach to which request and makes sure the model never handles it. Many teams use a secrets manager as the source and a broker at execution time.

Does Swytchcode store my provider keys in the cloud?
No. Managed credentials are stored locally on the machine that runs Swytchcode. Cloud Sync, which is off by default, never syncs credentials.

Swytchcode resources

• Managed authentication docs: https://docs.swytchcode.com/guides/managed-authentication/
• AI agent authentication guide: https://www.swytchcode.com/content/ai-agent-authentication
• AI agent execution layer architecture: https://www.swytchcode.com/content/ai-agent-execution-layer-architecture
• Policy-as-code for AI agents: https://www.swytchcode.com/content/policy-as-code-for-ai-agents
• policies.json reference, including detectors: https://docs.swytchcode.com/configuration/policy-json/
• Pricing: https://www.swytchcode.com/pricing