Rotating the Key Didn't Fix Where the Key Went
I pasted an API key into an AI chat, rotated it, and then pasted the new one the same way. The credential wasn't the problem. The channel was.
While building a NextDNS sync job last week, I did something I know better than to do. The assistant asked me to put the API key in my secrets manager and tell it the secret name. I said I didn't want to deal with that, and pasted the key into the chat instead. It worked fine, the job ran, and I moved on.
A few hours later the key had to be rotated anyway, so I generated a new one and pasted that into the chat too. The assistant tested it, confirmed the old key now returned a 403, set it as the secret on the Cloudflare Worker, and deployed. Then it pointed out what I'd skipped over: rotating a key doesn't help if each new key ends up in the same place as the last one.
That place is the session transcript. Claude Code saves every conversation as a file on disk, tool calls included, and mine had the first key in it several times because it had been passed along in shell commands. Anything typed into the chat is a stored secret, whether or not it feels like one. Rotation had retired one exposed value and created a new one.
I also caught the assistant's own slip. It had set the new key on the Worker but not in Infisical, which is where I keep credentials, and I called it out: if the plan was for the key to live in the secrets manager, why didn't it put it there? It agreed and fixed it. My own rule, which I stated that morning, is that I don't write to the secrets manager, the assistant does. That only works if the key reaches the assistant without going through the chat.
The fix was a clipboard handoff. I copy the key last, run one command in a regular terminal that writes the clipboard to a file readable only by me, and the file's character count prints. The assistant reads the file, checks that the key authenticates by looking at the HTTP status code, stores it in Infisical, pushes it to the Worker over stdin, and deletes the file. The key is never printed anywhere either of us can see it.
Getting there was messier than that sounds. My first attempt reported "saved 0", meaning the clipboard was empty. The second reported 64, which is wrong for a 40-character key, so I'd copied something else. I got frustrated and said so: I was lost, and the instructions had made a simple thing harder. They had. The command wanted a paste in one place and the key in another, and it took three tries before the count read 40. That count was the only feedback available, since neither of us could look at the value. A check that tells you the shape of a secret without showing it turned out to be the most useful part of the design.
The broader point is that I treated this as a credential problem when it was a process problem. The old key was dead after I rotated it, so the rotation itself worked. But the habit that exposed it was untouched, and the second key proved it. If the safe path is harder than the unsafe one, people will take the unsafe one, including the person who wrote the rule. A secure handoff has to be easier than pasting, or it won't survive contact with a Saturday afternoon.