The Promptware Kill Chain: Why "Prompt Injection" Doesn't Cut It Anymore

(This blog post was completely written by Anthropic Claude 4.6 opus)

We need to talk about how we're framing AI security, because we're getting it dangerously wrong.

For years, the conversation around LLM vulnerabilities has orbited a single term: prompt injection. It's catchy, it's easy to grasp, and it makes the problem sound like something we can patch. But Bruce Schneier, along with co-authors Oleg Brodt, Elad Feldman, and Ben Nassi, just published a piece (and accompanying paper) that reframes the entire discussion — and honestly, it's the kind of mental model shift the AI security space desperately needs.

From a Bug to a Kill Chain

Their argument is straightforward: prompt injection isn't a vulnerability. It's an entry point. What follows is a full-blown, multistage malware campaign that mirrors the sophistication of traditional cyberattacks like Stuxnet or NotPetya. They call this class of attack "promptware", and they've mapped it to a structured seven-step kill chain:

1. Initial Access — The malicious payload gets in, either through direct prompts or, more insidiously, through content the LLM retrieves on its own: a webpage, an email, a shared doc, even an image or audio file.
2. Privilege Escalation — What we've been calling "jailbreaking." The attack bypasses safety guardrails, effectively going from standard user to admin on the model's capabilities.
3. Reconnaissance — The compromised LLM is manipulated into revealing what it's connected to, what tools it has access to, and what it can do. The model's own reasoning ability gets weaponized against it.
4. Persistence — The attack embeds itself into long-term memory or poisons the databases the agent relies on, ensuring it survives beyond a single interaction.
5. Command & Control — The promptware evolves from a static payload into a controllable trojan, dynamically fetching new instructions from the internet.
6. Lateral Movement — The attack spreads. An infected email assistant forwards the payload to all contacts. A compromised calendar app pivots to smart home devices. The interconnectedness we built for convenience becomes the highway for propagation.
7. Actions on Objective — The endgame: data exfiltration, financial fraud, arbitrary code execution, or worse.

This Isn't Theoretical

What makes this genuinely unsettling is that the full chain has already been demonstrated in research settings. In one example, researchers embedded a malicious prompt in the title of a Google Calendar invitation. When a user innocently asked their AI assistant about upcoming meetings, the prompt hijacked the assistant, launched Zoom, and began covertly livestreaming the victim's video feed. The user did nothing wrong. They just checked their calendar.

In another, an AI email worm self-replicated across inboxes — each time the assistant was asked to draft a new email, it embedded the malicious payload and exfiltrated sensitive data to the attacker, spreading to every new recipient.

The Architectural Problem We Can't Patch Away

Here's the uncomfortable truth at the core of all this: LLMs have no architectural boundary between code and data. In traditional computing, we learned (painfully) to separate executable instructions from user input. LLMs process everything — system commands, user queries, retrieved documents — as one undifferentiated stream of tokens. A malicious instruction hidden in a harmless-looking email gets processed with the same authority as a system prompt.

This isn't a bug we can fix with better training or smarter filters. It's a fundamental property of how these models work.

So What Do We Do?

The authors' key insight is one that traditional cybersecurity learned a long time ago: assume the perimeter will be breached. If we accept that initial access will happen — and with the current architecture, it will — then the focus shifts to breaking the chain at every subsequent step. Limit what a jailbroken model can actually do. Constrain what it can discover about its own environment. Prevent persistence. Restrict lateral movement. Put hard guardrails on the actions an agent is permitted to take, regardless of what it's been told to do.

In other words, defense-in-depth. Not a silver bullet, but a systematic approach to risk management that treats AI agents with the same rigor we apply to any other attack surface.

We're in the middle of a gold rush to give AI agents access to our emails, calendars, code repositories, financial accounts, and smart homes. The promptware kill chain is a sobering reminder that every new integration isn't just a feature — it's an attack surface. And we'd better start treating it that way.

Read the original post on Schneier on Security and the full paper on arXiv.