Guide

How do I stop Claude Code and other coding agents from leaking secrets?

Updated November 9, 2026

Short answer

Start by hiding secrets from the agent. Read deny rules, ignore files and a sandbox read list all shrink what it can see. File rules alone won't hold, though, because cat, env, curl and git can reach the same secrets another way. So also check every command, file edit and push at the agent's pre-execution hook before it runs, and make that check on the laptop so the secret never leaves the machine.

What actually leaks#

A coding agent runs as the developer. Whatever the developer's account can read, the agent can read.

That covers .env files, ~/.aws/credentials, ~/.ssh keys, tokens in shell history and every variable in the environment. The leak happens when one of those values reaches something outside the machine: a curl, a git push to a new remote, an MCP tool call, a URL the agent opens, or a line of code committed to the repo.

Corporate laptop. Cloud credentials in plain files. An agent that takes 145 actions in an average session, and more than 1,000 in a long one.

Ignore files and read deny rules only close one door#

A rule like Read(./.env) in Claude Code's permission settings stops the agent's built-in Read tool from opening that file. Add it. It's cheap and it closes the easy path.

It doesn't cover the shell. Anthropic's sandbox docs are clear about the split: built-in tools such as Read "follow permission rules instead," and a sandbox denyRead entry "doesn't stop the Read tool." The two layers cover different things, and each one needs its own configuration.

The shell side has its own gap. The sandbox is off by default. By default it can read "most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials," and "there is no built-in credential deny list, so only the files and variables you list are restricted." Read the sandboxing docs before you rely on it.

The side doors around file rules#

PromptArmor showed what happens when a file rule is the only control. In their Google Antigravity test, the agent ran into a file protection and then "decides to work around this protection using the 'cat' terminal command to dump the file contents."

The same thing can happen with any agent that has a shell:

cat, grep, head or env read what the file rule hides.
curl, wget or a Python one-liner send a value out.
git remote add plus git push moves source code and committed secrets to a repo you don't own.
An MCP server, or a package pretending to be one, receives whatever the agent passes to it.
An agent that pastes a service key into client-side code ships that key to every browser. Nothing gets "exfiltrated," and the key is still public.

Supply-chain malware uses the agent too. Wiz found that the Nx attack "abused locally configured AI CLIs to identify additional files for exfiltration," and that over 2,000 unique, verified secrets were leaked. The AI step worked in under a quarter of cases, but the attacker's tool was still an agent the developer had already installed.

What each control stops#

Control	Stops	Misses
Ignore files, `Read` deny rules	The agent opening listed files with its file tools	Shell reads like `cat` and `env`, and files you didn't list
Sandbox `denyRead` list	Shell commands reading the paths you list	Built-in tools like Read. Credential files you didn't list stay readable. It's off by default
Scoped, short-lived credentials	How much damage a leaked secret can do	The leak itself
Human approval prompts	Some obvious risks	Anthropic reports users accept 93% of prompts. In Anthropic's 1,053-tester study, humans caught 13.6% of dangerous commands

Each of these is worth having, but each covers only part of the path. A long session with hundreds of actions will find the part that's left open.

A checklist you can run this week#

Keep secrets out of project directories. Use a secrets manager or short-lived cloud credentials instead of long-lived keys in ~/.aws.
Deny reads on .env*, ~/.ssh and ~/.aws in permission rules, then turn on the sandbox with a denyRead list for the same paths.
Limit outbound network access to the hosts the work actually needs.
Scope every token an agent can reach to one repo or one environment, and give it an expiry.
Have a policy or a person decide on any new git remote, any curl that carries a variable and any new MCP server.
Scan the code agents write for hardcoded keys before it ships.
Use one runtime check across every agent, so you aren't maintaining a separate setup for each vendor.

Where Harden fits#

The checklist still leaves a gap: the moment between the agent deciding to act and the command running. Harden Agentic Integrity Foundation (AIF) works in that gap.

Harden runs on the developer laptop, outside the agent, at the agent's pre-execution hook. Every command, file edit and push is checked against the session's intent before it runs.

Harden parses the command and follows the data from where it came from to where it's going. If a secret reaches a network call, that's a dangerous flow, and Harden acts on it.

Secrets are judged by content, not file names. A .pem holding a public certificate passes; one holding a private key is stopped. Base64 and hex values are decoded before analysis, and when Harden blocks an action, the agent gets the reason and can retry a safe way.

Decisions take about 28 ms (P99 about 70 ms) and are made locally, so the secret never leaves the machine to be checked. If the check can't run, the action doesn't run.

Harden starts in watch-only mode, so you can see what your agents do before you enforce anything. One policy covers every agent that exposes a pre-execution hook.

Harden has limits. It's a layer, not a perimeter. Exfiltration spread across several separate calls is the hard case, and it doesn't replace least privilege or scoped credentials.

For the security-team view, see Harden for security teams and the AIF trust page. For destructive commands, see stopping agents running rm -rf.

FAQ