Keep secrets safe when coding with agents

Secrets — API keys, tokens, database credentials — are where coding-with-agents gets genuinely dangerous, and where a lot of otherwise careful people are sloppy. An agent that can run shell commands, with secrets sitting in its reach, is close to the worst configuration you can build: one prompt injection or one careless command away from leaking the keys to your kingdom.

The good news is that keeping secrets safe with agents is mostly a few firm habits. Here they are.

The worst-case configuration

Security researchers have a name for the most dangerous setup, and it's worth burning into memory: an agent with bash permissions on a runner with secrets in scope. That's the configuration where things go catastrophically wrong, because the agent can both access the secret and act on it — read the key and then exfiltrate it. The worst real-world incidents trace back to exactly this combination of broad access and secrets within reach.

So the whole game is keeping those two things apart: the agent's ability to act, and the secrets themselves.

Keep secrets out of the context window

The first rule: a secret should never enter the agent's context. Not in a file it reads, not pasted into the chat, not printed by a command it runs.

This matters because the context window is leaky by nature. Whatever's in it may be sent to the model provider, logged, cached, or carried into a summary. A secret that touches the context has, for safety purposes, left the building — you can't be sure where it went. So the rule isn't "be careful with secrets in context." It's "secrets never go in context at all."

Stuart Leo

A secret that enters the context window is a secret you've half-leaked. The only safe amount in the agent's context is none.

Environment variables, never in code

The mechanism that keeps secrets out of reach is the same one good engineering already uses: keep secrets in environment variables (or a proper secrets manager), reference them by name in code, and keep the values out of the repo entirely.

# Right: the agent sees a reference, never the value
api_key = os.environ["STRIPE_API_KEY"]

# Wrong: the secret is now in a file the agent reads
api_key = "sk_live_51H...."

The agent reads the code, sees os.environ["STRIPE_API_KEY"], and learns that a key is needed — not the key. The actual value lives in the environment, which the agent has no reason to print and you give it no reason to read. (Your .env file is gitignored, always.)

Scope what the agent can run

Even with secrets out of code, an agent with unrestricted shell could still go fishing — env, cat a config, hit a metadata endpoint. So pair "secrets out of context" with "limit what the agent can do," which is least privilege: scope its commands and file access so the paths to a secret are closed. The two rules reinforce each other — keep the secret out of reach, and keep the agent's reach short.

This matters most for autonomous and overnight runs, where no one's watching. An unattended agent should never have a path to a production secret, full stop.

If a secret leaks, rotate

Sometimes it happens anyway — a command prints a key, a config gets read, a value slips into the chat. When it does, the response is simple and non-negotiable: rotate the secret immediately. Assume it's compromised.

Rotation is cheap. Assuming "it was probably fine" is how a leaked key becomes an incident. Treat any secret that touched the context window as burned, rotate it, then fix the path that let it in.

Never let a secret into the agent's context or its blast radius — keep keys in the environment, scoped tight.

Start here: see least privilege for coding agents, the field note on a leaked secret, or read the method.