ArticlesField notes
The secret that leaked into context
A field note on an API key that ended up in an agent's context window where it didn't belong, and the rule I keep now.
An API key I was careful with ended up in an agent's context window anyway, through a path I hadn't thought about. Nothing bad came of it — because I rotated it the moment I noticed — but it taught me a rule I now keep without exception. This is the field note.
How the key got there
I was debugging a failing API call with the agent. The call wasn't working, so — without thinking — I had the agent run the request with verbose output to see what was going wrong. The verbose output dutifully printed the full request, headers and all, including the Authorization header with the live API key in it.
There it was, in plain text, in the agent's context. I hadn't pasted it. I hadn't put it in a file. A debug command I asked for had pulled it out of the environment and into the window, and I almost scrolled right past it.
Why context is the wrong place for a secret
For a second I thought "no harm done, it's just in the chat." Then I remembered why that's wrong. The context window isn't a private scratchpad — its contents get sent to the model provider, can be logged, can be cached, can be carried into a summary. A secret that lands in context hasn't necessarily leaked, but you can no longer prove it didn't. As the security writeups on AI agent vulnerabilities keep stressing, anything an agent's session touches has to be treated as potentially exposed.
Stuart Leo
A secret in the context window isn't necessarily leaked — but you can't prove it wasn't. For a credential, that's the same thing.
The near-miss
So it was a near-miss, not a disaster, and the difference was entirely that I noticed. If I hadn't been looking at the output, that key would have sat in the context, gone to the provider, possibly been logged — and I'd never have known to rotate it. "Probably fine" would have been my whole security posture, by accident.
Pulling secrets out of reach
The immediate fix was simple: rotate the key, assume the old one burned. Rotation is cheap, and "it was probably fine" is exactly the thought that turns a near-miss into an incident.
The lasting fix was to make sure secrets can't reach the context in the first place — keep them in the environment, referenced by name, never printed. And to be deliberate about debug commands: verbose output is a classic way for a secret to leap from the environment into the window.
The rule I keep now
Two rules, actually, and I don't bend them:
- A secret never knowingly enters the context. Not pasted, not in a file, not printed by a command I run. If I need to debug an authed call, I redact first.
- If a secret touches the context, it's burned. Rotate immediately, no judgement calls about whether it "really" leaked.
A secret in the context window is a secret you've half-leaked — keep keys in the environment, never in what the agent reads.
Start here: see how to keep secrets safe when coding with agents, least privilege for coding agents, or read the method.
Related
An agent with shell access and secrets in scope is the worst-case setup. How to keep API keys and credentials out of an agent's reach — and out of its context.
Least privilege for coding agents: scope the blast radiusAn agent can only do damage where you let it reach. How to apply least privilege to coding agents — file scope, command limits, no prod, sandboxes.
Defend against prompt injection in coding agentsPrompt injection turns content your agent reads into commands it follows. Why coding agents are exposed, the real incidents, and the defences that hold.