Most AI security programs stop at the first stage. A team runs a battery of adversarial prompts, the model breaks the guardrail once in fifty attempts, the finding becomes a medium-severity ticket, and the matter is closed. The report says "the model is vulnerable to prompt injection." It does not say what an adversary would do with that.
That is the gap the Promptware Kill Chain exists to close. We adapted the framework from the research of Schneier et al. (2025) and turned it into a seven-stage offensive methodology — from initial access to full compromise. The premise is simple: prompt injection is not the attack. It is the way in.
Why the traditional kill chain does not fit
Classic frameworks assume a sharp boundary between code and data. A binary executes instructions; a configuration file supplies parameters. Exploitation happens when the attacker manages to move data over to the code side.
In an LLM, that boundary does not exist. The system prompt, the user input, the document retrieved from the vector store, and a tool's output all reach the model through the same channel — text. The model has no structural mechanism to distinguish the operator's legitimate instruction from the instruction planted inside a PDF the RAG pipeline just indexed.
The practical result: every piece of data that enters the context is potentially executable. An attack framework for AI systems has to start from that reality, not adapt to it.
The seven stages
1. Initial access
The adversary gains entry into the AI system. The vectors we test most often:
- Direct prompt injection — the user is the attacker, interacting directly with the interface.
- Indirect prompt injection — the instruction arrives through content the system consumes: an email, a web page, a support ticket, a document in the vector store.
- Data poisoning — manipulation of the fine-tuning corpus or the embeddings.
- Compromised plugins and endpoints — the third-party integration as the entry point.
The indirect vector is the most underestimated and the most exploited in real incidents. It does not require the attacker to have access to the system — only that they get text where the system will read it.
2. Privilege escalation
Inside the model's context, the attacker widens what they can do: they bypass guardrails, extract the system prompt, or unlock tool calls that should be restricted to the operator.
Extracting the system prompt is usually treated as a low-severity finding. It is not. The system prompt describes the connected tools, the authorization limits, and often the structure of the accessible data. It is the network map — just written in natural language.
3. Reconnaissance
The adversary enumerates capabilities: which tools the agent can invoke, which data sources it reaches, what other agents exist in the pipeline, which credentials are in scope for the session.
This is where the asymmetry becomes obvious. An agent with access to email, calendar, and a corporate vector database answers questions about its own configuration just as helpfully as it answers questions about the business.
4. Persistence
The stage that separates a desk exercise from a realistic one. The attacker writes instructions into a location that survives the end of the session:
- the agent's long-term memory;
- documents in the vector store that will be retrieved in future conversations;
- configuration files or project rules the assistant reads on every startup.
Across the incidents we catalogued between 2025 and 2026, 57% of the cases kept persistence active after the initial detection. The organization remediated the symptom — blocked the prompt, tuned the filter — and left the payload in place.
5. Command and control
Outbound channels get established. An agent with web access has a built-in C2 channel: encode the data in a request path. An agent with email access has another. The conversation memory of a shared assistant can serve as a dead drop between operations — exactly the pattern observed in the ZombAI case.
6. Lateral movement
The compromised agent reaches other systems. In multi-agent architectures, one agent trusts another agent's output for the same reason it trusts user input: it is all text. An instruction planted in agent A is executed by agent B as if it were legitimate.
The GeminiJack incident demonstrated lateral movement across an entire Workspace environment, zero-click, with the user interacting with nothing.
7. Actions on objective
Data exfiltration, system manipulation, fraud, or use of the access as a bridge into the traditional environment. CVE-2025-53773 (GitHub Copilot) and CurXecute (Cursor IDE) close the loop unambiguously: a malicious code suggestion leading to arbitrary command execution on the developer's machine. The attack starts in natural language and ends in a shell.
What the data shows
We catalogued 21 promptware incidents between 2025 and 2026. Two numbers matter more than the rest:
- 15 of the 21 exhibited four or more kill chain stages. Attacks on AI systems are not one-shot. They are campaigns.
- 57% kept persistence after the initial detection. Dwell time is long because the detection surface — memory, embeddings, context — is not monitored by existing controls.
If your AI security test produces a list of prompts that broke the guardrail, you measured stage 1 and extrapolated the rest.
How this changes the test
Applying the kill chain reorganizes the exercise around three questions:
- Reach. Once the model is compromised, what does it actually reach? Not what the documentation says — what the session credentials allow.
- Persistence. Is there any writable location the model reads back? If so, it is a persistence mechanism, whether or not it was designed as one.
- Detection. Do stages 4 through 6 generate any observable signal? In most environments we assess, the answer is no — the logs record the interaction, not the intent.
The output stops being a list of jailbreaks and becomes an attack path with reproducible evidence at every stage, severity classified by business impact, and a justified remediation order.
Where to start
If you run AI systems in production, three controls give the best immediate return:
- Reduce agency. Most of the severity comes from stage 7, and stage 7 is bounded by what the agent can do. Read permissions instead of write permissions eliminate entire classes of impact.
- Treat memory as an attack surface. If the agent writes to a store it later reads back, that store needs review, expiration, and logging.
- Instrument stage 5. Outbound calls initiated by agents — HTTP, email, tool invocation — must be logged and correlatable to the input that triggered them.
None of these controls depend on the model "resisting" prompt injection. That is the point: the kill chain assumes stage 1 will succeed and designs the defense for the six stages that follow.
The Promptware Kill Chain is the framework behind our AI Red Team exercises and our LLM pentest. To discuss applying it in your environment, talk to the team.