A resident uploads a forged 'new fee schedule' PDF into an open bucket that continuously feeds the city's permitting embeddings. What RAG threat does this illustrate?
Select an answer to reveal the explanation.
Short Explanation
If anyone can drop a PDF into the ingest bucket, they can rewrite what the permitting bot 'knows.' That's knowledge poisoning—treat untrusted uploads like contaminated water, not free training fuel.
Full Explanation
Knowledge poisoning of the RAG ingestion pipeline with untrusted content is the threat illustrated when a resident can upload a forged “new fee schedule” PDF into an open bucket that continuously feeds permitting embeddings. Whatever lands in that ingest path becomes candidate knowledge for the assistant. An attacker who plants false fee text can make the bot confidently cite fraudulent municipal rates, misleading applicants and staff. The root issue is untrusted write access into the continuous embed pipeline, not merely PDF size or encryption quirks.
Context-window overflow from oversized PDFs fails by concept: the scenario centers on forged content changing what the system “knows,” not on exceeding token limits. Model-weight exfiltration via embedding gradients fails because uploading a PDF into an ingest bucket does not extract foundation-model weights; it contaminates the knowledge store. Denial of service caused solely by PDF encryption fails because the described outcome is corrupted answers from trusted-looking forgeries, not service unavailability from encrypted files.
Exam caveat: Continuous RAG ingest from open civic drop locations is a classic knowledge-poisoning surface. Integrity and allowlisting of sources matter as much as retrieval quality.
Operational check: Close anonymous write to the embed bucket, require authenticated curated ingest for fee schedules, add content signing or publisher allowlists, re-embed from authoritative finance sources after purge of untrusted objects, and test that forged fee PDFs no longer appear in permitting answers.