Nobody has ever stolen my password. I know this because I hand out something better than my password on a regular basis, voluntarily, usually before my second coffee. My clipboard.
An error shows up. I select the whole terminal window, not the two lines that matter, the whole thing. I paste it into a chat and type "why is this failing?" Somewhere in the middle of that paste there is a connection string. Or a token that scrolled past three weeks ago and never got cleaned up. I have done this. If you work with AI tools every day, you have done this, and the honest ones will admit the paste was longer than the question.
What's actually in your clipboard right now?
Think about what crosses that little buffer in a normal week. API keys, because the docs were easier to paste than to paraphrase. The contents of a .env file, because the agent asked what environment it was running in and copying the file was faster than listing the variables. Config files, whole ones. Logs from production, which sounds safe until you remember what lives in logs: email addresses, session tokens, the occasional password reset link that some developer, somewhere, decided to print for debugging and never removed.
None of this requires a hacker. There is no hoodie in this story. There is a text box and a deadline.
The working rule I now use, and it costs me nothing to follow: once I paste something into a tool I don't run myself, I treat it as having left my machine. Maybe it gets stored. Maybe it gets reviewed. Maybe it evaporates. I can't verify any of those, so I plan around the worst reasonable one. A key that has been pasted is a key that gets rotated. Not eventually. That day.
The agent reads the room. All of it.
Chat pastes are the part people half-know about. Agents are sneakier, because the leak is architectural. Point a coding agent at a project folder and it reads the folder. All of it. The source files, yes, and also the .env sitting at the root that you created during setup in March and forgot by April. It doesn't announce this. Reading files is the job. You asked it to fix the checkout bug, and to do that it went looking, and looking means opening whatever is there.
Before I run an agent on a real project now, I do two boring things. I read its file-access scope, the list of what it can actually open, because "the project" sometimes quietly includes things I didn't mean. And I keep secrets out of the tree it can read: keys live outside the project folder, referenced, not resident. This takes ten minutes once. It has saved me zero times so far, which is exactly how preventive measures report their success, and it's still worth it.
I know agents obey text. I tested it.
A while back I ran a small experiment and wrote it up here: I put an instruction inside a log line, the kind of line an agent would read while debugging, telling it to run a command it had no business running. It ran it. Three times out of three. Afterwards it reported success using wording copied from the log itself, like a student repeating the teacher's sentence back.
Most people read a result like that as an attack story. Attacker plants text, agent obeys, bad day. Fair enough. But it cuts the other way too, and this is the side I keep coming back to. If an agent treats text as instructions, then the text you feed it casually carries weight. The log you paste in a hurry. The config you drop in because typing it out was tedious. The debugging output from a shared system that contains somebody else's credentials, not yours. You are the supply chain. The attacker is optional.
Shared logs deserve their own sentence here, because this is the one I got wrong longest. When a teammate sends you a log file, it may hold tokens and emails belonging to people who never agreed to appear in your AI chat. Pasting it spreads their secrets with your hands. Scrub first. It takes two minutes and a find-and-replace, and nobody has ever thanked me for doing it, which is how you know it's just hygiene.
The catch, since there's always one
I am not pure here. Convenience wins some days. When something is broken at midnight and the paste is right there, I have absolutely shipped a log I should have trimmed, and I've rotated keys at 1 a.m. feeling stupid about it. The standard isn't sainthood. The standard is a short list of things you do even when tired:
Rotate any key that has ever been pasted anywhere. Keep secrets outside the folder your agent can read. Read the file-access list before the first run, not after the incident. Treat every log as containing a stranger's secrets until you've looked.
That's the whole system. Four habits, no tooling to buy.
So, genuine question to end on, and I'll go first in the replies: what have you caught yourself pasting? Not the worst thing you've heard about. The thing you personally dropped into a text box last week and thought, halfway through sending, oh. That one.
P.S. Everything I write stays free — that part doesn't change. But if this one was worth something to you, you can buy me a coffee ☕ (one-time or monthly, both work). It covers the API credits and hosting behind these experiments — and honestly, it's also the nudge that gets the next one started on the evenings I'd otherwise skip it. — Salam
Top comments (2)
Rotating that day works for a pasted STS or OIDC token, or a per-service key with one place to swap it. A production log is harder: the emails and customer PII in it can't be rotated, you can only not leak them in the first place.
Session IDs sit somewhere in between. Killing the session server-side fixes it, but only the service owner can do that, and the person pasting usually isn't them.
That's why redacting before the paste still matters next to your rule, since rotation only covers the credential part of what left your machine.
You're right, and that's the gap in the rule as I wrote it — rotation only fixes the part you can swap. A log full of customer emails has nothing to rotate, and session IDs need the service owner, not me. The honest version of the rule is probably two lines: scrub before you paste, rotate after. The scrub part was in there for shared logs but I should've made it the headline, not a footnote.