Give an Unattended Agent Only the MCP Tools It Needs — Enforcing a Deny-by-Default Policy

Put deny-by-default at the administrator layer

Start by flipping the stance to "anything not allowed is denied." Concretely, broadly deny the higher-risk categories in managed policy, then add back only what's truly needed in the next step.

On macOS, the managed policy lives here (paths vary by environment):

# macOS managed policy location (requires admin rights)
/Library/Application Support/ClaudeCode/managed-settings.json

The contents begin by closing things down broadly:

{
  "permissions": {
    "defaultMode": "deny",
    "deny": [
      "mcp__filesystem",
      "mcp__puppeteer",
      "mcp__chrome",
      "Bash(rm:*)",
      "Bash(git push --force:*)",
      "WebFetch"
    ]
  }
}

Two things matter here. First, setting defaultMode to deny means anything you haven't explicitly allowed generally won't pass. Interactively, ask is reasonable; unattended, with no one to ask, deny is the safe starting point. Second, an MCP server can be denied wholesale as a single unit: mcp__<server>. "This agent never sees the filesystem MCP" becomes one line.

At this point you have an agent that can do almost nothing. That's fine. Next, hand back only what the job requires.

Narrow MCP at two levels: per-server and per-tool

It helps to think of the allowlist as two stages: enabling MCP servers, and allowing individual tools.

First, don't auto-launch every server bundled in the project's .mcp.json. In unattended operation, just being explicit here cuts down on "a server I didn't know about quietly appeared" incidents.

{
  "enableAllProjectMcpServers": false,
  "enabledMcpjsonServers": ["github"]
}

Setting enableAllProjectMcpServers to false keeps the project's .mcp.json servers off by default, launching only those listed in enabledMcpjsonServers. If the job is generating and pushing an article, you can narrow it to a single repository-operations server at most.

Then, within a launched server, allow tools by name. MCP tools can be addressed individually as mcp__<server>__<tool>:

{
  "permissions": {
    "defaultMode": "deny",
    "allow": [
      "mcp__github__search_repositories",
      "mcp__github__get_file_contents",
      "mcp__github__create_or_update_file",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git push:*)",
      "Read",
      "Write"
    ],
    "deny": [
      "mcp__filesystem",
      "mcp__puppeteer",
      "mcp__chrome",
      "WebFetch"
    ]
  }
}

Now, on that same GitHub MCP server, "read a file" and "create a file" pass, while any other destructive tool — should one exist — won't, unless it's on the allowlist. Close down per server, then open per tool. That two-stage stance is what pays off unattended.

Before / After: from leaning on prompts to closing things down in config

My first unattended launch looked like this:

# Before — grants broad permission on the spot
claude -p "Generate an article and push it" \
  --dangerously-skip-permissions

--dangerously-skip-permissions is handy because it skips interactive confirmation — but using it unattended skips the entire step of reasoning about reach in configuration. That's exactly what let an agent wander into unrelated tools and stall.

After switching to deny-by-default, the launch side actually got plainer, because closing things down is now the config's job:

# After — assumes the managed policy already closed things down; state only what's needed
claude -p "Generate an article and push it" \
  --allowed-tools "mcp__github__create_or_update_file,Bash(git push:*),Read,Write"

The --allowed-tools on the launch line is only a declaration of "what I'd like to use this session." It can't open anything beyond the managed policy's deny. So even if you write something too broad at launch, the administrator layer still holds the floor. Whether that un-overridable floor exists was the essential difference between Before and After.

Confirm the policy is in effect at startup

I learned the hard way not to relax just because I wrote the settings. The scariest case is a policy you believe you set that, due to precedence, isn't actually in effect.

Before putting it on an unattended schedule, launch it interactively once and check:

# 1. Inspect which settings load, and from which layer
claude --debug 2>&1 | grep -i "settings\|permission\|mcp"
 
# 2. Confirm which MCP servers actually launched
claude mcp list
 
# 3. Environment health check (including isolation of broken config)
/doctor

If claude mcp list shows only the servers you named in enabledMcpjsonServers, your per-server narrowing is working. If a server you meant to deny is still in the list, suspect precedence or the file's location. /doctor inspects configuration health and shows whether broken config has been isolated.

If you want to automate the check, you can put a front gate at the very start of the unattended run: pull the MCP list, and if it differs from what's expected, exit before doing any real work. In my own setup, if an unexpected server shows up, that run is skipped and only a log is left behind.

Traps worth knowing: precedence and fallback

In practice, what tripped me up wasn't settings that "didn't work" — it was settings losing to a different layer.

The most common one: an allow written in local project settings is blocked by the managed policy's deny and never passes. That's correct, by design. Deny wins at the higher layer, so adding an allow locally won't open it; if you want it open, you have to edit the managed policy itself. Unattended, that "can't open it locally" property is the safety device.

A second one: mistaking an MCP server's launch failure for a denial. If a server won't start because its command isn't found or an environment variable is missing, the outcome — the tool is unusable — looks just like a deny. Reading the status in claude mcp list separately from the startup log lets you tell "stopped by policy" apart from "failed to launch."

Finally, fallback design. When a tool is blocked by deny, does the agent route around it — say, trying to do the same thing via Bash? That's why deny should cover not just specific MCP tools but also the commands that tend to become detours, like Bash(rm:*). Holes open right next to the one you thought you'd plugged.

A small first step

You don't need to put every task on deny-by-default at once.

Pick the single agent you run unattended for the longest stretch, and run claude mcp list in that session. Just looking at whether it can see more servers than the job warrants will tell you where to tighten. The one thing you can do today: read that list and add to deny the one server you can immediately say this agent doesn't need.

The more something runs unattended, the more worth it is to narrow what can happen ahead of time. Since I took this on in configuration, I find far fewer agents stalled in the morning. If you're running overnight batches too, I hope this gives you a foothold for your own operational design.