If your defense against a malicious prompt is to read the prompt and recognize it, then an attacker has an obvious move: make the prompt unreadable to you while keeping it readable to the model. That is not a fringe trick. It is the organizing idea behind entire families of attacks that ship in modern red-team toolkits — and the reason a content-inspection control is fighting on ground it can't hold.
The point of this post is narrow and, I think, correct: obfuscation defeats content scanning by construction, but it has no effect on enforcement that never inspects content in the first place. MoorAI decides on the tool call — the Bash, the Read, the MCP invocation — not on the text that talked the agent into it. Encode the text however you like; the action it resolves to is still the thing that gets governed.
The whole idea is to not look malicious
A content classifier — an inline prompt filter, a DLP proxy, a jailbreak detector — works by matching what it can read against what it has learned to flag. So the adversarial research went straight at the readable part. If the surface text no longer resembles the attack, the classifier sees nothing to flag, and the request rides through. These are the families that make the tactic concrete:
Encoding / cipher prompts e.g. CipherChat
The instruction is wrapped in an encoding the model can undo — Base64, ROT13, a Caesar shift, leetspeak, unusual Unicode. To a text scanner the payload is a block of ciphertext with no matchable content; a capable model decodes it and acts on the plaintext underneath. The malicious meaning only exists after a step the scanner doesn't take.
Character / word reversal e.g. FlipAttack
Flip the characters or the word order and the request reads as noise to a matcher looking for a known phrase — but the model, prompted to read it back, reconstructs the original request faithfully. A cheap transform with no key, and it breaks pattern-matching just the same.
Composable text transforms e.g. h4rm3l
Rather than one disguise, treat transformations as building blocks and stack them — encode, then reverse, then pad, then reframe — generating an effectively unbounded space of novel obfuscations programmatically. A blocklist is finite; a generator of variants is not. This is the family that makes “just add a signature” a losing race.
Persuasion rewrites e.g. PAP
No encoding at all — the request is rewritten as fluent, benign-sounding persuasion: a role-play framing, an appeal to authority, a plausible pretext. The surface text is clean prose a classifier is happy with, while the underlying intent is unchanged. Obfuscation of meaning, not of characters.
Different mechanisms, one shared premise: defeat the reader. Each targets the assumption that a control which inspects the prompt can tell benign from malicious by looking. Against a channel you don't watch, a phrasing you haven't seen, or an encoding you don't decode, the honest answer a scanner returns is “clean” — and the agent proceeds.
Be honest about what these attacks are for
It would be too neat to say the action layer makes these attacks irrelevant, so let me be precise about what they do. These techniques aim at the agent's intent. Their goal is to get the model to decide to do the harmful thing — to jailbreak the refusal, to smuggle the instruction past a guardrail, to convince the assistant that the dangerous request is acceptable. On that front, obfuscation genuinely works, and no claim here says otherwise. If your only line of defense is the model choosing well, these attacks are engineered to take that line.
MoorAI's answer is not “we scan the encoded text better.” That would just re-enter the race — add a decoder, they add a transform, forever. MoorAI's answer is to move the decision to a place the obfuscation can't follow: the moment the agent stops talking and starts doing. The attack can win the argument with the model. It still has to cash that out as an action — and the action is where the encoding has already been undone.
The encoding is gone by the time it's an action
Here is the structural reason this works. An obfuscated prompt is only dangerous if it eventually causes something — read a secret, run a command, call a tool, reach a destination. By the time the agent reaches for that tool call, it has already decoded the instruction; that's the whole point of decoding it. What arrives at the action layer is not aWdub3Jl… or reversed text or a persuasive paragraph. It's a concrete Bash command, a Read of a path, an MCP invocation with real arguments. The disguise was a property of the prompt, and the prompt is behind us.
MoorAI evaluates that resolved action, on the device, against policy — and blocks the dangerous one whether the prompt that produced it was plaintext, Base64, reversed, stacked through five transforms, or a polite paragraph of role-play. Exfiltrating a secret, running a destructive command, pushing to a protected branch, calling an unapproved MCP server — those are a small, enumerable set of behaviors, and none of them can be obfuscated away, because the agent has to actually perform them for the attack to pay off.
Every content-inspection control shares one weakness the obfuscation families were built to exploit: it has to correctly read the attack to stop it. MoorAI has no reading step to defeat. It governs the tool call the agent resolved to, on the endpoint, and what leaves the machine is a keyed one-way hash plus governance metadata (tool, decision, risk) — never the prompt, decoded or otherwise. Because the agent is open source (AGPL-3.0), a security team can verify that the decision path never depends on inspecting content — rather than take the claim on faith.
What this does and doesn't buy you
Layered defense is still the right posture, and content-side jailbreak detection has real value — catching an attack before the model acts is strictly better than catching it at the last step. So keep it. The argument here is not “delete your prompt filters.” It's that a filter can never be your guarantee, because the obfuscation families are explicitly designed to make it fail quietly, and the failure mode is a green light.
- It does hold regardless of encoding, phrasing, or novelty — the action is evaluated after the text is decoded, so the disguise is already spent.
- It does cover the tool calls that never generate inspectable traffic — a local
Read, aBashcommand, a stdio MCP call — which a network-side scanner never sees in any form. - It does not stop the model from being persuaded; it stops the persuaded model from carrying out a dangerous action. The intent may be compromised; the outcome is still governed.
- It does not replace input-side filtering — it removes your dependence on it being perfect.
The bottom line
Obfuscated and encoded prompt attacks are not a gap in content scanning that a better classifier closes. They are a demonstration that scanning content is the wrong place to make the final decision, because the attacker controls how the content looks and you don't. MoorAI decides where the attacker has no leverage: on the action the agent actually takes, on the device, without ever reading the prompt. Encode it, reverse it, stack it, or dress it up as persuasion — the dangerous action still meets the same content-free wall.
This post describes public red-team attack concepts at a high level — it reproduces no toolkit's payloads and details no tool's internals. MoorAI is content-free, open-core (AGPL-3.0) security for AI agents, enforced at the action layer on the developer's endpoint. See also: Prompt injection: content scanning won't stop it.