DEV Community: Actionable Vectors

Whose response is this? The MCP server SDK that matched replies by id alone

Actionable Vectors — Wed, 21 Oct 2026 11:11:06 +0000

Whose response is this? The MCP server SDK that matched replies by id alone

A vector breakdown of CVE-2026-111770 / GHSA-jm63-cq47-j5jp (@modelcontextprotocol/server 2.0.0 through 2.2.0, fixed in 2.3.0)

No injection, no stolen token. Two people use the same MCP server over HTTP at the same time, and one of them gets the other's answer. That's the whole bug, and it came straight from the pattern the official framework examples showed.

What the advisory actually says

From GHSA-jm63-cq47-j5jp, published by the MCP TypeScript SDK maintainers and added to the GitHub Advisory Database on October 20, 2026:

Package: @modelcontextprotocol/server (npm). Affected: 2.0.0 through 2.2.0. Fixed: 2.3.0.
Not affected: stdio servers, createMcpHandler() with a factory that builds a new server on every call, and @modelcontextprotocol/sdk 1.26.0 and later.
Weakness: CWE-362, a race on a shared resource. Severity: High, CVSS 3.1 7.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:H).
The bug: "an MCP server reached over HTTP could deliver one client's responses and notifications to another client. This happened when clients shared one stateless transport, or one McpServer or Server instance."
Why ids collide: "Messages were matched to a connection by JSON-RPC id alone. SDK clients number requests from 0, so ids collide in normal use."
Credit: DavidCarliez and legitu1337.

It's one of five MCP TypeScript SDK advisories published the same afternoon. The others cover session-unbound tasks, a validation memory blowup, a missing token audience check, and headers resent across redirects.

The vector: two clients, one connection table

A developer builds an HTTP MCP server the way the README examples for the hono, express, fastify and node adapters showed: create the server and transport once at startup, then reuse them for every request.
Client A sends a request with JSON-RPC id 0. Client B, an unrelated user, also sends id 0, because every SDK client starts counting at 0.
The shared instance has one slot for "the response to id 0." Whichever response is ready gets routed to whichever connection currently holds that id.
Client B receives client A's tool result, or A's notifications, which may hold whatever data A's tool returned.

The attack complexity is rated high because it depends on timing and overlap. But this isn't something an attacker has to engineer. It happens on its own whenever traffic overlaps, so ordinary users can see each other's data without anyone trying.

Why this class of bug exists: three root causes

1. A protocol-level id used as a security identity

Mechanism. JSON-RPC ids exist so one client can match its own replies. They're only unique within one connection. A server that uses them across connections is using a counter as if it were an identity.

Evidence. The advisory: messages were "matched to a connection by JSON-RPC id alone," and because clients "number requests from 0, … ids collide in normal use."

What fixes it. Route by connection or session first, then by id. Any lookup keyed on something the client chooses needs a server-assigned scope around it.

2. "Stateless" read as "safe to share"

Mechanism. A stateless HTTP transport sounds like it holds nothing, so creating one at startup and sharing it looks like a harmless optimization. But it still tracks in-flight requests, and that tracking is state.

Evidence. Affected setups are ones where "your code creates the transport or the server once at startup, instead of once per request or per session." The fix makes the SDK refuse sharing outright: "a second connect() rejects with ALREADY_CONNECTED, and a stateless transport rejects its second request."

What fixes it. Treat per-request objects as per-request. If an object tracks anything in flight, it belongs to one request or one session. Making misuse fail loudly, as 2.3.0 does, is the right default.

3. The insecure pattern was the documented one

Mechanism. Most people build servers by copying the quickstart. If the quickstart shares one instance, most servers will too, and the bug spreads by copy-paste.

Evidence. The advisory: "Until this release, the README examples of @modelcontextprotocol/hono, express, fastify and node showed that pattern."

What fixes it. Example code is security-relevant code. Review quickstarts with the same care as the library, and design APIs so the copy-pasted shape is the safe one, for example a factory that builds a fresh server per call.

How this connects to the rest of the batch

Several of this week's MCP SDK advisories share a theme: something that should have been scoped to one client wasn't. Tasks weren't bound to sessions, tokens weren't bound to an audience, and here responses weren't bound to a connection. In a multi-user agent server, everything keyed by a client-chosen value needs a server-owned scope around it.

Defensive takeaways you can check this week

Check your version and your wiring. If you use @modelcontextprotocol/server 2.0.0 through 2.2.0 over HTTP, look for a server or transport created once at startup and reused across requests.
Upgrade and change the code. Move to 2.3.0 or later, then switch to one of the patterns the advisory lists: createMcpHandler() with a factory, a new server and transport per request, or one of each per session with sessionIdGenerator set. Upgrading alone will break a shared setup, on purpose.
Can't upgrade yet? The advisory says the same code change fixes affected versions.
Pick up the rest of the batch. Moving to @modelcontextprotocol/server / client 2.3.0 or @modelcontextprotocol/sdk 1.32.0 also covers the sibling advisories. Note that the validation-memory fix needs its new limit option configured; upgrading alone doesn't enable it.
Assess exposure. If several users shared an affected HTTP server, consider whether tool results could have held sensitive data, and handle it the way you'd handle any cross-tenant leak.
Test it. Run two clients concurrently against your server with overlapping request ids and assert each receives only its own responses.

Sources

If you're building agent backends and want a checklist for this kind of trust boundary, the Trust Boundary pack covers it.

This article was drafted with AI assistance and edited by a human. All facts come from the advisories linked above.

Summarize this document, then run it: Vibe-Trading's prompt-injection-to-root shell

Actionable Vectors — Wed, 21 Oct 2026 11:10:59 +0000

Summarize this document, then run it: Vibe-Trading's prompt-injection-to-root shell

A vector breakdown of CVE-2026-114107 (HKUDS Vibe-Trading 0.1.0 before 0.1.7, fixed in 0.1.7)

Most agent shell bugs need an attacker who can talk to the agent. This one only needs an attacker who can get a document or a web page in front of it. Vibe-Trading hands its model a shell tool that runs whatever command the model emits, as root, with no allow-list and no approval step. So the person who wrote the PDF the agent is summarizing has the same reach as the operator.

What the advisory actually says

From the CVE record (published to NVD October 21, 2026, 01:17 UTC, by VulnCheck), the VulnCheck advisory, and the project's GitHub advisory GHSA-jqmf-mx4f-hfr6:

Product: HKUDS Vibe-Trading, an AI trading-research agent. Affected: 0.1.0 up to, but not including, 0.1.7. Fixed: 0.1.7.
Weakness: CWE-1427, Improper Neutralization of Input Used for LLM Prompting. The GitHub advisory also lists CWE-77, CWE-78, CWE-94, CWE-116 and CWE-918.
Severity: VulnCheck scores it High, CVSS 4.0 8.7 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H). Network-reachable, no privileges, and "passive" user interaction: someone just has to ask the agent to read the attacker's content.
The bug, in the CVE's words: "remote attackers [can] execute shell commands as root by planting instructions in documents or web pages the agent processes. BashTool and BackgroundRunTool pass model-emitted commands to subprocess.run with shell=True and no allow-list or approval step, and read_url fetches arbitrary URLs, enabling command execution and server-side request forgery."
Related: CVE-2026-114106 covers the same release's file-read tools, which could be steered by path traversal into files like /etc/shadow and /proc/self/environ.

The GitHub advisory groups five findings under one root cause: "LLM-callable tool primitive ships with zero input validation between the LLM and the sink."

The vector: attacker text in, root shell out

The attacker writes instructions into content the agent will read later: an uploaded document, a web page, a trade journal.
A legitimate user asks the agent to summarize or research that content. The user's own prompt is clean.
The model reads the planted instructions and can't reliably separate "text I'm analyzing" from "instructions I should follow," so it emits a call to the shell tool.
BashTool (or its async sibling BackgroundRunTool) passes that command straight to subprocess.run(..., shell=True). No parser, no allow-list, no confirmation.
The container has no USER directive, so the command runs as root, with whatever keys and network the agent process holds.

The advisory notes a second path to the same tools: in affected versions the session API itself had no working authentication (a separate advisory), so anyone who could reach the port could drive them directly. But it's explicit that fixing authentication alone "leaves prompt-injection RCE on the table."

Why this class of bug exists: four root causes

1. A general-purpose shell is registered by default

Mechanism. Agent frameworks discover tools automatically and hand the model the whole registry. If one of those tools is "run any shell command," every task the agent does, even a summary, carries the ability to run code.

Evidence. The advisory says all five tools "are members of the auto-discovered tool registry the LLM agent gets at startup," and "the tool registration is unconditional in default config — no operator opt-in flag gates them." It also points out that there are two shell entry points, so "fixing only BashTool leaves this path intact."

What fixes it. Make dangerous tools opt-in, not discovered. A summarizing turn has no business holding a shell at all. If a workflow truly needs one, the operator should switch it on explicitly, for that workflow.

2. The model's judgment is the only gate

Mechanism. When the code between the model and subprocess does nothing, the model's own discretion is the security boundary. Prompt injection exists precisely to beat that discretion.

Evidence. The advisory's wording: "the LLM's own judgement is the only barrier, and that barrier collapses under prompt injection." The command argument is read "directly … (LLM-emitted) with no allowlist, no escaping, no chroot, no seccomp, and no length cap."

What fixes it. Put a deterministic check between the model and the sink: an allow-list of command prefixes, argument parsing with shell=False, and human approval for anything outside the list. The check has to be code, because text the attacker controls can't change code.

3. Untrusted content and privileged tools share one turn

Mechanism. The same model turn that ingests outside content can call tools with real authority. That gives the author of the content the operator's authority.

Evidence. The advisory describes "an authenticated, non-malicious caller using a clean prompt" being "turned into an RCE vector by feeding the agent attacker-controlled content (a malicious PDF, web page, or trade journal)." The same applies to read_url, which forwarded any model-supplied URL with "no schema check, no hostname allowlist, no RFC1918 filter," so planted text could also point the agent at internal services.

What fixes it. Split reading from acting. Turns that process outside content get read-only tools; acting turns don't see raw outside content, or their tool calls need approval the content can't grant. Validate outbound URLs (scheme, host, private address ranges) in code.

4. The blast radius is root in the container

Mechanism. Even a well-gated agent will eventually run something it shouldn't. What it can reach then decides whether that's a nuisance or a breach.

Evidence. "The container has no USER directive, so successful execution runs as uid=0(root)." The related CVE-2026-114106 shows the same release could read /proc/self/environ, which is where API keys in environment variables live.

What fixes it. Run as a non-root user, keep secrets out of the agent's environment, and limit outbound network access to what the workflow needs.

How this connects to other agent tool bugs

Recent approval-gate bugs had a gate that checked too little, or a gate that went silent on headless surfaces. This one never had a gate. Same lesson, simplest form: if the only thing between untrusted text and a shell is the model's opinion, the attacker is the one with the shell.

Defensive takeaways you can check this week

Upgrade. If you run Vibe-Trading 0.1.0 through 0.1.6, move to 0.1.7, per the GitHub advisory.
Rotate if exposed. If an affected version read outside documents or URLs, or its port was reachable by others, rotate the LLM and data-provider keys in its environment and review its shell history and outbound traffic.
Inventory your own agents' shell tools. Search for shell=True and equivalents reachable from a model tool call. For each, ask whether it's registered by default and what code, not prompt, stands in front of it.
Gate outbound fetches. Any "read this URL" tool should reject non-HTTP schemes and private, loopback and link-local addresses before it fetches.
Drop root. Add a non-root USER to agent containers and keep long-lived secrets out of their environment.
Test the injection path. Add a test that feeds the agent a document containing an instruction to call its shell tool and asserts the call is refused, not just that the model "usually ignores it."

Sources

If you're building agent backends and want a checklist for this kind of trust boundary, the Trust Boundary pack covers it.

This article was drafted with AI assistance and edited by a human. All facts come from the advisories and CVE record linked above.

No prompt injection required: Langchain-Chatchat's /tools/call is a remote shell

Actionable Vectors — Wed, 21 Oct 2026 11:10:17 +0000

No prompt injection required: Langchain-Chatchat's `/tools/call` is a remote shell

A vector breakdown of CVE-2026-75128 / GHSA-5rx2-xp53-9x5r (Langchain-Chatchat through 0.3.1.3)

Most agent bugs I write about need the model to be talked into something. This one skips the model entirely. Langchain-Chatchat has an HTTP endpoint that runs any registered tool by name, with no authentication, and one of the tools that's always registered is a shell.

What the advisory actually says

From GHSA-5rx2-xp53-9x5r and the VulnCheck advisory, published October 20, 2026 at 03:32 UTC:

Product: Langchain-Chatchat, an open-source RAG and agent app built on LangChain. Affected: through 0.3.1.3. No fixed release is listed.
Weakness: CWE-306, Missing Authentication for Critical Function. Severity: Critical, CVSS 3.1 score 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
The bug: the project "exposes a POST /tools/call API endpoint that invokes any registered tool by name without authentication, leaving the always-registered shell tool callable."
Impact: "Remote attackers can send a single request naming the shell tool to execute arbitrary OS commands as the server user (root in the shipped Docker image)."
Credit: VulnCheck credits Noy Pearl, Michael Sromin and Ophir Dror.

The vector: the agent's toolbox, published as an API

The advisory points at tool_routes.py. Reading it at the referenced commit, the shape is simple:

A /tools router has two routes. GET /tools lists every registered tool with its name, description and argument schema. POST /tools/call takes a tool name and an input dictionary and runs that tool.
Neither route has an authentication dependency.
Tools register themselves when their module is imported. The tools package imports a shell tool that wraps LangChain's ShellTool, described as "Use Shell to execute system shell commands."
So anyone who can reach the API server can list the tools, see shell, and call it directly.

No model is involved, so there's no system prompt to get around and no injection to craft. The tool layer that was meant to sit behind the agent is reachable straight from the network.

Why this class of bug exists: three root causes

1. Agent tools exposed without the agent's controls

Mechanism. In an agent app, tools are meant to be called by the model inside a turn, with whatever checks the app places around that turn. A direct "call any tool" endpoint is handy for debugging and for front ends. But it removes every control the agent path had and makes the HTTP layer the only policy. Here the HTTP layer has none.

Evidence. The advisory: the endpoint "invokes any registered tool by name without authentication." In the source, call_tool looks up the tool by the caller-supplied name and calls ainvoke on the caller-supplied input. Nothing checks who's asking or which tool they named.

What fixes it. Don't expose a generic tool-invocation route in production. If a front end needs one, put authentication on it and keep an explicit allow-list of tools callable that way, with dangerous tools never on it.

2. A dangerous tool on by default

Mechanism. Registering every tool when the package is imported is convenient, because nobody has to wire them up. It also means the riskiest tool in the box ships turned on for everyone, including people who never asked for it.

Evidence. The advisory calls the shell tool "always-registered." In the source, the tools package imports shell next to calculate, weather_check and the rest, and the @regist_tool decorator registers it on import.

What fixes it. Tools that execute code, run shell commands or touch the filesystem should be opt-in. Require an explicit config flag to enable them, and log loudly at startup when they are on.

3. Deployment defaults that turn a local bug into a remote one

Mechanism. A missing auth check on a service bound to localhost is a local problem. The same check on a service listening on every interface, running as root, is remote code execution with full control of the container.

Evidence. Outside Docker, the project's settings bind the API server to 127.0.0.1 by default, on port 7861. The shipped Dockerfile changes that with chatchat-config server --default_bind_host=0.0.0.0 and never sets a non-root USER, which matches the advisory's "root in the shipped Docker image." The example docker-compose.yaml runs the container with network_mode: "host", so that listener sits directly on the host's network.

What fixes it. Images should run as an unprivileged user, and anything that listens on all interfaces should require authentication. If a container has to bind 0.0.0.0 to be reachable, publish the port only to localhost or a private network and put an authenticating proxy in front.

How this connects to the approval-gate bugs

A lot of this week's agent advisories are about approval gates that get skipped: by sub-agents, by headless modes, by injected instructions. This one shows what happens when the gate isn't skipped but missing, because the tool can be called without going through the agent at all. Before asking "can the model be tricked into calling the shell?", ask the simpler question: can anyone call the shell without the model?

Defensive takeaways you can check this week

Find out if you run it. Langchain-Chatchat through 0.3.1.3 is affected and no fixed release is listed, so watch the advisory for one.
Check exposure first. Find out whether port 7861 (the API server) is reachable from anywhere beyond the machine itself. If you used the shipped Docker image or compose file, assume it listens on all interfaces.
Block /tools at the edge. Put the API server behind a reverse proxy that requires authentication, and deny /tools and /tools/call outright unless you actually use them.
Turn off the shell tool. If your deployment doesn't need shell commands, remove or disable that tool rather than relying on network controls alone.
Don't run as root. Rebuild the image with a non-root user and a read-only filesystem where you can, so one bad request doesn't own the container.
Look at your logs. Search the API server or proxy logs for POST /tools/call from addresses you don't recognize, and if you find any, treat the host and any keys on it as compromised.
Audit your own agent apps. Search for routes that take a tool name from the request and invoke it. Every one needs authentication and an allow-list, whatever framework you use.

Sources

If you're building agent backends and want a checklist for this kind of trust boundary, the Trust Boundary pack covers it.

This article was drafted with AI assistance and edited by a human. All facts come from the advisory, its CVE record and the source files it references.

The approval gate that always said yes: OpenSRE's headless shell bypass

Actionable Vectors — Wed, 21 Oct 2026 11:10:08 +0000

The approval gate that always said yes: OpenSRE's headless shell bypass

A vector breakdown of CVE-2026-109444 / GHSA-fqh3-76w5-5vvf (OpenSRE through 0.1.2026.10.19)

I write a lot about approval gates that check the wrong thing. This one doesn't check anything. In OpenSRE's headless mode the function that decides whether the agent may run a shell command ignores its inputs and returns True. Put that next to an agent whose job is reading alerts and Slack messages, and anyone who can get text in front of it can run commands on the host.

What the advisory actually says

From GHSA-fqh3-76w5-5vvf and the VulnCheck advisory, published October 20, 2026 at 03:32 UTC:

Product: OpenSRE (Tracer-Cloud), an AI site-reliability agent. Affected: through 0.1.2026.10.19. No fixed release is listed.
Weakness: CWE-862, Missing Authorization. Severity: High, CVSS 3.1 score 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). It's network-reachable, needs no privileges, and needs one "user interaction": the agent has to triage the attacker's content.
The bug: "an approval gate bypass vulnerability that allows attackers to execute shell_run commands without confirmation because the headless presenter's execution_allowed() always returns True."
Impact: "Attackers can inject instructions into alerts or Slack messages triaged by the agent to run commands on the host and exfiltrate LLM, Slack and cloud credentials."
Credit: VulnCheck credits Noy Pearl, Michael Sromin and Ophir Dror.

The advisory links two lines in the source, and both are worth reading.

The vector: untrusted text in, shell commands out

An attacker gets text in front of the agent. The advisory names two routes: an alert the agent is asked to triage, or a Slack message.
The text contains instructions. The model can't reliably tell "data I'm analyzing" from "instructions I should follow," so it decides to call shell_run.
Before running a command, OpenSRE asks the active presenter whether execution is allowed. In the interactive terminal that's where a human confirms.
In headless surfaces (the Slack gateway, scheduled runs, embedded use) the presenter is HeadlessSubprocessPresenter. Its execution_allowed() takes the policy result and an action summary, discards both, and returns True.
The command runs on the host with whatever the process can reach, and the advisory says that includes LLM, Slack and cloud credentials.

No authentication step is skipped. The attacker never logs in. They just write something the agent will read.

Why this class of bug exists: three root causes

The advisory covers what's wrong, not the fix. Here's the class split into causes you can look for in any agent framework.

1. Approval treated as a UI feature instead of a security control

Mechanism. The decision to run a risky action is handed to the presentation layer, the part that draws prompts and buttons. That works when there's a terminal and a human. When the same agent runs headless, the presentation layer has nobody to ask, so someone writes a stub. A stub for a print method is harmless. A stub for the permission check is the vulnerability.

Evidence. The module's own docstring describes it as the presenter "for non-TTY agent surfaces (gateway, scheduled, embedded)." Its execution_allowed() ignores the ExecutionPolicyResult it's handed and returns True. The project's commit history shows the presenter was registered in an August 2026 change (#4845) so that "the default agent can execute" shell_run. That was a reasonable fix for "the agent can't run commands," made through a component that never enforced policy.

What fixes it. The allow/deny decision belongs in the execution path, not the presenter. The presenter can show a prompt, but the policy result itself should decide whether the command runs. If a surface can't ask a human, the policy has to answer, and the safe default answer for an unreviewed shell command is no.

2. "No human available" fails open

Mechanism. Approval prompts are annoying in chat. They stall, time out and clutter threads. The tempting fix is to drop them on that surface. Unless something else takes over the gate, that turns "needs approval" into "approved."

Evidence. The second line the advisory links is in the Slack dispatcher, where a comment says: "No approval prompts in Slack for now. Button waits stalled the turn until the timeout and posted extra replies in the thread." The turn is then set up with tool_hooks=None. That's an honest usability tradeoff. It also means that in Slack the shell tool runs on the model's say-so.

What fixes it. When an approval can't be collected, fail closed: refuse the action, or queue it for a human somewhere else and tell the user it's waiting. Faster is fine for read-only tools. Anything that writes, executes or touches credentials should be denied by default on surfaces with no approver.

3. The agent reads attacker text with operator authority

Mechanism. An SRE agent exists to read noisy, untrusted input such as alerts, logs and messages from anyone in a channel. If the same model turn that reads that input can also call a shell, the attacker's text has the same pull on the model as the operator's instructions. And if the shell runs in a process holding long-lived credentials, every successful injection becomes a credential leak.

Evidence. The advisory's attack path is exactly this: instructions "inject[ed] into alerts or Slack messages triaged by the agent," leading to command execution and exfiltration of "LLM, Slack and cloud credentials." The CVSS vector requires no privileges, only that the agent processes the content.

What fixes it. Treat everything the agent triages as untrusted data. Split reading from acting: a turn that ingests external content shouldn't hold the shell tool, or its tool calls should need approval that untrusted content can't grant. Run the executor without the agent's own API keys in its environment, and give it scoped, short-lived cloud credentials.

How this connects to the other approval-gate bugs

Usually the gate exists but checks too little, such as the verb without the object or the parent agent without its sub-agents. Here the gate exists in the interactive path and is a no-op in the headless one. It's the same lesson again: an approval control is only as strong as its weakest execution surface. If you can't name who approves a shell command in Slack, nobody does.

Defensive takeaways you can check this week

Find out if you run it. If you have OpenSRE at or below 0.1.2026.10.19, assume headless surfaces (Slack gateway, scheduled runs, embedded use) execute shell_run with no confirmation. No fixed release is listed yet, so watch the advisory for one.
Stop exposing the headless path to untrusted input. Until there's a fix, don't connect the Slack gateway to channels where people outside your on-call team can post, and don't point scheduled triage at alert sources that carry text an outsider controls.
Take the credentials away from the shell. Run the agent in a container or VM whose environment doesn't hold your LLM keys, your Slack bot token or broad cloud credentials. Use scoped, short-lived roles.
Rotate if you were exposed. If an affected version triaged outside content in headless mode, rotate the LLM, Slack and cloud credentials it could read, and review its command history and outbound network logs.
Audit your own agents for the same pattern. Search for approval or *_allowed methods that return a constant, and for surfaces that pass None for hooks or approvers. For each one, ask what happens when nobody is there to click.
Test the headless path. Add a test that puts a prompt-injection string in an alert or chat message and asserts the shell tool is refused, not just that a prompt was shown.

Sources

If you're building agent backends and want a checklist for this kind of trust boundary, the Trust Boundary pack covers it.

This article was drafted with AI assistance and edited by a human. All facts come from the advisory, its CVE record and the source lines it references.

Your AI agent's approval gate checks the verb, not the object

Actionable Vectors — Sun, 18 Oct 2026 00:10:32 +0000

Most human-in-the-loop setups for AI agents ask one question before a risky action: is this tool allowed? A person clicks "approve" on approve_payment, and the gate is satisfied. But that approval binds the verb, not the object. Nothing ties it to this payee, this amount, this invoice, so content the agent reads after the click can still decide what actually gets paid.

I built a small mock company to test this: helpdesk, finance, code-review and release agents behind a policy layer. The policy passed 10 out of 10 of its refusal tests. A vendor email couldn't trigger a payment, and a PR description couldn't merge itself. Then I wrote five tests that left the verbs alone and changed what they acted on. Three of the five failed.

This post covers the vector (indirect prompt injection through retrieved content), why a green scorecard missed it, and seven distinct reasons it exists.

The vector

An agent reads content written by someone other than the person who made the request (a wiki runbook, an invoice field, a PR description, an earlier ticket message), and that content steers what the agent does.

The top row is the control plane: the requester, the system prompt, the policy check, the approver. The bottom row is the data plane, labeled by who can write it. Both collapse into one context window, and the dashed boundary between them disappears.

What the 10/10 measured

Nine of the ten fixtures were direct injection: the attacker's text arrived in the same message as the request. Only one, a poisoned wiki note, was truly indirect. And every test asked the same question: does the gate block this privileged verb?

It did. The gate was wired correctly. But that tells you nothing about the arguments.

The three failures

Using the same policy:

Bank field swap. A human approved paying invoice INV-2201. The invoice's bank details were then edited, and the payment went through to the new account.
Amount change. Same approval, with the amount raised from $1,840 to $18,400. It went through.
"Safe" tool egress. A helpdesk ticket got the agent to include the staff contact list in its reply through send_reply, a tool the policy treats as always safe. The redaction filter missed all five records.

Caveat: these were scripted stand-ins that behaved as if the model had already obeyed the injected text. This tests the policy layer, not how a particular model resists injection. That's deliberate: you should assume the model will sometimes comply and ask what the system lets it do when it does.

Seven root causes

"The model obeyed a malicious document" is true but not useful. Underneath it are separate mechanisms, and each one needs a different fix.

RC1: No structural separation of instructions and data. SQL injection was largely solved by parameterized queries: code and data travel separately. LLM context has no equivalent. A runbook and the system prompt are the same kind of token.

RC2: Task framing amplifies obedience. "Follow the runbook" or "do what the ticket asks" turns instruction-following from a risk into the job description.

RC3: Provenance is stripped at ingestion. By the time a chunk reaches the context window, a contractor's wiki edit looks the same as the SRE lead's.

RC4: Confused deputy. The group of people who can write to the data plane is far larger than the group allowed to trigger the actions. The agent connects them.

RC5: Approvals bind the verb, not the object. This is the cause the 10/10 hid. The attacker doesn't need to unlock a privileged tool. They only need to sit upstream of one a human already approved and shape its arguments.

RC6: The human gate is mediated by the agent. The approver reads a summary written by the same agent that just read the poisoned content. And "trusted channel" is often just a string the caller sets.

RC7: "Safe" tools are egress. Policies guard privileged verbs and wave through send_reply, comment and summarize. Once private data and untrusted input share a session, those tools are an exit.

The fixes are boring, and they worked

A tightened policy passed all five tests, and the two legitimate-use controls still worked:

Bind approvals to the object. Sign the exact arguments (tool, payee, amount, invoice, expiry, nonce) and re-check them at execution time. If anything changed after sign-off, deny.
Taint tracking for egress. Once untrusted content is in context, outbound tools become internal-only, templated, or need approval.
Show approvers the raw request and arguments, not the agent's summary.
Label provenance on retrieved chunks, and limit which sources can be in context for privileged tasks.
Least privilege per task. Run with the requesting user's permissions, not a super-identity.
Test the object, not just the verb. For every privileged tool, add a regression test that changes the arguments after approval, and one positive control showing legitimate work still succeeds.

"Add a line to the system prompt telling the model to ignore instructions in documents" isn't on this list. It can help at the margins, but it doesn't fix any of the seven causes.

Try this on your own platform

Pull one approval record from your agent platform. Does it bind the exact arguments (payee, target, amount, expiry), or just the tool name? If it only names the tool, your human-in-the-loop is approving a category, not a transaction.

The full pack, and a disclosure

I packaged this review method as five agent prompts for security engineers: threat modeling, PR security review, CVE triage, incident notes, and an agent-feature reviewer built around RC1–RC7. Disclosure: it's my product, Trust Boundary: Agent Prompts for Security Engineers, $15 at https://actionable0.gumroad.com/l/mtsdk. Launch offer: code BOUNDARY5 makes it $10 for the first 25 buyers, until Oct 31: https://actionable0.gumroad.com/l/mtsdk/BOUNDARY5

This article and the diagrams were drafted with AI assistance and reviewed by a human before publishing. The lab is a clean-room mock; no real systems were tested.

— Actionable Vectors