All pages
Guides
How do I control which MCP servers developers' agents use?
Find the MCP servers agents can reach, allowlist them with each client's own settings, scan their definitions, and block unapproved ones at the call.
An MCP server gives an agent new tools, and often new credentials and new places to send data. Controlling them is four jobs: know what is configured, decide what is allowed, check what each server says about itself, and stop the ones you have not approved.
Know what is configured#
Each client keeps its own list, and most read one per user and one per repository:
| Client | Where servers are configured |
|---|---|
| Claude Code | ~/.claude.json for the user and per project, and a repository's .mcp.json |
| Cursor | ~/.cursor/mcp.json, and a repository's .cursor/mcp.json |
| Codex | ~/.codex/config.toml |
A repository's own file matters: cloning a repository can bring a server with it. Claude Code asks before it starts a server from a project's .mcp.json.
Decide what is allowed#
Claude Code's managed settings can restrict which servers users may configure, with allowedMcpServers and deniedMcpServers, and a managed-mcp.json file can deploy a fixed set that users cannot change. Deploy both through your device management; see How do I roll out coding-agent security with Jamf, Intune or Kandji? Other clients have their own admin controls; check each one's documentation.
Check what each server says#
- Pin versions. A server started with
npx some-serveroruvx some-serverwithout a version runs whatever was published last. - Read the tool descriptions. The model reads them as instructions. A description can carry an injection, and it can change after you approved the server.
- Prefer HTTPS for remote servers, and look at what credentials each one is given.
- Scan definitions. Open-source scanners such as mcp-scan, from Invariant Labs (now part of Snyk), check server definitions for known problems.
What that leaves open#
- A configuration file says what could run, not what did. You learn which servers are actually used only by watching calls.
- Each client and each machine is configured separately, and a server added in one repository is easy to miss.
- A definition can change after it was reviewed, and nothing in the client tells you.
- Allowlists in managed settings cover the clients that have them, and only on machines where they are deployed.
Where Golem fits#
An inventory built from calls. Watch → Security Inventory → MCP servers lists every server an agent actually called, with its definition, from what passed through Golem rather than from what anyone registered. Each server can be decided Allow, Allow · read-only, Alert or Block. A server whose definition changes after you decided it reappears under Changed since decided.
First use of an unapproved server. Under Security Inventory → Settings, Unreviewed MCP servers is Allow (the default), Alert on first use or Block. A blocked call tells the agent that the server is not approved and where an admin approves it, with a decision id. Deciding Allow in the inventory is the approval. See Shadow AI.
Config scan. Every 30 minutes the Golem agent reads the MCP servers configured for Claude Code (global, per project and each repository's .mcp.json), Cursor, Windsurf, Gemini CLI and Claude Desktop. It alerts on a server that pipes a download into a shell or a remote server over plain http, and records servers run unpinned through npx or uvx. See What agents load.
Rules on servers and tools. A rule can read entry.mcp_server_id, entry.tool_name and entry.tool_description_changed, and hold or refuse a call on any of them.
Two places to stop a call. Your MCP servers can stay in each client's own configuration, where Golem sees and judges their calls through the client's hooks. Or you can route a server through Golem's MCP gateway, which puts Golem in the connection: a refused call never reaches the server, even if a client skipped its hook, and the client gets JSON-RPC error -32050. See MCP servers: hook or gateway.
What Golem does not do#
- It never edits a client's MCP configuration. Blocking happens at the call; removing the entry is for the developer or your device management.
- Golem's own servers (
golem-witness,golem-context) and clients' built-in tools are never treated as unapproved. - A server that is called through a client Golem is not wired into is not seen. The client still appears under Shadow AI as not wired.
- The scan judges each definition on its own. Golem has no reputation catalogue of public MCP servers.
Read next#
- Coverage: the Security Inventory and Shadow AI
- Block, hold and contain: what a refusal on the MCP path looks like
- Limits