Agent Security

MCP security for OpenClaw agents

A field checklist for connecting tools without handing every server, plugin, token, and file path the same level of trust.

Run the audit Security guide
01

Why MCP Security Matters

Tool reach is the real agent perimeter

MCP made it normal for agents to reach databases, files, browsers, SaaS APIs, private docs, calendars, and custom business systems through one protocol. That is useful. It also means the security boundary is no longer just the model prompt. It is the full tool graph around the agent.

OpenClaw's local-first shape helps because the operator controls the gateway, workspace, plugins, channels, and approval policy. The hard part is keeping that control explicit as more tools get connected.

Use three trust zones

Core tools

First-party or well-reviewed tools required for daily work: file reads, repo inspection, browser checks, search, and status commands.

Business tools

Tools that touch money, clients, private data, publishing, credentials, messaging, or production systems. These need narrower scopes and proof.

Experimental tools

New MCP servers, plugins, community skills, or local scripts. Keep them isolated until they have a reason, owner, config, and rollback path.

02

Inventory Every Tool

A tool without an owner becomes ambient authority

Before adding another MCP server or plugin, write down what it can read, what it can write, what credentials it uses, which channels can trigger it, and what evidence proves it ran safely.

Tool name:
Owner:
Purpose:
Read scope:
Write scope:
Secrets used:
Allowed channels:
Approval required for:
Logs/proof:
Rollback:
Last reviewed:

Prefer explicit allowlists

  • Files: allow specific directories instead of whole home folders.
  • Commands: allow command prefixes for repeatable work instead of shell-anything access.
  • Nodes: separate read paths, write paths, remote exec, camera, location, and browser control.
  • Channels: decide which chats can ask for which tools, especially in shared spaces.
03

Treat Plugins Like Code

Install trust, not just functionality

MCP servers, OpenClaw plugins, and skills can carry prompts, tool schemas, dependencies, auth flows, and local scripts. Review them like production code when they touch private systems.

1
Check source and maintainer

Know where the plugin came from, who maintains it, and whether the repo has recent, coherent activity.

2
Read requested permissions

Look for broad filesystem, network, shell, browser, or credential access that does not match the job.

3
Pin or review updates

Do not let high-risk plugins silently change behavior without a changelog, diff, or operator review.

4
Test with dummy data

Run first against a scratch folder, test account, or dry-run mode before connecting real credentials.

04

Keep Secrets Out of Prompts

Agents should reference credentials, not carry them

Recent OpenClaw work around SecretRef-style boundaries points in the right direction: agents need enough authority to use a credential through the right tool, not enough visibility to repeat the raw token into logs, chats, screenshots, or memory.

  • Never paste API keys into task prompts. Store them in the configured secret path or provider auth flow.
  • Separate read and write tokens. A reporting task usually does not need publishing rights.
  • Rotate after experiments. Temporary OAuth grants and test tokens should expire quickly.
  • Redact proof. Logs should show which credential class was used, not the credential value.
05

Gate High-Impact Actions

Approval policy should map to consequence

The fastest practical rule: read actions can be broad, reversible writes can be scoped, and external or destructive actions need approval unless the workflow has already been deliberately delegated.

Usually safe

Search, read-only diagnostics, local inspection, draft creation, summaries, linting, and status reports.

Scoped automation

Writing approved files, updating internal docs, committing owned changes, running builds, and refreshing generated assets.

Human gate

Emails, public posts, client messages, spending, deletions, live deploys, credential changes, and production data mutation.

06

30-Minute MCP Audit

A monthly routine for OpenClaw operators

0-5 min: list enabled MCP servers, plugins, skills, channels, and nodes
5-10 min: mark each as core, business, or experimental
10-15 min: check secrets, OAuth grants, env files, and token scopes
15-20 min: review write access, command access, and channel triggers
20-25 min: inspect recent failures, approvals, and surprising tool calls
25-30 min: remove unused tools, tighten scopes, and write the review note

The review note is part of the control

Save the outcome in workspace memory or an operations log: what changed, what stayed risky, which tokens were rotated, which tools were disabled, and when the next review should happen. If future agents cannot find the decision, the decision effectively did not happen.

07

Source Notes

This guide reflects the July 2026 OpenClaw release state: v2026.6.11 remains the latest stable npm release, v2026.7.1-beta.2 remains the current public beta, and recent project activity has emphasized diagnostics, update dry-runs, plugin management, scoped exec, credential boundaries, and channel delivery proof.

It also follows the broader agent trend: MCP and tool gateways are becoming the practical security perimeter because agents increasingly operate through connected tools rather than isolated chat windows.

Sources: OpenClaw releases • OpenClaw npm package • Microsoft MCP security discussion • Durable agent execution discussion