Home / Security and data

A text-pattern guard is not a security boundary

A guard that refuses a word in the text of a command judges a spelling, not an effect: any spelling that avoids that word gets through, and even a list of allowed commands matched by exact equality lets through the code that an allowed command reads from a file the agent can edit.

A guard refuses any command that contains the word rm. Three ways of writing the same deletion get through it, and the following demonstration checks this in a throwaway folder that it creates, with four empty files.

The guard and its four trials

mkdir -p demo-guard && cd demo-guard
touch target1.txt target2.txt target3.txt target4.txt
cat > guard.sh << 'EOF'
#!/bin/bash
cmd="$1"
if echo "$cmd" | grep -qw 'rm'; then
  echo "REFUSED: forbidden pattern detected in the typed command"
  exit 1
fi
echo "ALLOWED: no forbidden pattern found, running"
eval "$cmd"
EOF
chmod +x guard.sh
./guard.sh "rm target1.txt"
./guard.sh "r'm' target2.txt"
./guard.sh 'A=r; B=m; $A$B target3.txt'
ENC=$(printf 'rm target4.txt' | base64)
./guard.sh "echo $ENC | base64 -d | bash"
ls -1

REFUSED: forbidden pattern detected in the typed command
ALLOWED: no forbidden pattern found, running
ALLOWED: no forbidden pattern found, running
ALLOWED: no forbidden pattern found, running
guard.sh
target1.txt

The first trial is refused and target1.txt survives. The second splits the word with apostrophes, which the interpreter removes before running. The third assembles the word from two one-letter variables. The fourth encodes the command in base64, which base64 -d | bash decodes then runs.

Why fixing case by case closes nothing

Forbidding the lone apostrophe, pasted variables or base64 closes three doors and leaves others open, because the number of ways of writing the same command is not bounded in advance. The Claude Code permissions page says the same of its own command rules: a Bash(rm *) deny rule stops rm -rf build/ and lets /bin/rm -rf build/ or bash -c 'rm -rf build/' through, and such a rule is not a security boundary around the program.

Exact equality shrinks the surface without closing it

A list of allowed commands holds up better when it demands exact string equality and admits no launcher program, that is, no program that runs another command passed to it: bash, sh -c, eval, find -exec, xargs or npm run. It then closes the rewrites. It leaves open the code that an allowed command reads elsewhere. Git runs the program named by the repository's core.fsmonitor setting when it refreshes its index, during a git status for example.

mkdir -p demo-fsmonitor && cd demo-fsmonitor
git init -q
git config core.fsmonitor 'echo RUN_BY_GIT_STATUS > witness.txt; false'
git status > /dev/null 2>&1
cat witness.txt

RUN_BY_GIT_STATUS

A git status identical character for character to the allowed entry ran what an agent can write into .git/config. The other route no longer inspects the text: the sandbox, an isolation that the operating system imposes on shell commands and their child processes, bounds the files and network that this code reaches, whatever the command that launched it. It runs on macOS, Linux and WSL2, not on native Windows.

The lesson on the read that is enough to expose a secret shows the same limit for a read rule, which does not cover a command that reaches the file without naming it. The lesson on what an agent can leak without being asked to describes indirect injection, an instruction hidden in content that Claude reads, which is one of the routes by which an agent writes a configuration that nobody asked it for.

Added: also refuse the lone apostrophe.
Next bypass: two pasted variables, still allowed.

Allowed: git status
Refused: bash -c 'git status'
Still open: the program that core.fsmonitor names in .git/config