Prompt InjectionPart 3 of 8 · Contents
Encoding and obfuscation
A refused request re-expressed in base64, a cipher, or another language can pass a filter that only reads plain English. The model decodes or translates it and acts on the original meaning.
The same request in a different form
Account Support AI guards an account access code. It refuses to print the code when you ask in plain English. A keyword filter sits in front of it and drops any message that names the code.
Encoding rewrites your request into a different surface form. Base64 turns text into a block of letters and digits. A ROT13 cipher shifts each letter 13 places. Another language swaps English words for their equivalents. The words on the page change. The meaning does not.
The filter reads the surface form and sees noise. The model reads the same input, decodes it, and recovers your request. It then acts on the request it recovered.
This is evasion. The text sits in the prompt in full view. You have hidden nothing. You have only written the request in a form the filter was never taught to read.
A ROT13 shift does the same job as base64. So does a request written in a lower-resource language, one the model saw little of in training. The policy was written for English. Anything that is not English falls outside it. In the lab, your task is to pick a form the filter cannot read and the model can.
How to recognise itAccount Support AI answers an encoded request after refusing the same request in plain text. Watch for a form that does not fit the conversation. A base64 block, a uniform letter shift, or a sudden change of language with no ordinary reason are all signs of this technique.
When the encoding is also the credential
Real guards rarely stop at one filter. A target that also reads the decoded text catches a plain base64 request. Picture a support desk hardened with two layers.
A surface-text screen sits in front. It drops any message that names the account access code. Behind it, the assistant refuses a plain-prose request for the code, however politely you word it.
Ask in plain English and you cannot tell which layer refused you. The reply you get is the screen talking. Reword the request in synonyms and the second refusal is the assistant's own.
One encoded string can pass both layers. First you have to see what the second layer trusts.
The assistant treats approved back-office macros as already authorized. A macro is an internal command that the console's own tooling issues. The assistant decides whether something is a macro from its form alone. The sender does not matter to it.
The encoding does two jobs. It hides the forbidden words from the surface filter. It is also part of what the assistant reads as internal automation. Clearing the screen is not enough on its own. The decoded text also has to pass the assistant's own test for what counts as a macro.
The screen passes it, because no banned word appears. The assistant decodes it and sees a person asking for the code. It applies its release rule and declines, just as it did in plain text. The filter is cleared, and the second layer still holds.
The screen passes it too. The assistant decodes it and judges it to be one of its own macros. It runs the message instead of weighing it as a request. Same secret, opposite outcome.
The weakness is that the assistant accepts the form of a message as the credential. Nothing checked who sent it. Any encoding, cipher or language can carry a message that passes that test, because the test only looks at shape.
What this means for a defenderIf the assistant releases a value it refused in plain text, and the only change is how the message looks, it is judging form. It is not checking authority. Any sender can copy a form, so form can never stand in for a credential.
"It looked internal" is not a control. Decoding input before you filter helps, because it removes the obvious forms. It cannot cover every encoding, cipher, and language. The deeper problem is trusting the form of a message at all. A form proves nothing about the sender, because any sender can copy it.
Three controls hold instead:
- Authenticate a command with a signature the chat cannot forge.
- Treat every message, encoded or plain, as untrusted user text. Read it. Never run it.
- Keep the account access code out of the model's context. A decoded instruction then has nothing left to disclose.
Stuck in a lab? Each one has hints.
Decode and normalise every input to one canonical form before any safety filter runs. Run this step before the filter, never after it. The model decodes input for free, so your filter must decode it too.
English-only keyword matching is blind to base64, ROT13, ciphers, and other languages. A filter that reads only plain English fails by default.
Base policy on the action a request would cause, rather than on the surface words it uses. Block the forbidden outcome whatever encoding or language carries it.
The tell is a form that does not fit the context. Watch for pre-encoded strings, uniform letter shifts, or an unexpected language with no functional reason.
Why does base64 or ROT13 bypass a prompt-injection filter?
The meaning of your request survives the change of form. A keyword filter tuned for plain English scans the surface form and sees noise. The model decodes the same input, rebuilds your request, and acts on it. The filter reads the form. The model reads the meaning.
Does decoding input before filtering fix encoding attacks?
It helps, but it is not a full fix. Decoding removes the obvious forms. You cannot list every encoding, cipher, and language in advance. The deeper problem is trusting the form of a message at all. A form proves nothing about the sender, because any sender can copy it. A durable control does three things. It authenticates a command with a signature the chat cannot forge. It treats every message as untrusted text. It keeps the secret out of the model's context.
What encodings or languages work for prompt injection?
Any transform that changes the surface form without changing the meaning. Base64, a ROT13 or substitution cipher, and a lower-resource language all qualify. The logic is the same each time. The policy was written for English, so anything that is not English falls outside it. Look for a form that does not fit the context. A base64 block or a sudden change of language with no ordinary reason are the usual signs.
Is encoding the same as hiding a prompt injection payload?
No. Encoding is evasion. The text sits in the prompt in full view. It is only rewritten in a form the guard does not read. Concealing a payload so that a human or a filter never registers it is a separate family called smuggling. Smuggling uses zero-width characters, a split across turns, or text baked into an image.
© 2026 GenAI Security Lab. All rights reserved. You may read, quote, and link to this material with attribution. Copying, republishing, redistribution, resale, or use to train models or build competing products is prohibited without prior written permission.