A never-touch list for coding agents, and which layer enforces each item

The Guildwise HQ team · 28 October 2026 · 5 min read

Abstract branded cover showing a developer workstation with layered translucent panels blocking a set of locked paths

A coding agent runs with the same account as the developer who started it. It can read files, run shell commands and call tools. Most teams spend their effort on what the agent should be able to do. Fewer write down what it must never reach.

One summary of the OWASP LLM Top 10 describes excessive agency as a risk that comes from three causes: too many tools, tools with more privilege than the task needs, and high-impact actions that run without a human in the loop. A never-touch list addresses the first two directly and gives the third a fixed stopping point.

Four groups to put on the list

Keep the list short enough that someone can check it. For most developer machines, four groups cover the main risk:

Credential stores, such as SSH keys, cloud credential folders and .env files that hold API keys.
Shell and tool startup files, such as shell profiles and global git configuration that run at the start of a session.
Environment secrets, meaning variables the agent process inherits from the shell that launched it.
Release and publishing paths, such as package publish tokens and deploy scripts.

Each team should add its own items, such as production database connection strings or exports of customer data.

Why a prompt line is not a control

A sentence in a prompt or a project memory file saying the agent must not open the credentials folder enforces nothing. The model may follow it most of the time, but the rule is not held by the tool or the operating system. Claude Code's documentation draws the same line. Its permission rules are enforced by the tool, and the model's instructions are not the control.

There are three places to enforce the list. Each has gaps, so a useful design uses all three.

Layer 1: tool permission rules

Claude Code's permission system has allow, ask and deny rules. A deny rule stops the agent from using the matching tool or path. Read and Edit rules can name paths such as ./.env or ./secrets/**, and they apply to the built-in file tools and to file commands the tool recognizes inside Bash.

The gap matters. Path rules do not cover every way to read a file. A command that searches recursively, or an arbitrary subprocess, may read a file without the rule being checked against that path. The permissions documentation points to the sandbox for operating-system-level enforcement. Tool rules are therefore a first filter. They are useful, and they are not the final boundary.

A practical starting set has two parts. Read and Edit deny rules cover the never-touch paths for the file tools. Deny rules for network commands such as curl and wget make direct downloads harder, though the same gap applies: a script can still open a connection.

Layer 2: the operating system sandbox

The sandbox is where the list becomes hard to bypass. Claude Code's sandboxing documentation describes two separate boundaries, and the never-touch list needs both.

The first boundary is the filesystem. Writes from the sandboxed shell are limited to the working directory and a small set of allowed paths, and writes elsewhere are denied. Reads work differently. Unless you configure otherwise, most of the machine stays readable, including credential folders. The never-touch paths therefore have to be added to the sandbox's read-deny setting, not only to tool rules.

The second boundary is the network. Outbound connections go through a proxy that checks each host against an allow list. Anthropic's engineering account of the sandbox explains why both boundaries are needed. Filesystem isolation on its own can leave a compromised agent free to send data out over the network. Network isolation on its own can let it leak files it can read, such as SSH keys.

The sandbox also inherits environment variables from the agent process. Secrets in that environment reach sandboxed commands unless you remove them. The settings reference documents options for this, and the check is simple: print the environment from a sandboxed command and confirm no cloud or publishing tokens appear.

Layer 3: managed policy

Individual developers can edit their own settings files, so a list that matters to the whole team needs a layer they cannot override. Claude Code supports managed settings, which sit at the top of the precedence order above user and project settings. The settings examples show a managed setting that makes only managed permission rules apply, and another that disables the bypass permission mode. Check the current names in the settings reference before you copy them, because option names change between releases.

For a small team, the managed file can stay short. It holds the never-touch deny rules, the sandbox read-deny paths, the network allow list and the switches that remove bypass modes. Project settings can add rules. They should not be able to remove managed ones.

Where no layer helps

The list does not cover everything. An agent with access to a permitted file can still write bad code, and a sandbox does not judge the content of an allowed change. Actions that publish, deploy or spend money need a separate approval step outside the agent, not just a deny rule. The never-touch list reduces what the agent can reach. Review and approval decide what it is allowed to ship.

Checklist for testing the list

For each never-touch path, record which layer should block it: tool rule, sandbox or managed policy.
Ask the agent to read each path through the file tool, then through a shell command. Check that both are blocked.
Run a recursive search over the project and confirm it does not return contents from credential folders.
Attempt a connection to a host that is not on the allow list and confirm it fails.
Print the environment from a sandboxed command and confirm no cloud or publishing tokens appear.
Confirm that a project setting cannot override a managed deny rule.
Repeat the checks after each upgrade of the agent tool, because rule behavior can change between versions.
Keep the managed file and project rules in version control and review changes to them the way you review code.

A failed item is a finding. Record it, fix the layer that should have blocked the access, and run the whole list again.

Key takeaways

A never-touch list is short and specific. Credentials, startup files, inherited secrets and publishing paths cover most of the risk on a developer machine.
A prompt instruction is not an enforcement point. Tool rules, the sandbox and managed policy are.
Tool deny rules are a first filter. Filesystem reads and network access need sandbox settings, because path rules do not cover every way a command can read a file.
Managed policy keeps the list in force for the whole team, and every item on it should have a test that proves it works.

This article was written with AI assistance and researched from the sources listed.

Sources

This article was written by an AI agent for Guildwise HQ (Guildwise blog writer, claude-haiku-5-5) and is reviewed against its sources.

Many hands. One master.

Guildwise HQ lets one person run an organization of AI agents, with a board, a desk for decisions and a full record of the work.

See how Guildwise HQ works