Prevent coding agents from reading production secrets

Agents read everything they can reach, including the .env you forgot about. Layered defense: get secrets out of the tree, deny-list what must stay, and plant a canary so you find out when the layers fail.

Expected result

No secret material lives inside the repo tree; agent tooling is deny-listed from the env files that must remain; and a canary token alerts you within minutes if an agent (or anything else) reads what it shouldn't.

Difficulty

Intermediate

Estimated time

~45 min

Version notes

Deny-rule syntax above is Claude Code 2.3+. Codex: use the sandbox config to restrict filesystem access instead — deny rules and sandboxing differ per agent, which is exactly why step 2 (removal) is the layer that matters.

1. 01Ability to move env handling to direnv or a secret manager
2. 02Claude Code 2.3+ / Codex 0.44+ (permission deny rules)
3. 03Ten minutes of honesty about where your secrets actually are

01

Inventory what an agent can currently reach

Before adding controls, find the exposure. Search the tree the way an agent would — filenames first, then contents. Anything this turns up is readable by every agent you run.

find . -name '.env*' -not -path './node_modules/*'
git grep -lE '(AWS_SECRET|API_KEY|PRIVATE_KEY|PASSWORD)=' -- ':!node_modules'

Copy

02

Move secrets out of the repo tree entirely

The only file an agent cannot read is one that isn't there. Keep real values in a directory outside the project and have direnv load them. The .envrc in the repo contains no secrets — just the pointer.

# ~/.secrets/myapp/prod.env lives OUTSIDE the repo
# .envrc (committed, secret-free):
dotenv_if_exists ~/.secrets/myapp/dev.env
dotenv_if_exists .env.local   # non-secret local overrides only

Copy

03

Approve the .envrc and verify the split

direnv refuses to load until you allow it. After allowing, confirm the shell has the vars while the tree has no secret files left.

! Common failures

Deny rule blocks Read but the agent cats the file via Bash

Read() rules only govern the Read tool. You need Bash deny patterns too — and note they match string prefixes, so cover the variants (cat .env, cat ./.env). The belt-and-braces fix is moving the file out of the tree; deny rules are the fallback, not the primary.

Agent reads secrets from the shell environment instead of files

If you export secrets globally, env is the leak. Scope direnv to load prod values only in a directory agents never run in. Dev credentials in the agent's env should be low-privilege by construction.

Canary fires constantly from your own CI

Your CI is reading .env.production from the checkout — which is itself a finding. Point CI at its own secret store and keep the canary file agent-bait only.