Gate Secret File Reads for Coding Agents

The deputy already has the keys to the house

Most coding agents ship with filesystem and shell tools. Attackers do not need malware that reads disk. They need the host to already allow reads, and they need natural language (poisoned docs, tool descriptions, or post-approval metadata) to steer the plan toward secret paths—and sometimes to hide the hunt from the operator UI.

That is why Deadbugz-style metadata and ContextCrush-style Custom Rules matter: the blast radius is whatever your agent can open. Allowlisting a "formatter" MCP does not shrink that radius.

Secret-class paths are high-impact tools

Treat these as high-impact even when the tool is named `read_file`:

- `.env`, `.env.`, and committed secret dumps

- `~/.ssh`, agent sockets, and private keys

- Cloud credential files and SSO caches

- kubeconfig and cluster tokens

- Browser/OS keychain exports and shell history that embeds tokens

Policy:

1. Default deny secret-class globs unless the task charter explicitly needs them.

2. Extra gate (HITL or break-glass) showing the resolved path—not buried tool prose.

3. No expansion because MCP metadata or a docs rule "authorized" the read—AuthZ is server-side.

4. Log proposal → decision → outcome on one timeline with the MCP/docs fetch that preceded it.

Workspace-rooted reads under `/workspace` with path canonicalization are a different tier from home-directory credential harvest. Do not conflate them in one open `read_file`.

What "done" looks like

Tests prove ungated secret-class reads are impossible. Approvers see the real path. Traces connect injection-shaped context to the read proposal. Inventory knows which agents have any FS tools at all. That is Tool Safety + Human Approval + Observability—independent of how polite the MCP description sounded.