The ideas we build on, and who named them
Naming a category is how it gets owned, and the honest move is to build on the names that already exist rather than reinvent them. Here is the vocabulary the Trust Layer works with, credited to the people who coined it, and exactly where Queldrex fits. We coin a term only where there genuinely is not one, and even then we define it and pair it with the parent idea.
Prompt injection
We align with thisSimon Willison, crediting Riley Goodside, 2022Attacker-supplied text mixes with trusted instructions in the same model context and overrides the developer's intent. Named by analogy to SQL injection. It is the root of nearly every agent attack.
The parent category. We detect a specific vector of it; we never claim to have named or solved it.
Indirect prompt injection
We align with thisGreshake, Abdelnabi, Mishra, Endres, Holz, Fritz, 2023The malicious instructions are not typed by the user but embedded in third-party content the model later reads: a web page, a document, a tool output. Instruction-versus-data confusion at a distance.
Our MCP scanning detects one design-time channel of this. The runtime-output channel we contain, not prevent (see below).
Tool poisoning attack (TPA)
We adopt thisInvariant Labs, 2025Malicious instructions hidden inside an MCP tool's description, invisible to the user but read by the model, executing with the agent's privileges when the tool is invoked.
This is exactly what the Trust Layer scanner detects at registration. We use Invariant's term and credit them; we do not invent a competing name for it.
MCP rug pull
We align with thisInvariant Labs; CVE-2025-54136 "MCPoison", Check Point, 2025A tool passes review, then the server silently swaps its description or behavior afterward. Hosts that bind trust to the tool name re-run the mutated tool without re-asking. It gave persistent code execution in Cursor.
We pin the content hash of an approved tool and re-check on every call, so a post-approval swap is caught when it happens, not at the next scan.
Tool shadowing
We align with thisInvariant Labs, 2025A malicious server plants instructions that persist in the model's context and hijack how the agent uses a different, trusted server's tools. The malicious tool is never itself called.
We enumerate this as its own detector category rather than folding it into generic poisoning.
Lethal trifecta
We adopt thisSimon Willison, 2025Any agent that has all three of private-data access, exposure to untrusted content, and the ability to send data out is structurally exploitable for data theft. Each capability alone is ordinary.
Our rule QX-L-0006 is aligned with it: a session holding all three requires human approval before the egress step. We credit Willison for the framing.
Confused deputy
We adopt thisNorm Hardy, 1988A privileged intermediary is tricked into misusing its authority on behalf of a party that should not have it. In MCP it appears as proxy servers with static client IDs and token passthrough.
A classic term we use as-is. Our position on OAuth and token passthrough is stated on the threat-model page.
Shapeshifting
We coined thisQueldrex, 2026One logical MCP server presenting different self-descriptions across requests the 2026-07-28 spec requires to be treated as unrelated. Each exchange is individually compliant; the divergence exists only across requests.
The one term we coin, for a specific and reproducible thing (node scripts/poc-continuity.mjs). It is not an established term, so we always define it and pair it with the parent ideas (rug pull, continuity). Prior art for the defense is credited on the research page.
Coverage, honestly
Every named attack, credited, with a plain answer on whether the Trust Layer as built today addresses it. Conceding the no and partly rows is what makes the yes rows worth believing.
Pre-call scan of the tool description and parameter schema, before the agent ever reads it.
We pin the content hash at approval and re-check on every call, so a post-approval swap is caught when it happens.
We gate the egress leg: a session with private data, untrusted content, and outbound capability needs human approval. We do not remove the underlying injection risk.
Name-collision and cross-server rules are a detector category; context-poisoning delivered through a tool output at runtime is not seen by a pre-call scan.
We flag token pass-through in tool metadata; we do not fix a host’s OAuth proxy configuration.
We catch the design-time channel (poisoned descriptions). The runtime channel, injection arriving inside a legitimate tool’s output, we contain, not prevent.
With output scanning enabled, we run every tool output through the same injection detector and flag override attempts, data-exfiltration links, memory backdoors, forged approvals, and hidden-character smuggling, telling the agent to treat the output as untrusted data. It is pattern-based and after the fact: it cannot un-influence a model that already read the output, and a novel injection can evade it. We contain, we do not prevent.
We now scan artifact bytes and configs for known dangerous pickle opcodes and load-time code flags (trust_remote_code, custom-code references) before loading. It is a pattern scanner: bypassable by design and it does not execute the artifact, so a clean result means no known-dangerous pattern found, never proof of safety. Available at the API today; a console surface is still to come.
The most dangerous actions there passed through no tool interface at all. An MCP-scoped tool is one more boundary an un-instrumented agent never touches. We would not have stopped it.
What we catch, and what we do not
- Poisoned tool descriptions and parameter schemas before the first call.
- Rug pulls: we pin the content hash and re-check on every call, the class of bug that gave persistent code execution in Cursor.
- Lethal-trifecta sessions, gated to a human before egress.
- A silent BCC or a post-approval swap, made auditable after the fact by a signed receipt.
We do not prevent prompt injection. When the malicious text arrives inside a legitimate tool's output at runtime, a scanner that saw a benign description and a benign server cannot stop it. The people who named these attacks say plainly that model alignment is not enough and there is no easy fix for the architectural problem. What a governance layer does there is contain the blast radius, scoping, egress denial, and a signed record, not prevent the injection. Our honest claim is: detect poisoned tool definitions, enforce policy and budget, and prove what happened. See the threat model.