Most of us have the "don't commit secrets" reflex drilled in. Pre-commit hooks, secret scanners in CI, .env in .gitignore. Good. That covers the repo.
It doesn't cover the context window.
The gap: the repo is not the boundary anymore
When you work with an AI coding assistant, what leaves your machine isn't just the file you're editing. It's whatever you paste, whatever the extension decides is relevant, and whatever the agent reads while it's "helping." The security boundary now includes the editor extension, the chat history, any telemetry, and every service that processes that context on the way to the model and back.
Secret scanners watch commits. Nothing in a typical setup watches what you paste into a chat panel at 6pm while a deploy is failing.
Here are the usual ways a secret ends up in context without ever touching git.
1. The failing test that prints its config
An integration test fails. The assertion message helpfully dumps the client object, which includes the connection string with the password inline. You copy the whole test output into the assistant and ask "why is this failing?"
The question was about the assertion. The payload included the credential.
2. The environment dump
$ env | sort
...
AWS_SECRET_ACCESS_KEY=...
DATABASE_URL=postgres://app:...@db.internal:5432/prod
STRIPE_SECRET_KEY=sk_live_...
"Here's my environment, why can't the app find the config?" is a completely normal debugging move. It's also the fastest way to hand over every key on the box in one paste. Agents that can run shell commands can do this on their own if you let them.
3. Logs that log too much
A verbose HTTP client logs request headers. One of them is Authorization: Bearer .... You paste 200 lines of log to get help with a timeout, and line 143 is a live token.
4. The copied snippet
Someone shares a "working example" in Slack with the key still in it. You paste it into the assistant to adapt it. Now it's in two systems you don't control instead of one.
(These are illustrative scenarios, not specific incidents, but if you've debugged anything under pressure you've probably seen at least one.)
What actually helps
- Minimize what you send. Paste the relevant ten lines, not the whole log. Ask about the error, not the environment.
- Redact before pasting. Mask tokens, connection strings and headers. A small shell function or editor snippet that scrubs obvious patterns is worth having.
- Scope your credentials. If a dev key does leak, it should only be able to touch dev. Short-lived, least-privilege keys shrink the blast radius.
- Check how your tool handles data. What's retained, for how long, whether it's used for training, what the extension sends automatically, where telemetry goes. These are often separate settings and separate policies. One "privacy" toggle rarely answers all of them.
-
Restrict what agents can read. If your assistant can open files and run commands, keep
.env, credential files and secret stores out of its reach.
If it already happened
Deleting the chat message is not remediation. You don't know what was logged, cached or forwarded before you hit delete. Treat it like any other exposure: rotate the credential, revoke the old one, check access logs for use.
The reframe
Secret management used to be a version control problem. With AI tools in the loop, it's a data-flow problem: anything that reaches the model's context has, to some degree, left your control.
The safest secret is the one that never enters the context in the first place.
How does your team handle this today? Do you have any tooling that checks what goes into an AI assistant, or is it all down to developer habit?
Top comments (2)
The habits that hold up are the ones that cost nothing in the moment. Keep production credentials off laptops entirely, so the worst thing in a paste is a dev key. Have the app fail with a message that never prints its config or connection string. Load secrets through a wrapper that injects them at run time, so they are not sitting in env output to be pasted. And treat the 6pm failing-deploy case as the real threat model, since that is when people skip the redaction step.
Redaction before pasting is the same class of control as "don't commit secrets" — it works until the deploy is on fire and you paste the whole log at 6pm. The more durable lever is on the agent side: if the assistant can run
env | sortor read.env, a human redaction habit is the only thing standing between you and a full dump, and that habit is exactly what pressure erases. Regex scrubbing is also whack-a-mole since providers rotate token prefixes and opaque keys slip through, so I'd rather bound the blast radius with short-lived scoped keys and log egress from whatever the extension sends — because delete never un-sends anything.