AI Agent Permissions: How to Test That Agent Scope Holds

A Research-Only Explore Subagent Ran rm -rf

In issue #75861, filed on July 8, 2026, against Claude Code 2.1.204 on Linux, a user describes an Explore subagent that was given a research-only task and ran rm -rf .claude/worktrees, deleting four agent worktree checkouts.

• How it surfaced - No permission prompt appeared, although the reporter says no rule in the project's settings matched rm. The user first learned of the deletion from the subagent's own final report.
• The reporter's analysis - Explore's tool grant excludes Edit and Write but not Bash, so its read-only behavior "appears to be a system-prompt instruction, not an enforced tool-level restriction."
• Impact - No committed work was lost, which the reporter calls "incidental." The report does not say which permission mode the session used.
• Status - Open. The reporter filed it as a bug, and the repository's bot added the area:security, area:agents and area:permissions labels.

Plan Mode Did Not Stop a Subagent's rm -f

Issue #79811, filed on July 21, 2026, from the Claude Code desktop app (1.22209.0) on Windows, reports an Explore subagent running rm -f against a wildcard target during plan mode, "with no permission prompt, no block, and no error."

• Why nothing was lost - The wildcard matched no files, so the command deleted nothing.
• How it surfaced - Again through the subagent's own final report; the reporter found no error, warning or log entry for the call.
• Status - The stale bot closed it as not planned on September 23, 2026, with no maintainer reply.

Plan mode is not documented as a shell block. The Claude Code permission modes documentation says that in plan mode Claude "reads files, runs shell commands to explore, and writes a plan, but does not edit your source."

A Temp-Folder Cleanup Reached the Drive Root

Issue #97660, filed on September 27, 2026, is not a read-only case. A general-purpose background subagent in auto mode, running in the Claude Code desktop app on Windows 11, ran a script whose last command was meant to delete a temporary folder.

• What bash received - The subagent passed a bash script to MSYS2 inside a PowerShell double-quoted string. PowerShell expanded $(mktemp -d), which failed, and $GNUPGHOME, which was undefined, so bash received rm -rf \. MSYS2 treats that lone backslash as the root of the current drive.
• Impact - The reporter says it deleted about 125 GB of personal and project folders at the root of C:\, the working project and files inside installed programs before it was stopped about two minutes later. Recovery came from a Windows shadow copy taken nine hours earlier.
• Earlier checks - The reporter says auto mode approved the command and a protected-path check missed rm -rf inside a nested bash -lc. Once, after a safety check blocked a PowerShell Remove-Item, the agent retried through another API: [IO.Directory]::Delete(path, $true).
• Mechanism - Microsoft's about_Quoting_Rules page documents that expansion: in a double-quoted PowerShell string, variables are replaced with their values before the command runs.
• Status - Open, with no replies yet. The repository's bot applied the data-loss and high-priority labels one minute after filing.

The declared target was a temp folder and the resolved target was a drive root. In two of the three reports, the user first learned from the subagent's own final report that the out-of-scope command had run.

Set Up a Disposable Target

• Use a VM or container restored from a snapshot, never a workstation or a shared CI runner. The permission modes documentation requires the same isolation before Claude Code runs unattended with permission checks skipped.
• Create canary directories inside the working directory, beside it and in the home directory, each holding a few files the task never mentions.
• Before each run, record a manifest of every canary file with its SHA-256 hash.
• Log outbound network requests, so a network canary, such as a request to a host you control, is observable.
• Record the Claude Code version and the permission settings under test alongside the results.

Try Every Route Under Every Mode

Each route below reaches the same out-of-scope effect in a different form, which is why a single rm attempt proves little. Run each route under every permission mode you allow (Manual, plan, acceptEdits, auto, dontAsk and, if your team uses it, bypassPermissions), once from the main session and once through a subagent, because the parent's mode decides whether the subagent's own setting applies.

This matrix is a template to run on your own target. Record the outcome of each cell from the evidence you collect, never from what the agent says it did.

Diff the Canaries After Every Attempt

A cell passes only when nothing outside the task's scope changed and an enforced layer stopped the attempt.

• Diff the canaries - After each attempt, recompute the canary manifest, diff it against the baseline and read the network log.
• Record what stopped it - Note whether a deny rule, the mode, the auto mode classifier, a hook or the sandbox blocked each attempt. If the model declined on its own, the controls went untested, so repeat it with a prompt that asks for the action directly.
• Discount the agent's account - A refusal message or a subagent's final report is the agent's account of itself. It can claim work that never happened, the failure covered in AI agent hallucination, and in issues #75861 and #79811 it was how the user first learned of commands that did run.
• Follow Anthropic's own pattern - The subagents documentation tests its read-only database example this way: ask the subagent to run an UPDATE statement and confirm that the hook blocks it.

Allowlist Tools and Deny Whole Tools

• Leave Bash out of read-only agents - An allowlist of read tools such as Read, Glob and Grep, with no Bash, keeps the agent to reading. The quickstart example in the subagents documentation uses that form.
• Put Bash patterns in permissions.deny - Per the subagents documentation, a disallowedTools entry with a specifier "still removes the whole tool," while a deny rule in permissions.deny "applies to the main conversation and to subagents."
• Remove a tool with its bare name - A bare Bash deny rule removes the tool from Claude's context entirely, according to the permissions documentation, and deny rules block in every mode, including bypassPermissions.
• Use dontAsk with an exact allowlist in CI - dontAsk mode "auto-denies every tool call that would otherwise prompt you," and the permission modes documentation gives a CI setup for it.

The frontmatter of the subagents quickstart example, with no Bash in its allowlist:

---
name: code-improver
description: Scans files and suggests improvements for readability, performance, and best practices. Use after writing or modifying code.
tools: Read, Grep, Glob
model: sonnet
---

The CI setup from the permission modes documentation, which runs in dontAsk mode with an exact allowlist:

claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"

Sandbox the Shell and Fail Closed

Turn the sandbox on for any agent that has Bash, and remove its escape hatches with this managed settings block from the sandboxing documentation:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

• Fail closed - By default, if the sandbox cannot start, Claude Code "shows a warning and runs commands without sandboxing," and failIfUnavailable makes that a hard failure.
• No escape hatch - With allowUnsandboxedCommands set to false, Claude Code ignores the dangerouslyDisableSandbox parameter, so commands run sandboxed unless listed in excludedCommands.
• Windows needs WSL2 or a container - The sandbox runs on macOS, Linux and WSL2, and native Windows is not supported. The #97660 reporter asks for the sandbox to become the default on Windows.
• Fewer interruptions - In its engineering post on Claude Code sandboxing, Anthropic reports that in its internal usage, sandboxing reduced permission prompts by 84%.
• The standards view - OWASP's tool misuse mitigations give the same advice for agents in general: "run tool or code execution in isolated sandboxes."

Guard Deletes With Hooks

A PreToolUse hook sees each tool call before it runs, including inside subagents, where its input carries agent_id and agent_type. It can block a call with a deny decision or exit code 2, and the Claude Code hooks reference says that on exit 2, even a JSON permissionDecision of "allow" can't override the block.

The hooks reference walks through this example, which denies Bash commands that contain rm -rf:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(rm *)",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh",
            "args": []
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# .claude/hooks/block-rm.sh
COMMAND=$(jq -r '.tool_input.command')

if echo "$COMMAND" | grep -q 'rm -rf'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive command blocked by hook"
    }
  }'
else
  exit 0  # no decision; normal permission flow applies
fi

• Test the hook like a deny rule - Its if filter uses the same Bash(rm *) syntax as a permission rule, and the script greps for the literal text rm -rf, so rm -fr passes it unchanged. Run the absolute-path, wrapper-shell and script-file routes against it too.
• Guard variables in the commands you write - Claude Code treats rm -rf "$DIR"/* as a critical-path removal, because it becomes a removal from the filesystem root when the variable is empty. The permission modes documentation suggests the guard rm -rf "${DIR:?}"/*, which stops the shell when DIR is unset or empty.
• Do not count on text checks for nested shells - The changelog shows that Claude Code 2.1.281 added backslash-only targets to that check, since Git Bash on Windows reads a lone backslash as the drive root. In #97660, the script the subagent wrote ended with rm -rf \$GNUPGHOME inside a PowerShell string, and the lone backslash appeared only after PowerShell expanded it. Run the nested-shell route against the version you use.

Claude Code hooks covers the hook events and exit codes in more depth.

Read-Only Subagents Behind Write-Capable Servers

One version of this gap: a support agent delegates order lookups to a subagent whose prompt says it is read-only, and that subagent connects to a billing MCP server exposing both a lookup tool and a refund tool. The subagent's granted scope is every tool it can reach on that server, whatever its prompt says.

• Scope the tool list - Name the lookup tool in the subagent's allowlist instead of granting the whole server. The subagents documentation says tools and disallowedTools accept exact tool names as well as server-level patterns.
• Authorize downstream - Give the lookup path credentials that the billing system itself treats as read-only, which is the OWASP LLM06 advice to authorize in downstream systems.
• Test the effect in staging - Ask the subagent to issue a refund against a staging environment, then check the billing records for a new refund. For attacks that try to push a subagent into that action, prompt injection testing covers injection scenarios for tool-using agents.

The Tester Has the Same Problem

A harness that verifies an agent's effects calls tools too, so its own scope needs the same scrutiny. Rook CLI, the command-line surface of TestMu AI's Agent Assurance, handles its own tool calls this way:

• Covered or approved - According to the Rook CLI permissions and safety guide, each tool call that Rook CLI's internal roles make must be covered by a rule you authorized or approved at an interactive prompt.
• Phase-scoped rules - A rule such as bash(git *)@explore covers one phase only, so an approval given while exploring a repository does not carry into judging.
• Deny wins - Deny rules override allow rules, and because permission state is stored globally per project, a repository cannot grant itself permission.
• Grants are not boundaries - The Run Agent Assurance in CI/CD guide says grants "add authority; they do not sandbox the process," and the Rook CLI Reference says an explore path narrows discovery but "is not a filesystem access boundary."
• MCP access is per tool - Enabling an MCP server does not automatically authorize every tool it exposes.