An AI coding agent ran printenv to debug a deployment and put a live AWS session token into its context window. Nobody did anything wrong. That's why we built ctxcop, an open source CLI that strips secrets out of agent context before the model sees them.
Your AI coding agent doesn't need your credentials to do its job. We built a cli hook that stops handing them over, and open sourced it.
A few months ago I watched an AI coding agent debug a failing deployment. It ran printenv, which is what I'd have done too. The problem is that printenv on that box printed a live AWS session token. That token went into the model's context window, then into the conversation transcript sitting in plaintext on the laptop, and then off to somebody else's computer. It could have easily also ended up in a whole mess of logs.
Nobody did anything wrong. The agent was being helpful and the engineer was being productive. A production credential just ended up somewhere none of us had decided it should go.
That's the whole reason for this post.
The reflex
When a powerful new tool shows up, the reflexive security move is to lock it down. Write a policy, ban it in the handbook, route it through a review board. It feels like control.
It isn't. Engineers picked up AI coding agents faster than any tool I've seen, and they did it whether or not security signed off. Ban the tool and you don't get safety. You get the same credential exposure happening outside of a sanctioned workflow, and a security team that can no longer see any of it. You lose productivity and visibility at the same time.
So "against" was never really the winning side. The move that works is to meet the tool where it runs and build the guardrail into it.
Need to know
The guardrail comes from an old idea: need to know.
I want to be careful about the claim here, because the loud version of this story is wrong. I'm not saying you can't trust Anthropic or OpenAI (or Deepinfra et al). Most providers are contractually solid, and several of them won't train on your context. But they'll still have logs, sometimes in multiple places for multiple reasons with multiple of their own vendors. No, my claim is smaller and harder to argue with: You shouldn't hand any third party more information than it needs to get the job done. Nobody has to be acting in bad faith for that to matter. Keeping the blast radius small is just good practice, and a coding agent's context window is a new place to practice it.
An agent needs to reason about your code and the world that code operates in. It doesn't need the literal value of your database password to do that. It needs the shape of the problem, not the secret. So we stopped giving it the secret.
A cop for the context window
That's ctxcop, short for context cop.
It's a simple CLI tool that installs into whatever agent you run: Claude Code, Cursor, Codex, Pi, OpenCode, Aider, whatever we’re all rocking tomorrow. It hooks the moments where a secret could cross from your machine into the model's context. When the agent runs a command, reads a file, or calls a tool, ctxcop looks at the output before the model sees it and replaces anything that looks like a credential:
AWS_ACCESS_KEY_ID=<REDACTED:aws-access-key:OLIA>The model gets a placeholder where the secret was. The command still ran with the real value in your shell. The model just never saw it. Nothing leaves your machine. There's no proxy or gateway to run and no account to create. You run ctxcop install, it finds your agents and wires itself in. It's open source under MIT, because blind faith is always the wrong move when you're working with secrets.
The redaction is only half of it. When ctxcop pulls a secret out, it also leaves the agent a note: that was a credential, we took it out, and if you need the value, reference it indirectly. It primes the agent at the start of a session too, so the conventions aren't a surprise later. That way the agent doesn't get a mystery placeholder and start guessing. It doesn't try to base64-decode the redaction or re-run the command to get the real thing. It's told what happened, and it keeps working.
That part is deliberate: we aren't just trying to stop fighting our developers, we're trying to stop fighting the agent too. A guardrail that silently mangles an agent's inputs is one it'll eventually learn to route around. If a tool explains itself instead, the agent can cooperate with it.
None of the hard part (the actual finding of secrets) is ours. ctxcop is built on betterleaks, the maintained successor to gitleaks, and without it this project would have been a giant pain to build. We get its whole detection engine and ruleset for free. What we lean on even more is how extensible it is. The rules are just config, so you can tighten ours, add patterns for your own internal sensitive data, or load a whole extra pack with one environment variable. That's exactly how ctxcop ships an optional crypto and financial PII ruleset: off by default, one variable to turn on. Your secrets are not our secrets, and betterleaks makes it easy to say so.
How it works
Every harness has its own approach to extensibility, so this varies from harness to harness. Check out https://github.com/webflow/ctxcop/blob/main/docs/harnesses.md for details, but let’s dig into Claude Code’s hooks as an example:
On SessionStart, ctxcop steers the agent by giving it a preamble using hookSpecificOutput.additionalContext which tells Claude that ctxcop is hooked into the session, what a redacted pattern looks like, and what to do if it encounters one.
When the agent decides to use the Bash tool, ctxcop hooks PreToolUse and rewrites the agent’s intended command:
cat .env ⇒ ctxcop run -- bash -c ‘cat .env’
When ctxcop wraps a command, it scans stdout and redacts per the rules it’s configured with, leaving enough for the agent to reason about, along with a reminder about how to work with secrets without polluting context:
ANTHROPIC_API_KEY=<REDACTED:anthropic-api-key:DwAA>
API_URL='https://test.example.com'
SLACK_BOT_TOKEN=<REDACTED:slack-bot-token:ItGB>
SLACK_DEPLOY_WEBHOOK_URL=<REDACTED:slack-webhook-url:UxPp>There are several other surfaces for Claude Code: if a user pastes a secret into the prompt, the agent reads a file, or uses MCP servers, ctxcop hooks into those events as well, being careful to preserve the value of the operation while maintaining confidentiality where possible.
What it doesn't do
A security tool that oversells itself is worse than no tool, so here's what ctxcop doesn't do.
It works on content. It redacts what the model sees. It isn't a firewall, an egress proxy, or a behavioral monitor. It won't stop an SSRF. It doesn't know or care about a poisoned MCP tool or a slow, multi-step exfiltration. Those are real problems and they live at a different layer. ctxcop sits next to a network egress control, it doesn't replace one.
Pipelock and Runlayer are good examples of that other layer. They work on the network instead of the model's view of it, and enforce at the egress point instead of on your box. That's a different operating model with its own real advantages, and it's genuinely worth a look. The folks behind Pipelock also publish an external, vendor-neutral benchmark called agent-egress-bench. We ran the parts of it that apply to ctxcop and put the results in the repo, including every category we don't cover. If you want to know where the edges are, they're written down.
Working with it
I think this is what it looks like for a security team to grow up around a new tool instead of standing in front of it.
The agents aren't going anywhere, and neither is the pressure on every engineer to use them. The job for security isn't to be the department of no, it’s to engineer security into your users’ workflows. Using a tool safely should be easy, intuitive, and clear about where risks are.
ctxcop is one guardrail for one boundary. It's open and it's live at github.com/webflow/ctxcop. Read it, run it, and tell us if it helps you sleep better at night.
