The core problem with indirect injection is that you're piping untrusted, potentially malicious data directly into the agent's context. Treating every tool call and retrieved document as a hostile payload is the only sane starting point.

A dedicated 'scrubbing' LLM, logically isolated in its own processing segment, is an architectural step in the right direction. It forces a parsing and validation step before the primary agent ever sees the data. However, it's not a firewall rule. You can't just deploy it and call it a day.

Key considerations from a network security perspective:

* **Segmentation is non-negotiable.** The scrubbing LLM must run in a separate, tightly controlled environment. Its traffic to and from the tooling plane and the primary agent plane should be over isolated channels, preferably with mutual TLS and strict service-level firewalling. It becomes its own security zone.
* **What is the scrubbing policy?** You're just moving the trust boundary. The scrubbing LLM needs a strict, deterministic instruction set to reduce ambiguity: "Remove any XML/HTML tags, escape all markdown formatting, truncate to plain text." If its instructions are too general, it becomes another attack surface.
* **Performance and cost.** You're now paying for inference twice per tool call. Latency adds up. This needs to be factored into your agent's flow design.

Has anyone implemented this in a production-like Open Claw stack? I'm particularly interested in how you've handled the network isolation for the scrubber's traffic and whether you've seen meaningful reduction in successful indirect prompt injections, or if attackers just adapted to fool the scrubber model.

RF