// Agent tools · safety
MCP & agent safety checklist
Before you install an MCP server or switch on auto-approve: what can go wrong, and the few settings that prevent most of it. Distilled from the official MCP security guides.
6 risk typeschecked 2026-10-22based on modelcontextprotocol.io
01Six things that go wrong
Each item links to the official source it is based on.
- 01
A local MCP server runs as you
A stdio server is an ordinary process on your machine: it can read what you can read, use tokens in your environment and reach the network. A third-party server installed with one npx command has your full access.
Do this: Use the remote version when it needs nothing local; run third-party servers in a container, sandbox or VM; pin versions and install only from identifiable publishers. source ↗
- 02
Tool output can carry prompt injection
Servers that fetch pages, mail or tickets hand text written by outsiders straight to the model; hidden instructions can make the agent do things you never asked for. Anthropic’s and OpenAI’s official docs both warn about this.
Do this: Don’t auto-run tools that read outside content together with tools that write, send or pay; keep a human confirmation on sensitive actions. source ↗
- 03
Tool definitions are untrusted input too
Tool names and descriptions go straight into the model’s context; they can be written to steer the model, or change after you approved them.
Do this: Skim each tool description before installing; prefer clients that re-prompt when a definition changes; enable only the tools you need (most clients support tool allow-lists). source ↗
- 04
Over-broad or passed-through tokens
The official guide names token passthrough (forwarding a client’s token to downstream APIs), confused-deputy attacks and over-broad scopes. A token that can write every repo turns one injection into access to all of them.
Do this: Give each server its own least-privilege credential (fine-grained PATs, read-only DB users); request only needed OAuth scopes; don’t let servers inherit your whole shell environment. source ↗
- 05
No limits on files and network
Write access everywhere plus open egress means files outside the project can be changed and data can leave (the guide also covers SSRF).
Do this: Limit file access to specific directories, read-only where possible; disable egress for servers that don’t need it and allow-list the rest. Run the agent’s own commands in a sandbox too. source ↗
- 06
“Run everything” removes the last gate
Switches such as bypassPermissions, --allow-all-tools, Run Everything, danger-full-access or trust: true let the agent run anything without asking. Cursor itself notes its Auto-review classifier is not a security boundary.
Do this: Use full auto only inside a throwaway container or VM; day to day, stay on defaults like “workspace-write + ask when needed”. source ↗
02Checklist for your own machine
From the official MCP Local Server Security guide.
- Know every server in your client config; remove the ones you don’t use
- Servers that need nothing from your machine run remotely, not as local processes
- Every server comes from an identifiable publisher, with its version pinned
- Third-party servers run isolated (container, sandbox or VM), not as bare processes
- Each server gets its own narrowly scoped credentials via per-server config — nothing inherited from your shell, nothing reused
- Filesystem access is limited to specific directories, read-only where possible
- Servers that don’t need the network run with egress disabled; the rest have a known list of destinations
- You have skimmed each server’s tool descriptions, and your client re-prompts when a definition changes
03Checklist for teams
- Maintain an allow-list of approved servers with published acceptance criteria
- Continuously inventory MCP client configurations on managed machines
- Document a default isolation posture for local servers
- Keep audit logs of MCP activity on managed machines
- Be able to block a server’s egress and rotate its credentials across the fleet
04Safety switches in each client
Full setup guide →| Agent | Permission modes | Sandbox |
|---|---|---|
| Claude Code | Permission modes: default (ask per tool) / acceptEdits / plan / auto (classifier review) / dontAsk / bypassPermissions | Turn on with /sandbox (off by default); Seatbelt on macOS, bubblewrap on Linux / WSL2, not on native Windows |
| Codex (CLI · IDE · ChatGPT desktop) | Sandbox read-only / workspace-write (default, network off) / danger-full-access; approvals on-request / never / granular | On by default: Seatbelt on macOS, bwrap + seccomp on Linux, MXC on Windows; .git, .codex, .agents stay read-only |
| Cursor (editor · CLI) | Run Modes: Auto-review (recommended, classifier) / Allowlist / Run Everything (no checks) | Shell commands can run sandboxed (Auto-review, or Allowlist with sandbox); CLI uses /sandbox or --sandbox. Cursor says Auto-review is not a security boundary |
| GitHub Copilot (VS Code · Copilot CLI) | CLI asks by default; --allow-tool grants specific tools, --allow-all-tools hands over all your access | /sandbox enable in the CLI for a local sandbox; cloud sandboxes are in public preview |
| Antigravity CLI | not documented | Has a dedicated sandbox / file-access page in the official docs |
| Gemini CLI | not documented | Enable with -s / GEMINI_SANDBOX: docker, podman, macOS Seatbelt and more |
| Devin Desktop / Devin CLI (formerly Windsurf) | not documented | Devin CLI has OS-level sandboxing (Linux needs bubblewrap + socat); enterprises can enforce it |
| Cline | Asks step by step by default; Auto Approve can be enabled per action type | not documented |
| OpenCode | allow / ask / deny per action, with wildcard rules per command | not documented |
| Kiro (IDE · CLI) | not documented | not documented |
| Qwen Code | Approval modes plan / default / auto-edit / auto (classifier) / yolo | tools.sandbox can be set to docker and others |
05Tools that help
All security tools →- ToolHiverun MCP servers in isolated containers
- Container Usea container and branch per coding agent
- agent-scanscan installed MCP servers and skills
- modelcontextprotocol/inspectorinspect a server’s tools before installing
- E2Bcloud sandbox for code
- microsandboxlocal micro-VM sandbox
- infisicalsecrets management and injection
- gitleakscatch leaked secrets before commit
Is a local (stdio) MCP server more dangerous than a remote one?
It runs on your machine with your permissions, so a malicious or compromised one can read your files and tokens. The official MCP guide recommends running servers remotely when they need nothing from your machine, and isolating third-party local servers.
Does a sandbox make full-auto mode safe?
It limits file and network escapes, but tokens you pass in and actions through MCP tools still go through. Keep secrets minimal and confirmation on sensitive actions.
Sources · about this page
- MCP · Security Best Practices ↗
- MCP · Local Server Security ↗
- Claude Code · Sandboxing ↗
- Codex · Agent approvals & security ↗
- Cursor · Run Modes ↗
- This page summarises official guidance; it is not a security audit of any specific server.