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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Arcade's blog post: OpenClaw’s direct MCP integrations expose provider credentials locally, while a gateway model keeps tokens outside the assistant and authorizes each call separately.
Why it matters: This matters because IAM teams need to decide where credential custody, consent, logging, and revocation sit when agents call Gmail, Linear, and other services through MCP.
By the numbers:
- OpenClaw Tool Recommendation can cut input tokens by up to 91% over a 10-turn session, according to Arcade.
Context
OpenClaw’s direct MCP setup creates a familiar governance problem: the assistant can function only if it also holds the provider credentials it needs to act. That means API keys, OAuth tokens, and local state can sit in the same place as the content the agent reads, which expands the exposure surface when the system is scheduled or used against everyday accounts.
A gateway pattern changes custody and control. Instead of treating each provider connection as a separate local secret store, the assistant calls a broker that can scope tools, mediate authorization, and keep provider tokens out of the assistant’s own runtime. MCP security guidance becomes the right reference point for this model.
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. The goal is to remove standing secrets from agent workflows and shift trust to verifiable identity assertions, policy checks, and lifecycle-managed access. That reduces blast radius, improves auditability, and makes compromise far less persistent.
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. If the token also grants refresh capability or broad scopes, compromise of one runtime can extend into the assistant host into both data access and downstream APIs, so scope restriction, short lifetimes, and host isolation matter.
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. It can enforce allowlists, schema checks, authentication, and per-agent scope, so the agent never reaches every backend tool directly and gains only the minimum callable surface.
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.
Technical breakdown
Why direct MCP connections expand the credential surface
In a direct MCP model, the assistant or its host stores the credential material needed to reach each provider. That can include API keys in configuration files and OAuth tokens in local databases or state directories. The risk is not just theft at rest. Once the assistant can read messages, issues, or other live content, the same runtime becomes a place where sensitive tokens and sensitive data coexist, which increases the chance of accidental disclosure, prompt-injection abuse, or filesystem exposure. See the API Key Management Guide.
Practical implication: Treat local storage of provider credentials as part of the trust boundary, not as implementation detail.
How a gateway changes MCP authorisation and custody
A gateway centralises tool exposure and separates the assistant’s runtime from the provider credential. The assistant sends a request to the gateway, the gateway obtains or uses the upstream authorization context, and the resulting tool call can be recorded and governed independently. This does not eliminate risk, but it narrows where credentials live and makes per-call policy, logging, and revocation easier to reason about than many direct integrations spread across local state.
Practical implication: Use a mediation layer when multiple tools and providers would otherwise force the assistant to hold long-lived credentials.
Why tool recommendation matters for agentic tool exposure
When an agent loads every available tool schema, it carries more context than many tasks actually require. Tool recommendation reduces that surface by presenting only the tools needed for the current job, which lowers token load and reduces the chance that the model will reason over irrelevant capabilities. In governance terms, this is a scope-reduction control for agentic tool use: smaller visible tool sets mean fewer accidental or malicious paths through the workflow. Read OWASP Agentic Applications Top 10.
Practical implication: Limit tool visibility per task so the agent cannot browse unnecessary capabilities during execution.
Threat narrative
Attacker objective: The attacker aims to recover reusable provider credentials or abuse the assistant’s connected tools to access mail, issues, and other linked services.
- Entry occurs when an operator connects the assistant to provider services through MCP and places API keys or OAuth tokens in local configuration or database storage.
- Credential access follows because anyone with filesystem access can read those stored secrets, and the assistant may also process provider content in the same runtime.
- Impact is broader tool misuse or token exposure across email and work-management workflows, especially when scheduled jobs keep running against everyday accounts.
Breaches seen in the wild
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Per-call authorization is more defensible than standing assistant custody of provider tokens: a brokered model lets the assistant request an action without becoming the permanent holder of the provider secret. That shifts the control point from persistence to use, which is where NHI governance is strongest. NHI authentication guidance is relevant because the authentication model, not the model size, determines whether the connection can be governed cleanly.
Tool minimisation is a governance control, not just a performance optimisation: loading only the schemas needed for the current task narrows what the agent can attempt and what an attacker can steer it toward. The named concept here is identity blast radius: the smaller the visible tool set, the smaller the set of actions that credential compromise or prompt injection can influence.
Scheduled agent jobs turn local secret handling into a persistence problem: once the assistant runs repeatedly against real accounts, a one-time setup error becomes a standing exposure window. That assumption fails when the actor operates on its own schedule and can repeatedly touch the same credentials without fresh human review. Practitioners should re-evaluate every control that assumes access is short-lived or manually observed.
Execution logging only helps if the credential boundary is already correct: recording tool calls is valuable, but logs do not compensate for a design that keeps provider secrets inside the assistant host. The implication for the field is that auditability must be paired with custody separation, otherwise the log becomes a post-incident record of a bad trust model.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
Identity blast radius: The more provider credentials and tool definitions that sit inside the assistant runtime, the larger the blast radius when a prompt injection or filesystem exposure occurs. Governance needs to move from static possession of secrets to mediated use, because the important question is no longer whether the assistant can connect, but whether it can do so without becoming the credential holder.
Per-call authorization and task-scoped tool visibility are becoming the practical floor for agent governance, especially where assistants interact with email, issue tracking, and other everyday business systems. According to the State of Secrets Sprawl 2026, DeepSeek alone generated 113,000 new exposed API keys in 2025, a reminder that new AI integrations create credential exposure faster than most controls adapt.
The operational signal to watch is whether teams can separate authentication, tool selection, and execution logging into distinct layers. When those layers are collapsed into one local runtime, revocation gets harder, review becomes noisier, and the assistant starts to look less like a client and more like a credential custodian.
For practitioners
- 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. The goal is to remove reusable secrets from the same environment that processes untrusted content.
- 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.
- Verify every delegated call in execution logs Check that the recorded tool call matches the expected user, task, and outcome before enabling write actions or scheduled automations.
- Use read-only workflows first Test a gateway connection with mailbox or issue reads before allowing any action that can modify content, then confirm the exact call path in the execution record.
Key takeaways
- Direct MCP connections can force an assistant to hold provider secrets in the same runtime that processes untrusted content, which widens the exposure boundary.
- A gateway model improves custody and auditability by separating provider credentials from the assistant host and by mediating each tool call.
- Limiting tool visibility by task is not just a usability choice, because it reduces the action surface that compromised credentials or prompt injection can influence.
Related NHI Mgmt Group resources: API Key Management Guide · MCP Security Guide · NHI Authentication Guide · OWASP Agentic Applications Top 10
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Provider tokens stored in local databases and config files are the central exposure risk here. |
| NHI-04 — Insecure Authentication | The article hinges on how assistants authenticate to remote tools through OAuth and header-based access. | |
| NHI-10 — Human Use of NHI | Operators connect and approve non-human access paths that can cross into everyday business accounts. | |
| Recommendation — Keep provider credentials out of the assistant host and revoke any secret that can be read locally. Use mediated authentication paths that prevent the assistant from becoming the credential holder. Separate operator approval from runtime credential custody so human action does not create standing NHI access. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent tool use and delegated authority are central to the risk discussion around OpenClaw workflows. |
| Recommendation — Constrain agent privileges to the smallest task scope and validate every delegated action path. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The gateway model is fundamentally about governing what the assistant can access and invoke. |
| Recommendation — Enforce task-scoped permissions and review delegated access before enabling write actions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | API keys and OAuth tokens are authenticators whose storage and revocation determine exposure. |
| Recommendation — Manage credential issuance, storage, and revocation so authenticators are not left in local state. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The threat pattern involves reading stored tokens and using them to access downstream services. |
| Recommendation — Map local token exposure to credential access and watch for downstream abuse of connected services. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
- API Key: A unique identifier used to authenticate a software application or service when calling an API. API keys are static, long-lived credentials and a major source of secrets sprawl. In 2024, over 50 million leaked API keys were found on the dark web.
- MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org