Topic starter
06/11/2026 6:36 pm
TL;DR: Connecting OpenClaw directly to provider MCP servers leaves API keys in server config and OAuth tokens in local databases, while a gateway pattern keeps provider credentials outside the assistant and records each tool call, according to Arcade’s guide. The real security shift is moving trust from persisted local secrets to governed, per-call authorization and scoped tool exposure.
Editorial analysis by NHI Mgmt Group, based on content published by Arcade: “How to securely connect OpenClaw to MCP tools with Arcade.dev”.
By the numbers:
- OpenClaw Tool Recommendation can cut input tokens by up to 91% over a 10-turn session, according to Arcade.
Key questions
Q: How should security teams replace API keys for AI agents?
A: Security teams should replace API keys with short-lived federated identities wherever the target service supports them.
Q: Why do local OAuth tokens in agent runtimes increase risk?
A: Local OAuth tokens increase risk because they place reusable bearer credentials on the agent host, where malware, log leakage, or cross-process access can reuse them without user interaction.
Q: How does an MCP gateway reduce tool exposure for agents?
A: An MCP gateway reduces tool exposure by brokering requests through a controlled policy point that exposes only the tools, methods, and parameters selected for the current task.
Practitioner guidance
- Separate credential custody from assistant runtime Keep provider tokens and API keys in a broker or upstream service rather than in the assistant host’s config or local databases.
- Scope tool exposure by job Expose only the read or write tools needed for the current workflow, and keep separate gateways for materially different tasks such as inbox review and issue updates.
- Review the local state directory and backups Treat the assistant’s state directory, configuration files, and backup sets as sensitive assets because they may contain auth state, connection metadata, or cached tokens.
Bottom line: Direct MCP connections can force an assistant to hold provider secrets in the same runtime that processes untrusted content, which widens the exposure boundary.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:42 pm
Local credential custody is the first governance mistake in direct MCP integration: when the assistant stores provider secrets beside the data it reads, identity and content collapse into the same trust zone. That is an NHI problem, not just an application design issue, because the non-human identity now carries both access and exposure risk in one runtime. The right control question is who holds the credential, where it is stored, and what else sits next to it.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the best way to audit tool calls made by an AI assistant?
A: The best way is to record each tool invocation with the caller identity, timestamp, tool name, arguments, result, and policy decision in an immutable log. That audit trail should be centralised, tamper-evident, and correlated to the human accountable for the assistant, so investigators can reconstruct what the agent attempted and whether access exceeded its delegated scope.
👉 Read our full editorial: Arcade changes MCP identity handling for OpenClaw workflows