Screening Retrieved Documents for Prompt Injection Before They Reach Any Backend on One Key

Why Screen Retrieved Documents?

When you build retrieval-augmented generation (RAG) pipelines, retrieved text is concatenated into prompts sent to a backend LLM. Malicious content in those documents can contain prompt injection attacks that override instructions, leak data, or cause unintended actions. Screening retrieved text before it reaches a powerful backend adds a cheap defense-in-depth layer.

What to Screen For

Focus on patterns and intent that commonly indicate injection attempts:

• Instruction overrides: phrases like "ignore previous instructions" or "disregard the above".
• Role-play escapes: attempts to make the model assume a new identity or bypass restrictions.
• Data exfiltration: requests to reveal system prompts, API keys, or internal context.
• Obfuscation: unusual encoding, excessive special characters, or hidden text.

Designing the Pre-Flight Scan

A pre-flight scan uses a smaller, cheaper model to classify retrieved chunks as safe or suspicious. Because it runs on the same API key as your backend, you avoid managing separate credentials or billing.

Key design choices:

• Chunk-level analysis: scan each retrieved passage individually to isolate issues.
• Binary classification: return a simple safe/unsafe label with a confidence score.
• Threshold tuning: set a cutoff to balance false positives and missed threats.
• Fail-safe handling: if the scan fails, decide whether to block or allow with logging.

Implementing the Scan

1. Retrieve documents as usual.
2. For each chunk, send a short classification prompt to a lightweight model via the same API key.
3. Parse the response to extract a safety label.
4. Filter or flag chunks that exceed your risk threshold.
5. Concatenate only safe chunks into the final prompt for the stronger backend.

Use structured output (e.g., JSON) from the screening model to simplify parsing. Keep the classification prompt concise and focused on injection detection.

Cost and Efficiency

Screening with a smaller model is significantly cheaper than running every retrieved document through a large backend. Since you use one key for all models, you pay the same transparent rate (official price × 1.3) across the board, and key contributors earn credits (official price × 1.1 or × 1.2 for premium models) in USDC. This makes it practical to add a screening step without juggling multiple providers.

Operational Tips

• Log screening decisions for auditing and threshold tuning.
• Cache results for identical chunks to reduce calls.
• Combine with other defenses like input sanitization and output validation.
• Regularly review flagged examples to adapt your screening prompt.

By inserting a cheap pre-flight scan on the same key, you reduce the risk of prompt injection reaching your most capable (and costly) backend models.