Never let a chatbot do your secrets

Failure one: the answer that was never computed

Of the three failures, hallucination is the most dangerous because it is invisible. A hash is the worst possible thing to ask a language model for: the output is a long string of characters with no pattern, no redundancy and no way to eyeball correctness — precisely the text where "sounds right" and "is right" occupy different universes. The model obliges anyway. It produces 64 smooth hex characters for your SHA-256, and unless you check, that fiction flows onward: into the release notes "verifying" a download, into the incident thread "confirming" a file's integrity, into the runbook. People have caught these inventions only because a real tool later disagreed. The same applies in miniature to HMACs, checksums and signature checks — anything whose answer must be computed bit by bit. A chatbot does not compute; it predicts, and it will predict an answer for a question it cannot answer with the same fluency as one it can. The defence is to only ever take digests from things that run the algorithm: locally, that is the hash generator (MD5 written from the RFC, the SHA family from WebCrypto), and the habit generalises — if a tool cannot show its working, its hash is a story.

Failure two: the refusal, the warning, and the wrong lesson

Sometimes the chat declines instead: decoding a token is "potentially sensitive", identifying a hash is "associated with credential attacks", generating a password gets a lecture. These refusals are not hypocrisy — the same capabilities are dual-use, and a hosted model cannot tell a sysadmin from a phisher — but they teach a bad lesson twice over. First, they strand legitimate work: the on-call engineer debugging an expired token at 3 a.m. does not need a policy, they need the exp claim. Second, and worse, they train people to route around the warning by pasting the secret into the next, less careful service — a random decoder site whose server logs everything, a forum, a pastebin. The safe path has to be the easy path or it will not be the taken path. That is the design brief of this whole family of tools: a JWT decoder that decodes and verifies in the browser tab, a hash identifier that reads a digest's shape without uploading it anywhere or cracking anything, a password generator sampling the operating system's entropy pool — each one doing locally, instantly, the job the chat refused or fumbled.

Failure three: the copy you forgot you made

The quietest failure needs no wrong answer at all. A chat conversation is a stored document: retained in your history, processed on a provider's infrastructure, subject to that provider's retention, breaches, subpoenas and plan administrators. Into that document, people paste the crown jewels with both hands — the .env file "for context", the bearer token from a failing request, the private key the error message mentioned, the password they just generated there. Each paste is a copy of a credential in a system designed to remember, and unlike a file on your disk, you cannot shred it on rotation day; you can only rotate and hope the copies are as private as the policy page claims. The rule that survives contact with real work is mechanical: if a string would trigger a rotation after a breach, it never goes into a chat — not "redacted later", not "just this once", not into the model that promises not to train. Debug with shapes instead: key names, error text, the first four characters. And do the secret-bearing work — decoding the Base64 blob from the config, checking the token, hashing the suspect file — in tools whose defining feature is that the input cannot leave the machine. When the safe tool is one click and zero upload, the paste stops being tempting. That, in the end, is why this batch of tools exists: not because the chatbot is malicious, but because it is a logged, remote, predicting system — and secrets need a local, silent, computing one.

Frequently asked questions