openclaw - 💡(How to fix) Fix Feature Request: Protect secret tokens in config from model context leakage (headers, URLs) [1 participants]

Feature Request

Problem

openclaw.json contains sensitive credentials that get injected into the system prompt and agent context via workspace files (e.g., TOOLS.md, AGENTS.md, project context blocks). This means LLM models can potentially read:

1. Bearer tokens in MCP server URLs — e.g., MCP server configs with ?key=<SECRET_KEY> embedded in plain text
2. API keys in channel config — Telegram botToken, Matrix accessToken appear in full in the config
3. Gateway auth tokens — gateway.auth.token visible in system context
4. Any token in URL query parameters — ?key=xxx, ?token=xxx patterns
5. Any token in custom headers — Authorization: Bearer xxx, X-API-Key: xxx

The real danger: When agents are given full config access, the model receives all secrets in context. A compromised or malicious model (or one that is jailbroken) can exfiltrate these credentials through its responses.

Current situation

• openclaw.json secrets appear in agent session context
• Auth profiles (auth.profiles) are visible to agents
• Channel credentials (botToken, accessToken) are loaded into context
• MCP server URLs with embedded keys (?key=xxx) are loaded into context
• No redaction of these values before they reach the model

Proposed solutions

1. Auto-redact secrets in agent context

   • Replace token values with [REDACTED] markers in the prompt/context sent to models
   • Support patterns: ?key=..., ?token=..., Authorization: Bearer ..., botToken, accessToken, gateway.auth.token

2. Secret scope isolation

   • Introduce a scope: "secret" or scope: "system" annotation for config keys
   • Values with this scope are available to the gateway runtime but NOT injected into model context
   • Similar to how redactSensitive: "tools" currently works for tool outputs

3. URL-level key extraction

   • Parse MCP/tool URLs and extract ?key=, ?token= parameters into separate secret references
   • Store them as secret refs instead of plaintext URLs

4. Header-level token protection

   • Allow headers in tool/MCP config to use secret ref syntax
   • Gateway resolves at runtime, model only sees the ref metadata, not the actual token value

5. Extend secret ref support for URL tokens

   • Extend the 2026.3.28 env secret ref feature to also support URL query parameters

Priority

High — This is a security concern. Any agent with config-reading capability (which is the default) exposes all embedded credentials to third-party LLM providers.

Suggested labels

security, enhancement, auth, secret-management, context-isolation