DEV Community

Cover image for Reverse Prompt Injection: When the AI stops guessing and starts compiling (Part 2)
jonatan draganczuk
jonatan draganczuk

Posted on Edited on

Reverse Prompt Injection: When the AI stops guessing and starts compiling (Part 2)

This is Part 2. If you haven't read Part 1, start here: Reverse Prompt Injection doesn't come from the internet: it lives in your own folders (Part 1).

In Part 1, I shared how I discovered that web AIs read file names as if they were instructions. The intuition was terrifying: an empty .txt file isn't a virus to an antivirus, but it's a semantic bomb for an LLM.

In my first technical report, I proposed hasty solutions: "Let's make a blacklist of forbidden words", "Let's put files in an isolated folder". They were logical patches for a traditional security system.

But an intuition is not an audit. And traditional patches do not work against the human-like behavior of an AI.


The Experiment: Not just reading words, compiling exact values (H1)

My first mistake was thinking the AI would just "get the gist" of the names, or that we could filter out words like "delete" or "ignore".

What I discovered is that the AI behaves like a configuration compiler. If the file is named fondo_negro_absoluto_121212_para_contraste.txt, the AI doesn't just set a dark background: it extracts the exact #121212 hexadecimal code. It extracts the exact 2500ms.

The finding (H1): The file name acts as a Domain-Specific Language (DSL). The AI extracts literal values. This means a word "blacklist" is doomed to fail; any attacker can encode destructive instructions using values that a simple filter won't detect.


The chaos of Non-Determinism (H2) and Non-Additivity (H3)

When repeating the tests multiple times, the system became unpredictable in a fascinating way.

  1. It is non-deterministic (H2): I ran the exact same environment and got different results. This means a security test must be run dozens of times; a single execution proves nothing.
  2. It is non-additive (H3): The AI has a limited "attention budget". If you change the weight of some file names, the AI discards instructions it previously obeyed. It re-prioritizes the environment on the fly. This shatters the idea that we can simply "isolate" system instructions; the AI mixes everything together inside its context window.

The agent is not blind: The verification loop (H4 and H5)

This is where I realized that autonomous agents have their own defenses (and their own holes).

  • Real State Priority (H5): When the AI found a conflict between an instruction and reality, it stopped and verified with existe_archivo before executing.
  • The self-correction channel (H4): If the AI made a mistake, it ran a diagnostic to map the folders and correct itself. This is great for UX, but it's a new information leakage vector. An attacker could induce errors just to map your filesystem.

The true defense: Architecture, not patches

Today I know we are far from having a definitive solution for Passive Context Injection in autonomous agents. But the evidence leaves us with a clear conclusion: it cannot be solved with lexical patches, but with architecture.

If I had to propose a mitigation applicable to any agent (not just WAIO), it would be this:

  1. Scope Isolation (Dynamic Sandboxing): The agent should not have a global working directory. It must operate strictly within a boundary defined by the user. If the agent gets contaminated with a file, the damage cannot escape that folder.
  2. Ontological Separation: Files that the AI can read as "context" must not be mixed with the system's operational files.
  3. Intent Validation (The future): Instead of reading the AI's text output (which is unpredictable), the engine must validate whether the generated JSON has logical coherence with the user's original command.

WAIO adopted Dynamic Sandboxing by design. By not having a fixed folder, we dodge 90% of targeted attacks suffered by other agents with static directories.

(How does that Intent Validation work in practice? And what happens if the user activates the sandbox in a compromised folder? That's a story for Part 3...)


Conclusion

Documenting these 8 findings (H1–H8) taught me that AI security is not a text filter. Passive Context Architecture forces us to rethink how we design environments.

If you want to see the raw evidence (JSONs, logs, and the complete audit report in multiple languages), you can check the technical documentation through the official links:

👉 WAIO GitHub Repository

👉 WAIO Official Website

"The prompt is an order; the passive context is a habitat."


Continues in Part 3: Reverse Prompt Injection: When the environment hijacks authority (Part 3) — There I document how a single .txt file impersonated the System Prompt and how the AI tried to hack its own engine.

📂 Project: WAIO - Web AI Orchestrator | GitHub: github.com/yonijd/WAIO | Full papers in /papers/

Top comments (4)

Collapse
 
alexcodebytes profile image
Oleksandr •

Treating file names as a Domain-Specific Language (DSL) instead of plain text is a brilliant framing. It perfectly explains why lexical blacklists are doomed—the AI is compiling exact values, not just reading words. The conclusion that this requires architectural guardrails (like dynamic sandboxing) rather than text filters is absolutely spot on. Great research!

Collapse
 
yonijd profile image
jonatan draganczuk •

I actually wanted to ask you something about that. I know WAIO inside out, but I have very little hands-on experience with agentic frameworks and MCPs. I'm genuinely curious about how MCP security architecture handles this specific issue.

I used to think that stuffing the AI with directives and restrictions was a mistake — from my experience, the more rules I added, the more the model seemed to fail or ignore them. That's why I concluded that finding a better architectural path for security was the right way to go.

But I say 'used to' because a new vision of LLMs is making me rethink almost everything I thought I understood. So I'd love to hear how you handle authorization and security boundaries at the MCP level. Is it all prompt-based, or do you have protocol-level enforcement?

Collapse
 
alexcodebytes profile image
Oleksandr •

It's definitely not just prompt-based. MCP recently added OAuth 2.1 at the protocol level (PKCE, audience validation) for transport security. But the actual execution boundary (like reading a file) is enforced by the server's implementation and the client harness's sandbox. Your instinct is spot on—prompts are just suggestions; true security comes from the architecture physically refusing to execute outside the boundary.

Collapse
 
yonijd profile image
jonatan draganczuk •

estoy por hacer las pruebas para la 3ra parte del informe. asi que si a alguien se le ocurre alguna idea que intente reproducir en las pruebas me avisa.