What the Safeguards Still Cannot See

Claude Code’s repository contains real safeguards, but it does not contain a guarantee that every relevant action, instruction, or data path will be observed. This chapter interprets the limits named by the security plugin, managed settings, gateway examples, and repository documentation. The practical task is to separate what a safeguard sees from what it assumes, what it may miss, and which claims require current external documentation, testing, or human judgment.

From safeguard to observable scope

A safeguard is meaningful only within an observable scope. A pattern rule sees an edit path and some new content. It can identify a known-dangerous expression quickly, but it may not see an equivalent operation expressed through another tool or understand the surrounding data flow. A diff review sees a change relative to a baseline. It can reason about a group of edits, but it may exclude pre-existing code, untracked state, or files dropped by a size limit. A commit review can read related files, but it still depends on the exact commit identity and the repository state it can safely resolve.

A permission rule sees a tool request and the policy that applies to it. A sandbox constrains a particular process and its configured filesystem or network paths. The settings documentation warns that Bash sandboxing does not automatically contain Read, Write, WebSearch, WebFetch, MCP servers, hooks, or internal commands. A network allowlist sees destinations, not the intent behind a request to an allowed host. A gateway sees a provider path and organization-managed identity, not necessarily every local action that produced the request.

These scopes form a practical matrix rather than a single ladder of protection. An edit review can see changed content but not necessarily the command that generated it. A command sandbox can see the process it starts but not a hook that runs separately. A network allowlist can see the destination but not the meaning of data sent to an approved host. A managed configuration can see which settings are permitted but not whether a repository instruction is trying to manipulate the agent. The missing dimension is often not “more security”; it is a different observer.

This is not a defect that one more setting can always fix. Each control is optimized for a different decision. A pre-tool block can prevent a recognized action. A post-tool warning can influence the next action. A stop review can inspect a change after the fact. A managed policy can constrain what local users and plugins may add. The question is not whether a control exists; it is whether its event, input, process, and timing intersect the consequence that matters.

The HIPAA-oriented example makes that intersection concrete. It denies access to selected credential files and environment variables, limits sandboxed network domains, requires the sandbox to be available, and prevents an unsandboxed fallback. It also blocks selected tools that send content off the computer, changes synchronization and remote features, and routes selected telemetry to an organization-controlled collector with content-rich fields disabled. These controls can reduce specific data paths. The same example explicitly says they do not cover injected instructions in repository or CI content, processes outside the sandbox, approved plugins or MCP servers that run outside it, merged settings lists, or data that outlives the retention sweep.

Those exclusions are not minor footnotes. They define the difference between a configured boundary and a complete threat model.