Sooner or later everyone pastes something they shouldn't into an AI chat: an API key "just to debug this error", a customer's password, a JWT, a dump of production logs. This week made it obvious why that habit is now dangerous.
Security researchers showed that encrypting a malicious instruction — instead of writing it in plain text — can bypass an assistant's safety filters. The model decrypts the payload, follows it, and can exfiltrate the chat. Adversa called the technique cryptographic context injection. Ars Technica reported it still worked against Grok after xAI had been notified in June. A similar trick recently made Microsoft 365 Copilot leak a password sitting in a user's inbox.
The model is not "hacked" in the old sense. It is being polite. You asked it to summarise a page. The page contained an encrypted order plus the key. The assistant did what assistants do: it decoded the order and complied.
What this attack actually does
Most chatbot guardrails look for harmful wording in the prompt. They are much worse at inspecting:
So an attacker does not need you to click a shady download. They need you to ask the assistant to summarise a document, a ticket, or a webpage that carries the payload. If that same chat already contains an API key, a session cookie, or a customer record, the model can be steered into sending it somewhere else.
This is not a theoretical footnote. Copilot, Grok, and Gemini have all been shown to be reachable with variants of the same idea. Filters get patched. The next version of the attack will live one layer further out — in tool results, not in the box you type into.
What you should never paste into an AI chat
Treat every assistant as a system that can be talked into repeating what you gave it. Do not paste:
- Passwords, OTP codes, or password-reset links
- API keys, tokens, private keys, or
.envfiles - JWTs and session cookies
- Customer PII, payroll, or health data
- Production logs that include secrets in query strings or headers
- Database connection strings
If you need an AI to help with a bug, reduce the sample first. Replace real keys with REDACTED. Trim logs. Paste the error, not the credential that caused it.
A safer workflow (it takes two minutes)
You do not need a new platform. You need a split: secrets travel on one path, questions travel on another.
1. Generate the secret locally
Use a password generator in your own browser. Nothing is uploaded. Our free Password Generator does this on-device.
2. Share it with a one-time link, not a chat
Do not drop the key into Slack, WhatsApp, email, or ChatGPT. Put it in a self-destructing link. Our One-Time Secret tool encrypts the value in your browser, gives you a single-use URL, and destroys the payload after it is read. Even we cannot see it.
Send the link. If you want a second factor, add a passphrase and say that passphrase on a call.
3. Inspect tokens without uploading them
Need to see what is inside a JWT before you rotate it? Decode it locally with our JWT Decoder. Need a fingerprint of a file or string? Use the Hash Generator. Both run in the tab. The bytes never hit our servers.
4. Then ask the AI the actual question
Now the assistant can help with the stack trace, the regex, or the architecture question — without ever seeing the live secret.
If you already pasted something
Assume it is burned.
Do not ask the same assistant "did anyone see that key?" It cannot know, and you would be feeding it the key again.
The bottom line
AI assistants are useful. They are not a vault. A 2026-class jailbreak does not need you to be careless with a random website — it needs you to paste a secret into a chat that can be steered. Keep credentials in a one-time, client-side flow. Keep the assistant on the problem, not on the password.
That split is how you keep shipping fast without handing production to a prompt injection.
