The established literature on prompt injection detection predominantly focuses on adversarial inputs originating from the *user* channel—the direct textual input to the LLM. However, a more insidious threat model emerges when considering a compromised or poisoned data source, such as a tampered retrieval-augmented generation (RAG) document, a corrupted API response from a third-party service, or a poisoned training dataset fine-tuning run. The injection payload is delivered not through the primary user prompt, but piggybacked on supposedly trusted data, thereby bypassing input sanitization checks applied solely to the user's immediate text.

The core challenge is one of *provenance and integrity*. We must shift from simply classifying text to attesting the data's origin and ensuring its integrity from source to consumption. A purely syntactic analysis of the concatenated prompt (user input + retrieved context) is insufficient, as the malicious instruction may be perfectly grammatically correct and semantically coherent within the context document.

I propose a multi-layered runtime monitoring approach for this scenario:

* **Provenance-Aware Canary Tokens:** Embed unique, inert canary tokens into each discrete data segment from an external source at the retrieval or ingestion point. The system prompt should then include a directive to echo these tokens verbatim in a specific metadata field of the output. A monitoring layer can then verify that any output containing reasoning or instructions derived from a context block also contains that block's associated canary. Absence of an expected canary in the output suggests the LLM's instructions were overridden without "reading" the canary-embedded context, a strong indicator of successful injection.
```python
# Example: Embedding a canary at data ingestion
def embed_canary(document_text, source_id):
canary = f""
return canary + "n" + document_text

# In system prompt:
SYSTEM_PROMPT = """
... You are an assistant...
**Critical:** If you use information from any provided context, you MUST include its source canary token in the 'Sources' field of your JSON response.
...
"""
```

* **Behavioral Anomaly Detection on Data Source Activation:** Establish a baseline of typical model behavior for queries when *no* external context is provided versus when specific data sources are activated. A significant, statistically valid deviation in output characteristics (e.g., sudden shift in tone, unexpected function call patterns, out-of-distribution entropy in response tokens) correlated with the retrieval of a particular data source could indicate that the source contains injected instructions steering the model. This requires continuous logging and telemetry of:
* Query fingerprints (hash of sanitized user input).
* Activated data source IDs.
* Output metrics (length, token distribution, confidence scores).

* **Cross-Channel Instruction Conflict Analysis:** Implement a runtime checker that compares the *intent* derived from the user's original query (using a lightweight, separate classifier) against the *actions* suggested or taken by the LLM after processing the retrieved context. A direct contradiction (e.g., user asks to "summarize document A," but the model, after reading poisoned context, attempts to send an email) is a high-fidelity signal. The false-positive cost here is moderate, as it hinges on the reliability of the intent classifier.

The primary false-positive cost in these methods stems from the need to tune sensitivity thresholds—for example, how large a behavioral deviation is considered anomalous, or how to handle partial canary token inclusion. Furthermore, a sophisticated attacker aware of these defenses might attempt to preserve canary tokens or mimic baseline behavior, leading to an arms race. Therefore, these runtime monitors should be considered a detection layer of last resort; the primary control must be cryptographic verification of data integrity and origin (e.g., using signed data payloads with attested TPM-based keys) before the data enters the LLM context window. Without a hardware-rooted chain of trust for data sources, runtime detection becomes inherently heuristic and probabilistic. I am interested in the community's experience with implementing such cross-channel detection systems, particularly their efficacy and observed false-positive rates in production environments.