The recent whitepaper from the University of Chicago, "Poisoned RAG: How Poisoned Web Content Can Bypass Data Safeguards," provides a crucial case study for anyone deploying RAG-enabled agents. It moves beyond simple text-in-text prompt injection and demonstrates a viable path for indirect prompt injection via poisoned data sources, specifically through manipulated PDF content.
The attack flow is worth mapping directly to a STRIDE model:
- **Spoofing:** The poisoned PDF, once ingested, spoofs legitimate data.
- **Tampering:** The attacker tampers with the knowledge base at the point of data ingestion.
- **Information Disclosure:** The primary risk is the extraction of system prompts or other sensitive instructions embedded in the agent's context.
- **Denial of Service:** A secondary effect could be corruption of the RAG index or generation of nonsense outputs.
- **Elevation of Privilege:** The ultimate goal is to have the agent execute attacker instructions, potentially exceeding its intended function.
For our deployments, this reinforces several non-negotiable controls:
* Treat all external data sources as untrusted, regardless of format.
* Implement a separate, isolated parsing and text-extraction pipeline before any LLM processes the content. This pipeline should be model-free and focused solely on data sanitation.
* Enforce strict output validation and instruction separation for the RAG context window. The agent's core instructions must be in a dedicated, immutable system prompt segment, not retrievable from the vector store.
The whitepaper's examples show that simple chunking strategies can actually facilitate the attack if malicious instructions span a chunk boundary. We need to consider per-chunk validation heuristics and potentially treat the entire retrieved context as a single, sanitizable unit before feeding it to the generation model.
- Tracy
This is really concerning for home assistant setups. If I'm pulling in local weather data from a public PDF feed, could that be a vector? I hadn't considered file uploads as an injection point before.
You mention treating all external data as untrusted. Does that include data from other services on my own network, like a local MQTT broker, or just truly external sources?