Classic command injection turns attacker-controlled text into an operating-system instruction. Prompt injection turns attacker-controlled text into a model instruction—and, when that model has tools, the effect can reach files, browsers, credentials, terminals, and production systems.

The analogy is not perfect. A language model is not a shell parser, and a prompt is not a deterministic command language. But the defensive lesson is the same: untrusted data must not become privileged action merely because an interpreter found it persuasive.

Threat model by James Tsetsekas, informed by the Microsoft and Google security research linked below.

Indirect injection is the dangerous default

Direct prompt injection happens when a user deliberately tells a model to ignore its instructions. That is the obvious case.

Indirect prompt injection arrives inside content the agent is expected to read: a webpage, email, document, issue description, dependency README, calendar invitation, image, or retrieved database record. The user may never see the malicious instruction. To the model, however, both the task and the retrieved content are tokens in context.

Google’s security team describes indirect prompt injection as a primary expected attack vector for browser-connected agents and reports finding real attempts on the public web, including instructions aimed at exfiltration or destructive behavior. Many suspected examples are harmless or ambiguous, which creates a second problem: defenders must control execution without assuming they can perfectly classify every sentence.

When a prompt becomes a shell

Microsoft disclosed two Semantic Kernel vulnerabilities in May 2026 that demonstrated the escalation path. In one proof of concept, a prompt could lead to calc.exe launching through a vulnerable framework and tool path.

The important conclusion was not that the model itself had become an operating-system exploit. The system had mapped model-controlled data into a privileged tool unsafely.

The chain looks like this:

1. The agent reads untrusted content.
2. The model interprets part of it as an instruction.
3. The model proposes a tool call containing attacker-influenced arguments.
4. The framework accepts those arguments with too much authority.
5. A downstream interpreter—shell, SQL engine, browser, or API—performs the action.

A system prompt that says “never do anything dangerous” is not a security boundary in that chain. It is another natural-language input to the same probabilistic decision process.

The command-injection analogy—and its limit

For ordinary command injection, developers learn not to concatenate user strings into shell commands. They use parameterized APIs, allowlists, escaping appropriate to the final interpreter, and an account with limited privileges.

Agent systems need equivalent controls:

• tool calls with typed, narrow arguments instead of arbitrary command strings;
• explicit policy checks outside the model;
• per-tool and per-resource authorization;
• a sandbox that limits filesystem, process, and network reach;
• approval for consequential actions;
• secrets unavailable unless the specific tool and task require them;
• logs that record proposed and executed actions without storing sensitive content.

The limit of the analogy is that prompt injection can change intent before any obviously dangerous string appears. An injected page may convince an agent that sending a file is necessary for the user’s task. The API call can be perfectly well-formed and still violate the user’s goal.

That means argument validation is necessary but not sufficient. The control plane must also constrain which action is allowed, on which resource, for whose stated purpose.

Design the agent as a hostile intermediary

The safest mental model is not “the AI is malicious.” It is “the AI may be faithfully processing adversarial context.” Treat its output like any other untrusted proposal.

Separate reading from acting

An agent that summarizes the web does not need permission to send email. A code-review agent usually does not need deployment credentials. Grant capabilities per task instead of attaching every available tool to one universal assistant.

Make tools narrow

Prefer create_issue(title, body, repository) over run_shell(command). Prefer read_file(project_path) over unrestricted disk access. Validate paths after resolution, cap payloads, and reject unexpected protocols and destinations.

Put policy outside the prompt

Rules such as “never transfer funds,” “never publish a message without approval,” and “only modify this repository” should be enforced by the host application. A model should not be able to reinterpret away the mechanism that limits it.

Require meaningful approval

An approval dialog should explain the action and scope: “Publish this event to these relays,” “send this message to this address,” or “execute this command in this directory.” A generic “Allow?” button trains users to click through the most important boundary.

Assume content is adversarial

Repository files, package scripts, issue comments, and documentation can all carry instructions. Agent developers should distinguish trusted user intent from text collected while completing that intent. Retrieved content can provide facts; it should not silently expand authority.

Why Bitcoin raises the stakes

Bitcoin software often sits near irreversible actions and high-value capabilities:

• hardware signers and remote signers;
• Lightning invoices, macaroon credentials, and NWC connections;
• exchange or treasury APIs;
• node terminals and backup locations;
• encrypted messages containing order or delivery information.

An agent that can inspect a node and help diagnose it may be useful. If the same agent can read arbitrary web content, access the node’s credentials, and broadcast transactions without a separate confirmation path, the architecture has joined unrelated trust domains.

The right pattern is a sequence of narrow capabilities: diagnose with read-only data, propose a remediation, show the exact effect, require approval, execute with the minimum authority, then verify the result.

Model quality will not remove the boundary

Better models can reject more attacks. Filters can detect known injection language. Training can make agents more skeptical. All of that reduces risk.

None of it changes the architectural requirement. A model sophisticated enough to use unfamiliar content is also sophisticated enough to be influenced by that content in ways we did not enumerate. The system around the model must limit the consequences of a wrong interpretation.

Prompt injection is the new command injection not because prompts and shell strings are identical, but because the industry is repeating the same category error: giving text more authority than it deserves.

Sources and further reading

• Microsoft Security: Prompts Become Shells
• Google Security Blog: Mitigating Prompt Injection Attacks in the Browser
• DeepSeek Harness Safety Guidance

Last verified: September 9, 2026.