Plugin and Connector Trust Boundaries That Stop Adversarial Instruction Propagation

To protect enterprise RAG pipelines from indirect prompt injection, teams need hard boundaries between trusted instructions, retrieved content, and tool execution. Detection must track content provenance, changes to connector definitions, and suspicious tool-call arguments, while execution controls prevent untrusted text from authorizing actions. Model safeguards help, but they cannot fix a plugin layer that gives external content the authority of a system instruction.

Why the plugin and connector layer is where adversarial instructions land

The consequential shift is a model prompt becoming an execution path. Earlier integrations usually wrote text for a human to act on, so adversarial content had fewer paths to an automated action. Agents can now inspect repositories, edit files, execute shell commands, and query internal systems with limited supervision. An injected instruction can therefore become a database write or an email. The dependency is no longer just executable code. It is also context the agent trusts, so behavior can change without a new binary appearing.

Anthropic released Model Context Protocol, or MCP, in November 2024, and it has become the primary connector surface. NSA's MCP security guidance describes an inversion in the familiar client-server relationship. Rather than only answering client requests, servers can query and sometimes execute actions for connected clients. That creates paths that are difficult to trace. The guidance identifies this inversion as a design risk and says adoption has outpaced the protocol's security model.

How instruction trust collapses when plugin boundaries are absent

Instruction trust collapse happens when external content gains the power to guide an agent's decisions. Without hard separation, retrieved text can guide which tool the agent chooses as well as what goes into an answer. This repeats an old mistake in how systems are built, confusing commands with data. SQL injection and cross-site scripting exploited related failures of separation. In the plugin layer, the confusion reaches both the model's instruction stream and the tools it can invoke.

Three boundaries make the failure precise. The User-Agent Boundary gives user instructions more authority than external content. The Agent-Tool Boundary keeps tool responses as untrusted data so they cannot become executable instructions. The Tool-Tool Boundary prevents one tool from influencing or hijacking another. Each protects a different transfer of authority.

The IEEE S&P 2026 study of third-party chatbot plugins found implementations that transmit conversation history without integrity checks, allowing forged messages to impersonate high-privilege roles. That breaks the User-Agent Boundary before the model responds. The study also found 15 plugins that scrape web content without distinguishing trusted first-party material from untrusted third-party material. Here, retrieval erases the Agent-Tool Boundary instead. MCP's lack of support for exchanging Role-Based Access Control permissions at instantiation compounds the problem by making access boundaries between tasks or services difficult to enforce or verify.

What trust collapse looks like in production: five documented cases

Socket's research team documented SANDWORM_MODE in February 2026, involving 19 malicious npm packages published under the aliases official334 and javaorg. Its Stage 2 payload included an internal module named McpInject. The rogue server advertised index_project, lint_check, and scan_dependencies, with embedded instructions to read SSH configuration and deployment credential files without disclosing the context-gathering step. Tool metadata became a source of behavioral commands. This crossed the Agent-Tool Boundary by asking the agent to treat attacker-supplied tool content as authority.

LayerX documented a Claude Desktop Extensions zero-click chain in 2026 with CVSS 10. A malicious calendar event and a benign user prompt such as “take care of it” were sufficient to chain the Calendar connector into Desktop Commander and reach arbitrary code execution. The initial connector did not need equivalent privileges. Instead, it crossed the Tool-Tool Boundary by influencing a more powerful connector.

CVE-2025-54136, known as Cursor MCPoison, involved replacing an already-approved MCP entry with an arbitrary command without another approval prompt. It scored CVSS 7.2, affected Cursor versions 1.2.4 and below, and was fixed in 1.3. The mismatch between the approval and what would execute violated the Agent-Tool Boundary and exposed the unsafe assumption that an approved tool remains unchanged.

The Shai-Hulud registry wave reached over 440 npm packages in August 2026. Separately, a payload reached registry.modelcontextprotocol.io through a V.A.P.E. MCP server entry whose linked npm/PyPI package was clean but whose linked GitHub repository contained malware. The compromised downstream link exposed the Agent-Tool Boundary's supply-chain dependency, since the integrity of everything a trusted distribution surface referenced required separate verification.

CVE-2026-30615 involved attacker-controlled HTML writing a malicious server into Windsurf's local MCP configuration, where it auto-registered. It scored CVSS 8.0, with no named fixed version published as of reporting. External content reached the system-configuration tier, crossing the User-Agent Boundary.

Why model-level defenses cannot close a gap that lives in the architecture

If instruction hierarchy gives system messages the highest authority, why is that not enough? The hierarchy is valuable when roles remain intact. But a plugin that accepts forged system-role messages has already mislabeled the attack before the model evaluates it. Faithfully following the hierarchy cannot repair false provenance.

Fine-tuning and RLHF alignment face the same limitation. They operate on content after the structural failure has occurred, and heuristic defenses provide no formal guarantee against adaptive attacks. Stronger instruction-following can even increase susceptibility in some tool-poisoning settings because compliance itself becomes the attack vector. MCPTox found that o1-mini failed at a substantially higher rate than the benchmark average, with DeepSeek-R1 and Phi-4 close behind. Capability is not a reliable proxy for resistance.

Manifest-based permissions address a different part of the problem. They constrain which tools are available, but not what the model will attempt with those tools after reading adversarial content. Availability is not authorization for every possible use. Architectural enforcement therefore complements model defenses by limiting what can happen even when the model follows a malicious instruction.

The three trust zones that architectural enforcement must create

The design response is to separate instructions, data, and execution into three zones with explicit gates. The trusted instruction zone contains developer-authored system prompts and pinned, integrity-verified configuration. Retrievals, user input, and tool responses can enter it only after human review and an explicit decision to promote them. The Hookify incident illustrates the alternative, as a marketplace plugin allowed project rule files to reach the system-message channel.

The untrusted data zone takes in retrieved documents, RAG results, tool outputs, and external feeds. These remain useful evidence. Their influence on model output must follow a tagged, auditable path. The plugin study found that 15 of 17 plugins ingested first-party and third-party content indiscriminately. Separating this zone corrects that specific failure rather than asking the model to infer provenance from prose.

The controlled execution zone gates tool calls and downstream actions independently of model output. Every argument set passes through guardrails before dispatch, and irreversible actions require human approval. A tool request is not permission to execute. Because MCP lacks RBAC exchange at instantiation, implementations must enforce this separation themselves. In the calendar chain, that means a low-risk connector cannot confer authority to use a higher-risk one.

Controls that enforce each boundary in the plugin and connector layer

At the instruction gate, teams should verify both integrity and provenance. Conversation history sent in network requests needs integrity checks so attackers cannot forge higher-privilege messages. The plugin study found that 8 of 17 plugins lacked them. Repository instruction files should remain untrusted until reviewed. Plugin manifests and MCP tool descriptions should also be pinned and signed so changes after approval become detectable.

That last control remains an implementation responsibility because the July 2026 update to the MCP specification did not cover tool-description signing. A server can therefore present benign definitions for approval and change them later in a rug pull. Initial consent cannot validate a later definition. Configuration-tier changes need the same scrutiny as the initial installation.

At the data gate, all web-scraped content, RAG results, and external feeds should get trust labels before they enter the context window. Metadata should show whether sources are first-party or third-party, and those labels must stay with any content made from them. An instruction extracted from an untrusted document remains untrusted. This gives indirect prompt injection detection a provenance trail rather than leaving it to judge suspicious wording alone. It also prevents a processing step from silently promoting retrieved material into authority.

At the execution gate, tool calls must be typed and checked independently of the LLM. Permissions should cover only what each task requires, rather than bundle read, write, email, and finance access into a general-purpose agent. A human must approve database writes, emails, financial operations, and file deletions before they go ahead. Guardrails must check every set of tool-call arguments. Checking only the final answer misses the point where an instruction becomes an action.

Discovery supports all three gates because approving an application does not inventory everything installed inside it. A plugin may bundle Skills, hooks, subagents, and MCP server configurations from additional suppliers. Security teams should map which data, tokens, and APIs each component can reach and which actions it can take. The approved-plugin list is only a starting point. Logging behavior, alerting on anomalies, and retesting after updates or configuration changes keep that map useful.

How CaMeL's dual-LLM architecture translates the zone model into a formal enforcement mechanism

Google DeepMind's CaMeL, or CApabilities for MachinE Learning, makes this separation concrete. The research system, presented at IEEE SaTML 2026, uses a Privileged LLM to build a Python execution plan from the trusted user query without processing untrusted data. A Quarantined LLM handles that data without tool access, while a custom interpreter tracks provenance and enforces flow-tag policies before tool calls. Untrusted data cannot alter program flow. The privileged model, quarantined model, and interpreter correspond to the instruction zone, data zone, and execution gate. DeepMind reports that CaMeL solves 77% of AgentDojo tasks with security guarantees, compared with a higher but unguaranteed completion rate for an undefended system. This validates the design logic while leaving enterprise readiness, tool-definition rug pulls, and supply-chain vetting unresolved.

What continuous vendor monitoring must cover that static assessment misses

Third-party connectors can change after procurement, so point-in-time assessment cannot preserve the boundaries established at integration. A rug pull makes the mismatch explicit. The approved definition describes yesterday's tool, while the agent invokes today's version. NVD tracked no MCP vulnerability CVEs in the first four months of 2025, compared with 23 in the same period of 2026. An approved inventory therefore needs ongoing vulnerability tracking as well as change detection.

Monitoring must track tool-description changes and new CVEs, and check runtime behavior against what tools claim they can do. It must also track the provenance of content entering through vendor connectors and anomalous tool-call arguments that may indicate active injection. These signals answer different security questions. Definition monitoring detects drift in what was approved, while behavioral attestation tests whether actual activity matches declared capabilities. Both still need the execution gate to block an action that has not been authorized.

Production tooling for behavioral attestation is an active, maturing area, with multiple tools in general availability as of 2026. Monitoring tool-description changes and CVE feeds against the approved inventory is an available control. Platforms combining vendor risk assessment with real-time AI threat detection address this organizational gap. TPRM, InfoSec, Privacy, and Legal teams need a shared, ongoing view of vendor-supplied AI assets. NSA's May 20, 2026 Cybersecurity Information Sheet reinforces that production focus by identifying tool poisoning, rug pulls, and cross-server trust exploitation as priority concerns.

Where the standards landscape currently leaves gaps that architecture must fill

NIST launched its AI Agent Standards Initiative in February 2026, but no binding standard covering plugin trust boundaries or MCP security has been published. The NSA/DoD joint advisory of June 2, 2026 is guidance. It identifies priority threats without mandating the specific architecture described here. Implementation remains the enterprise's responsibility. Generic governance checklists assess whether a vendor has a security program, leaving unchecked whether its tool definitions changed after approval or its connector has only the permissions its task needs.

For organizations in finance, legal, and healthcare, that leaves AI-specific attack surfaces outside the checks they have traditionally used. Compliance alone does not establish safe separation between retrieved content and executable actions. Future standards may provide signed manifests, behavioral attestation requirements, and RBAC support in MCP. Enterprises deploying these systems today need architectural gates and continuous monitoring at the points where external text can acquire authority.