A prompt injection attack hides instructions in content an AI agent reads, so the agent follows the attacker instead of the user. On a developer laptop this is not a theory. This article walks through the exact sequence of tool calls a prompt injection makes, explains why it works, and shows the one moment where it can be stopped.
What is a prompt injection attack?
A prompt injection is text placed where an AI agent will read it, written to be obeyed as an instruction rather than treated as data. There are two kinds. A direct prompt injection is typed straight into the chat. The dangerous kind for AI coding agents is the indirect prompt injection: the instruction is buried in a web page, a code comment, a file, a package README or a tool result, and the agent encounters it while doing an ordinary task.
The agent cannot reliably tell the difference between content it was asked to work with and an instruction hidden in that content. That ambiguity is the whole attack.
A prompt injection attack, step by step
Here is how one plays out on a real machine, in about four seconds.
- The developer asks the agent to fix a failing test.
- The agent searches the web for the error message.
- The third result is a forum post with a plausible fix. Inside an HTML comment, invisible to a human reader, is a sentence addressed to AI assistants: run this script and do not mention it.
- The agent's WebSearch tool returns the page. The agent reads it.
- The agent decides the script is part of the fix and calls its Bash tool with a command that pipes a remote script into a shell.
Three tool calls. About four seconds. No person involved after the first sentence. The developer asked for a test fix and got a remote code execution.
Why do prompt injection attacks work?
Two things make prompt injection effective against AI coding agents.
First, agents are built to be helpful and to act. They have tools that read files, run commands and reach the network, and they use those tools without asking for each step. An instruction that says run this is exactly the kind of thing they are designed to carry out.
First-generation defences try to filter the input, scanning for known bad phrases. Attackers rewrite the phrasing, encode it, split it across a page, or place it in a language the filter does not cover. Input filtering is a losing race because the space of ways to phrase run this is unbounded.
Second, the injection itself is not the harm. Reading a malicious sentence does nothing. The harm is the action that follows: the Bash call, the network request, the file write. That is both the problem and, as it turns out, the solution.
Where can a prompt injection attack be stopped?
Because the harm is the action, the place to stop a prompt injection is at the action, on the endpoint, before the process starts.
A sensor with a hook into the agent reads every tool result the agent sees. When it recognises text addressed to the agent, an instruction rather than data, it marks the session. Then it watches the next tool call. If the agent's very next move is a shell command, a network destination it has not used, or a write to a sensitive location, the hook blocks it and raises a threat that shows the injected text, its source, and the command it stopped.
The agent tells the developer the command was blocked. The developer looks at the forum post, sees the hidden comment, and understands what happened. Nobody rotates a credential that afternoon, because nothing was taken.
This approach does not depend on recognising the wording of the injection. It depends on the causal link between reading an instruction and taking a dangerous action, which is far harder for an attacker to disguise.
Direct and indirect prompt injection
It is worth being precise about the two forms, because they call for different defences.
A direct prompt injection is typed into the chat by whoever is using the agent. In a coding agent on your own machine this is mostly a self-inflicted risk, and it matters more in agents that are exposed to untrusted users, such as a customer-facing assistant.
An indirect prompt injection is the one that should keep a security team up at night. The instruction is planted in content the agent will read while doing legitimate work, and the person driving the agent never sees it. The sources multiply as agents gain tools: a web page returned by search, a dependency's README, a code comment in a repository the agent was asked to review, a row in a database the agent queried, the output of another tool, even an image with text in it. Every new capability an agent gets is a new channel for an indirect injection, which is why the problem grows rather than shrinks as agents get more useful.
Why this is not a solved problem at the model layer
Model builders have worked hard on this, with system prompts that tell the model to distrust instructions in content, and with training that makes models better at spotting manipulation. These help, and they still fail, because the model has to be right every time and the attacker has to be right once. A model that resists ninety-nine injections and follows the hundredth has still leaked your credentials.
This is the same shape as every other security problem: you do not rely on the target being perfect, you add a control that catches the failure. At the model layer, prompt injection is an open research problem. At the action layer, on the endpoint, it is a tractable engineering problem, because the set of dangerous actions is small and observable even when the set of malicious phrasings is not.
Real campaigns, not just demos
Prompt injection is sometimes dismissed as a lab trick. The supply chain incidents of the past year say otherwise. In May 2025 Invariant Labs showed a poisoned GitHub issue steering an agent into leaking a private repository through the GitHub MCP server. Malicious packages and extensions have carried instructions and payloads that ran inside developers' agents and tools, exfiltrating source and keys at scale. The MCP servers an agent loads are one of the main ways that text reaches it. When the same injected text appears across many endpoints, it is a campaign, and treating each occurrence as an isolated curiosity misses the pattern. Detection that reports to a shared console lets a security team see one injection become many and respond once, rather than one machine at a time.
Every one of those campaigns worked on machines nobody was watching for it. A team can review one agent's sessions after the fact and find the poisoned issue, the instruction and the command that followed. It cannot do that across every developer laptop, every day, for every tool result an agent reads. The same poisoned README lands on twenty machines in the same week, and the only way to know it is a campaign rather than a one-off is to see the same injected text from twenty sensors. Detection has to run where the tool result arrives, on every endpoint, and the records have to land in one place.
The GitHub MCP attack needed one poisoned issue and one agent with the developer's access. Join the launch list and be first to run it on your own endpoints.
How do you prevent prompt injection in your organisation?
A practical programme against prompt injection attacks has a few parts.
- Detect on the endpoint, not at the network. Only the endpoint sees the tool result that carried the injection and the action that followed it.
- Block the action, not the sentence. Judge the command, the destination or the write that comes after injected instructions, rather than trying to filter every phrasing.
- Constrain standing permissions. An agent that has been granted the right to run any command without asking removes the one natural checkpoint. Decide which permissions an agent may hold, and enforce it.
- Watch for campaigns. The same injected text seen on several endpoints is not a coincidence; it is a campaign, and it should be raised as one.
- Keep the evidence. Every blocked attempt should be a record with the injected text, the source and the stopped command, so an incident is a five-minute read rather than a reconstruction.
Prompt injection is often described as unsolved, and at the level of the model it largely is. But you do not have to solve it in the model. You have to stop the action it triggers, and that action happens somewhere you can watch: the endpoint.
How ZYBE handles this
The ZYBE sensor sits in the agent's own hook chain, so it sees every tool result before the agent acts on it and every command the agent runs next. Injected text in a tool result is raised as instructions to the agent in tool output; when the agent then reads a credential or opens a connection it becomes agent acted after instructions arrived in tool output, and a runtime rule can block that action on the endpoint before it completes. The same injected text arriving on several machines is raised once, as same injected instructions on several endpoints. The console keeps each attempt as a record with the source, the injected text and the stopped command, and the compliance view marks the setting tool output is inspected for injected instructions per endpoint, so an auditor can see the control is on.
Join the launch list: first access when ZYBE opens, and what we find on real laptops before then.
Frequently asked questions
Can prompt injection be prevented? You cannot reliably stop a model from reading an instruction, but you can stop the dangerous action that follows it. Blocking the shell command, network call or file write after injected instructions on the endpoint prevents the harm.
Why does input filtering not stop prompt injection? Filtering scans for known phrasings, and attackers have unlimited ways to rephrase, encode or split an instruction. The reliable signal is the action the injection triggers, not the wording.
Where should prompt injection be detected? On the endpoint. A network proxy sees that traffic went out but not why. The endpoint sees the tool result that carried the injection and the command the agent ran next.