Runtime Signal Patterns That Expose Adversarial Prompts Entering an LLM Pipeline Through Third-Party Plugins

Indirect prompt injection detection in enterprise retrieval-augmented generation pipelines requires runtime monitoring of task drift, instruction changes, tool use, and data egress alongside filtering user prompts. Third-party plugins can bring hostile instructions into content the system was allowed to retrieve. The strongest detection approach combines internal-state probes, semantic and entropy signals, and action monitoring because each exposes a different stage of the attack.

Why plugin-mediated prompt injection is a structurally different threat from direct injection

Direct injection starts in the user turn, where defenses expect to find instructions they need to check. Plugin-mediated injection comes in through a tool response, retrieved document, email body, or configuration file. The user may have done nothing hostile. A routine request to fetch information brings the payload into the model’s context, bypassing defenses concerned only with whether the user’s request is safe.

The IEEE S&P 2026 chatbot-plugin study found that plugins expose models to indirect injection when they fail to separate trusted website content from third-party material such as customer reviews. That creates an asymmetry in the attacker’s favor. Poisoning an upstream source once can reach every downstream user whose agent retrieves it, without a separate attack against each person. When those agents have file access, code execution, APIs, or repository credentials, the consequences extend beyond unsafe text. Defenders need to check model behavior and downstream actions as well as what crosses the input boundary.

How the MCP protocol and plugin trust hierarchies turn data channels into execution paths

With MCP, this problem spreads across connected tools. Content received through a tool call can become an instruction for the model’s next action. Once that happens, a data channel has become an execution path, and inspecting the original user prompt cannot explain what the system is now doing.

The MCP threat-model paper reports that its STRIDE analysis puts most of the threats it found under tampering and information disclosure, and that tool poisoning and prompt injection are the most common attack types. The chatbot-plugin study found that 8 of 17 tested plugins failed integrity checks, allowing adversaries to forge system messages from low-trust user input. What should distinguish information from an operator instruction is then lost. The Cline/OpenClaw incident and GitInject study show how similar trust failures lead to execution, so every content boundary that feeds the model is a place to check for attacks.

What real-world plugin injection attacks look like as they move through a pipeline

The Cline/OpenClaw supply chain attack in February 2026 began with prompt injection in model-powered GitHub Actions issue triage. Poisoned issue content entered through repository data that the agent was designed to read, and the chain led to a compromised npm package that silently installed OpenClaw on thousands of developer machines. OpenClaw was legitimate software, but its installation was unauthorized. There were no reports that credentials, SSH keys, or cloud tokens had been exposed.

The GitInject CI/CD pipeline study in 2026 found that agents ingesting untrusted PR content with elevated repository permissions were susceptible to at least one attack class in their default configuration across all tested providers. An adversary adds GEMINI.md, AGENTS.md, or CLAUDE.md to the PR branch, actions/checkout includes the merge commit, and the provider CLI loads those files as authoritative operator-level instructions before review begins. An output filter is poorly placed to catch that transition because execution can begin before a final response exists.

Activation delta signals: detecting task drift before the model acts

Activation deltas compare the model’s internal representations before and after it ingests external content. The original query establishes a task direction. If a plugin response redirects that task, the change in activations can expose the shift before the model generates an answer. This is especially useful when an injection asks the model to act differently while making its visible response look normal.

The TaskTracker paper reports that a simple linear classifier on activation deltas achieves near-perfect ROC AUC on out-of-distribution test sets. It also generalizes to unseen attack types, including prompt injections, jailbreaks, and malicious instructions, without training specifically on those attacks. Its position in the pipeline is the distinguishing feature. It reads what changed inside the model rather than relying on an answer the attacker may have instructed it to conceal or sanitize.

The BASIS paper reports that linear probes on pre-generation hidden states predict whether a model has been exposed to injection, with AUROC above 0.90 across multiple models. BASIS also uses sparse probes on attention-derived features to distinguish inputs the model would resist from those that would breach it, limiting over-blocking by refusing the latter. Attention Tracker uses statistical attention patterns to give another view of what happens inside the model. These methods provide early signals. An adaptive attacker may suppress the very drift a probe expects to see, which makes complementary detection necessary.

Semantic and entropy-based signals: catching drift in what the model is being asked to do

Semantic monitoring asks whether the conversation still serves the user’s established goal. DeepContext tracks intent drift across turns through a GRU over task-attention weighted fine-tuned BERT embeddings, reporting strong F1 performance at low latency. The distinction from activation monitoring is useful. DeepContext examines drift in what was said, while TaskTracker examines drift in what the model understood. Surface meaning and internal representation can diverge, so these approaches cover different evasion opportunities.

SENTRY, presented at EACL 2026, uses predictive entropy as an attack-agnostic signal. Its TokenSAR score measures weighted token-level entropy in model output, identifying differences between benign and adversarial prompts without needing prior knowledge of the attack type. Only ten newly generated tokens are required. That makes for a fairly light check on output from plugin payloads with different sources and wording, though it still needs a change in generated tokens that it can detect.

CAD, from Washington University in St. Louis, addresses a different question. Is a sentence malicious in this query and context, or does it merely resemble an instruction? It measures how much each sentence changes query- and context-aware embeddings, which helps tell injected instructions apart from benign material that uses similar language. Context is essential when both share one document. CAD also uses feature-space robust learning and adversarial training with simulated LLM-based paraphrasing to harden classification against changes in wording.

Behavioral and action-layer signals: what the pipeline does after a successful injection

Action monitoring shifts attention from what the model processes to what the system does. An agent that normally summarizes documents but starts calling external APIs produces a behavioral signal independent of model internals. So does an agent reading configuration files outside its declared scope. Comparing tool calls, API invocations, and file access against established patterns exposes deviations even when an internal probe misses the injection.

Data egress needs the same contextual treatment. A standard API response, outbound email, or webhook may be an ordinary channel even when the information it carries falls outside the data scope the agent is allowed to use. The channel alone cannot establish permission. GitInject reinforces why credential access and configuration-file reads belong in this monitoring layer, since its most dangerous pathways arise from infrastructure handling. Installing software without permission, as in the Cline/OpenClaw chain, is also an action-level event.

This layer has a clear timing constraint. It observes outcomes rather than the intent that caused them, so it cannot prevent the first malicious action merely by detecting that the action occurred. It can expose and interrupt the chain that follows. That makes action monitoring an irreplaceable checkpoint, especially for teams without model-internal access, but not a substitute for signals available earlier.

Why each signal family has a blind spot and what a layered detection stack requires

The LAD paper shows that a realistic attacker can break activation-based detection by suppressing most activation drift across tested models. Semantic classifiers face a different evasion path. Attackers can paraphrase an injection to fit its benign surroundings. CAD addresses this evasion path by adding adversarial training to context awareness. Strong performance on a test set does not remove the need to consider an attacker adapting to the detector.

Entropy and behavioral monitoring have their own limits. An injection that preserves ordinary output entropy while directing a background action could evade SENTRY’s signal. Slow or low-volume exfiltration may also remain close enough to a behavioral baseline to avoid an alert. These are different blind spots. Their differences provide the reason to combine layers.

The practical design is overlapping coverage across the pipeline. Context- and query-aware screening belongs at each tool-content boundary before retrieved material reaches the model, while activation or attention probes check processing as it happens where they have the access they need. Semantic and entropy monitoring adds output-side evidence, while behavioral baselines watch execution and egress. Detection still needs a response architecture. A probe can flag a deviation without itself deciding how to interrupt it, so adding detectors alone does not complete the defense.

Why pre-deployment testing cannot substitute for runtime monitoring in plugin pipelines

Could sufficiently thorough red-teaming replace these runtime checks? GitInject gives a concrete reason to doubt that. The study found that simulation missed a large majority of confirmed real attacks in the CI/CD setting and incorrectly predicted 5.0% of infrastructure-blocked attacks as successful. Testing therefore produced errors in both directions. A simulated model interaction did not reliably capture what the deployed pipeline allowed or blocked.

Configuration-file injection explains part of that gap. Its success depends on how actual CI/CD infrastructure handles a merge commit and which instructions the provider CLI loads before review. A sandboxed simulation that omits those interactions misses the operative trust boundary. The chatbot-plugin study likewise uncovered previously unknown risks across real deployments that prior analysis had not surfaced. Pre-deployment testing remains useful, but its evidence is bounded by the environment it reproduces.

The environment also changes after deployment. New tools, server configurations, and third-party content can add injection surfaces that were absent when an earlier assessment took place. For vendor AI assets, security consequently depends on whether each plugin or MCP server preserves conversation integrity, scopes permissions, and validates tool outputs over time. Traditional security frameworks do not cover these AI-specific instruction boundaries by themselves. Continuous vendor assessment and runtime monitoring track changes in a dependency beyond what a procurement check covers.

How do teams protect an enterprise RAG pipeline from malicious third-party content?

An operational posture covers four connected surfaces, including plugin trust configuration, in-pipeline signals, action baselines, and vendor ecosystem posture. The lesson for deploying teams is to assess whether every plugin or MCP server separates trusted from untrusted content, preserves conversation history integrity, and limits tool permissions to least privilege. Those are concrete trust-boundary questions. Weaknesses at these trust boundaries can let retrieved material gain authority before any detector evaluates its effect.

Signal coverage then needs to match the access available. Activation or attention probes, semantic drift monitors, and entropy detection belong inline where they can identify changes before or immediately as actions are issued. Tool calls, API invocations, credential access, and egress need behavioral baselines and alerts for injection-driven deviations. Research methods establish useful capability criteria. A detector’s position, access requirements, evasion exposure, and connection to a response are as important as its reported score.

Responsibility extends across TPRM, InfoSec, and Legal teams. Procurement assesses trust boundaries, deployment establishes runtime coverage, and ongoing operation tracks changes in vendor AI assets that could open new attack paths. Dedicated AI risk intelligence platforms that combine vendor assessment with real-time AI threat detection cover that wider scope, while compliance checklists and perimeter tools alone leave gaps inside the pipeline. The operational objective is specific. Information an agent is allowed to retrieve must not quietly give it permission to install software, access credentials, or move data outside its permitted scope.