← writing

Promptware Defense Checklist: One Control per Kill-Chain Stage

The take-home from my BSides DFW 2026 talk. Prompt injection is a probability, not a bug, so defend what the agent can do, not the text it reads. One control for each stage of the promptware kill chain, the four real cases behind them, and every source.


[Disclaimer: The opinions, insights, and perspectives shared here are solely my own and do not reflect those of my current or past employers, nor do they convey any confidential information by any means.]

This is the handout for my BSides DFW 2026 talk, “Promptware: How Attackers Exploit Agentic AI and What Defenders Actually Do About It.” If you scanned the QR code at the end, this is the checklist and the sources.

The idea in four lines

  1. Agents mix instructions and data in one channel. There’s no parameterized query for an LLM, so injection can’t be patched in the model. It can only be made less likely.
  2. So injection is a probability, not a bug. A defense that has to catch every injection fails eventually, because the attacker needs one success and you run thousands of sessions a day.
  3. What attackers want is the agent’s access: its shell, its credentials, its email.
  4. So defend the actions, not the text. Ask “what can the agent do if we missed the bad prompt?” instead of “did we catch it?”
untrustedtext quarantinedreader values only privilegedplanner never reads untrusted text policygate schema, exact args, egress denied by default tools
Defend the actions: the planner that calls tools never reads raw untrusted text, and every call it makes is checked against policy before it runs.

The checklist: one control per stage

The stages come from the promptware kill chain (Nassi, Schneier, Brodt and Feldman, arXiv 2601.09625).

INITIALACCESS quarantineretrieved textas data PRIVILEGEESCALATION agent can'tedit its ownpermissions PERSISTENCE memory writescarry provenanceand get reviewed LATERAL MOVEAND C2 egress deniedby default,per-server creds ACTIONS ONOBJECTIVE short-lived creds,tool-call logs,verified outcomes
Top: what the attacker needs at each stage. Bottom: the control that takes it away. Recon is left out on purpose; it uses the agent's own tools, so the controls downstream cover it.
Stage Control How to check it
Initial access (prompt injection) Treat everything retrieved as data, and quarantine it. The model that plans tool calls never reads raw untrusted text. Can a sentence in a fetched web page, issue, or file change which tool gets called?
Privilege escalation (jailbreak) The agent never edits its own permissions. Deny writes to .vscode/, .cursor/, .claude/, MCP config files, credential stores, and shell profiles at the tool boundary. Ask the agent to set its own auto-approve flag. Is the write blocked and logged?
Persistence (memory and retrieval poisoning) Memory writes carry provenance (which source, which session) and get reviewed before they’re trusted. Can you say where each stored memory came from?
Lateral movement and C2 Egress denied by default, plus per-server credentials. Each MCP server gets only its own secret and only the hosts it needs. Does a new, unknown domain fail to connect and raise an alert?
Actions on objective Short-lived credentials minted per task, tool-call logs, and verified outcomes. “Done” is a claim until you read the result back. Is any credential older than the task it belongs to?

Pick the stage where you have nothing. Start there on Monday. If you can only do one thing, make egress deny-by-default for the agent’s runtime. It turns most exfiltration into a failed connection you can alert on.

The demo from the talk

In the talk I replayed one attack twice. A README carries an HTML comment, invisible when rendered, telling the agent to turn on auto-approve and send .env to an outside address. Without a gate, all four tool calls succeed and the agent reports “Build complete.” With the policy from the checklist (no writes to the agent’s own config, egress denied by default), the same agent reads the same README and tries the same things. The settings write and the outbound post are both denied and logged, which fires two of the alerts below. The gate never had to judge the README. It only judged two actions.

Three alerts worth writing this week

  • A write to an agent’s own config files.
  • The first-ever egress to a new domain from an agent runtime.
  • A credential used when no agent task is active.

What doesn’t work on its own

  • System-prompt warnings. They’re text competing with text in the same channel.
  • Prompt classifiers as the only control. Run them as a layer; adaptive attackers find what they miss.
  • Approval prompts. People get tired of them, and case 1 below shows an agent being steered to turn them off.
  • Command-name allowlists. Case 2 below bypassed one through the environment.

The four cases

poisoned contentCopilot · CVE-2025-53773 poisoned environmentCursor · CVE-2026-22708 poisoned packagepostmark-mcp · npm 1.0.16 poisoned server metadatamcp-remote · CVE-2025-6514 youragent
Every case attacked something the agent was designed to trust. None of it lives in the code your scanners read.
Case What was poisoned What it shows Fix that stops it
CVE-2025-53773, GitHub Copilot in Visual Studio (CVSS 7.8, Aug 2025; Johann Rehberger) Content the agent read Injected text made the agent write its own auto-approve setting, so terminal commands ran unconfirmed Agent never edits its own permissions
CVE-2026-22708, Cursor 2.2 and earlier (fixed in 2.3, Jan 2026; Pillar Security) Content the agent read In Auto-Run mode with an allowlist, some shell built-ins ran unapproved, so injection could change the environment of trusted commands Gate the tool call on exact arguments, not command names
postmark-mcp (Koi Security, Sep 2025) A tool server from npm Fifteen clean versions, then 1.0.16 added one line that BCC’d every email to an attacker Pin versions with integrity hashes; contain third-party servers
CVE-2025-6514, mcp-remote 0.0.5 to 0.1.15 (CVSS 9.6, Jul 2025; JFrog) A tool server’s OAuth response A crafted authorization URL reached an OS open call, giving command execution on the client Contain third-party servers; deny-by-default egress

How I contain third-party MCP servers in my own open-source work: each one runs in Docker with no network, a read-only root filesystem, and a throwaway home directory. The setup is public in agent-fault-lab.

Where agents attack, not just get attacked

The talk opens with JadePuffer, which Sysdig’s Threat Research Team documented in July 2026 and assessed as the first fully autonomous agentic ransomware campaign. An agent exploited an internet-facing Langflow instance through CVE-2025-3248, harvested credentials, reached a production Nacos server, and encrypted about 1,300 configuration records. It went from a failed login to a working fix in 31 seconds. The exploits were old; the adaptive operator was new. Sysdig’s caveats apply: “first” is their assessment, and a human set up the campaign infrastructure.

Sources

  • Nassi, Schneier, Brodt, Feldman, “The Promptware Kill Chain,” arXiv 2601.09625 (v2, Feb 2026).
  • Simon Willison, “The lethal trifecta for AI agents”, June 16, 2025.
  • Beurer-Kellner et al., “Design Patterns for Securing LLM Agents against Prompt Injections,” arXiv 2506.08837, June 2025.
  • Debenedetti et al., “Defeating Prompt Injections by Design” (CaMeL), Google DeepMind, arXiv 2503.18813, 2025.
  • CVE-2025-53773 (NVD), Microsoft Patch Tuesday, August 12, 2025; research by Johann Rehberger, Embrace The Red.
  • CVE-2026-22708 (NVD), advisory GHSA-82wg-qcm4-fp2w; credited to Dan Lisichkin, Pillar Security.
  • Koi Security, report on the postmark-mcp npm package, September 2025.
  • CVE-2025-6514 (NVD), JFrog Security Research, July 2025.
  • CVE-2025-3248 (NVD), Langflow, fixed in 1.3.0.
  • Sysdig Threat Research Team, JadePuffer reports, July 1 and July 20, 2026.
  • MITRE ATLAS, the knowledge base of adversary tactics against AI systems: atlas.mitre.org.
Cite this

Khan, M. (November 7, 2026). Promptware Defense Checklist: One Control per Kill-Chain Stage. Moeez Khan. https://moeezkhan.com/writing/promptware-defense-checklist/

Moeez Khan
Moeez Khan

Software Engineer at AWS Transform, building agentic AI for enterprise and mainframe modernization — and writing about making legacy tractable at scale.

← More writing