The Lethal Trifecta Checklist
Day 1 named the three conditions. Day 2 put them on the loop. Day 3 showed you the protocol that carries them. Today we turn all of it into something you actually use: a checklist you run against a target in minutes, before you write a single payload, that tells you whether an agent is exploitable and where to push.
This is the most practical post of week one. Print it. Tape it above your desk. By the end you should be able to look at any agent deployment and give a yes or no answer to the only question that matters at the start of an engagement: are all three conditions present, and if so, what is the shortest path between them?
Why a checklist beats intuition
Prompt injection has a reputation for being fiddly and unreliable. Payloads that work on Monday fail on Tuesday. A model update changes everything. Newcomers waste days crafting clever text against agents that were never exploitable to begin with, and miss trivial wins against agents that were wide open.
The fix is to stop starting with payloads. Start with structure.
The lethal trifecta, Simon Willison’s framing, holds up because it describes the preconditions for damage, not the technique. Sysdig reviewed the major public findings and reached the same conclusion: nearly every significant prompt injection finding shares one pattern, an agent with access to private data, exposure to untrusted content, and the ability to communicate externally. If those three are not all present, the worst you get is a confused agent. If they are all present, you have an exfiltration primitive and the only remaining work is delivery.
So the checklist answers structure first. Payloads come later, and only against targets that passed.
The three conditions, defined precisely
Vague definitions cause missed findings. Here is each condition tightened up.
Condition A, access to something valuable. The agent, through any tool, can reach data or actions worth stealing or abusing. Not just databases. Private repos, the user’s inbox, internal wikis, cloud credentials in the environment, a payments API, an admin action. The test is not is there a database. The test is can this agent touch anything an attacker would want.
Condition B, exposure to untrusted content. The agent reads text that someone outside your trust boundary can influence. This is the one people underestimate. It includes the obvious, web pages and emails, and the non obvious: file names, commit messages, calendar invite titles, PDF metadata, error messages that echo user input, a row in a shared spreadsheet, the alt text of an image, a package README pulled during a build. If an outsider can shape one byte the agent reads, condition B is met.
Condition C, ability to communicate outward. The agent can send bytes somewhere the attacker can observe or control. Obvious channels: HTTP requests, outbound email, a webhook, a pull request. Sneaky channels that count and get missed: a rendered markdown image whose URL the agent constructs, a link the agent emits that gets auto fetched for a preview, a DNS lookup, writing to a file in a location the attacker can later read, even a git push. If data can leave in any form the attacker eventually sees, condition C is met.
The subtlety across all three: they do not need to live in the same tool. Condition B might be your ticket reader, condition A your database, condition C your email sender. The agent bridges them. That is the whole trick, and it is why per tool review misses it. You have to look at the union.
The checklist
Run this against a target. For each tool the agent can call, fill one row.
TOOL: ______________________________
Reads external content? (B) Y / N source: __________
Reaches valuable data/action? (A) Y / N what: __________
Can send data outward? © Y / N channel: __________
Executes as identity: __________ scope: __________
Worst case with attacker-chosen args: __________
Then the roll up, which is where the finding actually appears:
TRIFECTA ROLL-UP
Any tool satisfies B? Y / N -> list them (entry points)
Any tool satisfies A? Y / N -> list them (targets)
Any tool satisfies C? Y / N -> list them (exits)
ALL THREE PRESENT ACROSS THE TOOLSET? Y / N
If Y: shortest B -> A -> C chain: __________
If the last line has a value, you have your attack. Everything in week two and three is technique for walking that chain. If all three are not present, you note which is missing, because that is also the defender’s answer, and move on rather than burning a day on clever text.
Worked example: the support triage agent
Concrete makes it stick. A company runs an agent that triages support tickets. It has three tools:
list_tickets reads ticket bodies from the support systemquery_orders looks up order and customer records in the production databasesend_reply emails the customer who opened a ticket
Run the checklist.
list_tickets: reads external content, yes, because anyone can open a ticket and write anything in the body. Condition B, this is the entry point.
query_orders: reaches valuable data, yes, customer records and order history. Condition A, this is the target.
send_reply: sends data outward, yes, email to an address that in practice can be influenced. Condition C, this is the exit.
Roll up: all three present. Shortest chain is list_tickets to query_orders to send_reply. An attacker opens a ticket whose body instructs the agent to look up another customer’s records and include them in the reply. Nobody approved that. The user asked for triage.
This is not hypothetical. It is the exact shape of the Supabase class incident, where an attacker embedded a malicious instruction inside a support ticket message and the agent connected to the database through MCP acted on it. The checklist would have flagged it in under five minutes, before a line of payload existed.
Second example: the coding assistant
Different surface, same method. An IDE agent with:
- web fetch, to read documentation
- filesystem read and write across the project
- a terminal that runs allowlisted commands
web fetch: reads external content, yes, arbitrary pages. Condition B.
filesystem and terminal: reach valuable data and actions, source code, secrets in env files, and code execution on the developer’s machine. Condition A, and a severe one because execution is local.
Exit for condition C: the terminal itself. A git push, a curl, a DNS lookup all send data out. Condition C.
All three present. And the environment poisoning angle makes it worse, because the Cursor case, CVE-2026-22708, showed that allowlisted commands like git branch can be made to deliver arbitrary payloads when the execution environment is poisoned, so the terminal is both target and exit at once. Chain: web fetch a poisoned doc, act on injected instructions, exfiltrate through the terminal.
Two very different products. Same three boxes ticked. That is the power of structure over intuition.
What breaking the trifecta looks like
Since the same checklist is what a defender runs, it is worth seeing the mitigations mapped to conditions, because it tells you which findings will actually get fixed and how.
Break A. Scope the agent’s reach down. Per user tokens instead of one broad service token. This directly attacks the confused deputy problem from Day 2, where the agent’s effective permissions were the union of everything a broad token could reach.
Break B. You mostly cannot. Reading untrusted content is usually the agent’s job. Do not expect this one to hold, which is why input filtering fails, per Sysdig’s finding that adaptive attacks bypass essentially every published defense.
Break C. Constrain outbound channels. Allowlist destinations, strip agent constructed URLs from rendered output, block auto fetching link previews, disable outbound email to non verified addresses. This is often the cheapest real mitigation, and its absence is often your easiest finding.
The lesson for you as an attacker: condition B almost always holds, so your effort goes into finding the weakest of A and C. The defender who understands this spends their budget on C. The one who does not spends it on a doomed injection classifier.
Homework for Day 4
Take the loop diagram you drew on Day 2 and run the full checklist on it.
- Fill one tool row per tool. Be honest about the sneaky B and C channels, file names, image URLs, link previews.
- Do the roll up. List entry points, targets, exits separately.
- Write the shortest B to A to C chain in one sentence.
- Now do it a second time for a completely different agent, ideally one from a different category. A chatbot if your first was a coding tool, or the reverse.
- Compare. Notice that the chains rhyme even though the products do not.
Keep both filled checklists. On Day 7 you build a lab, and these two profiles are what you will reconstruct and attack for real.
Day 5 zooms out to the OWASP Top 10 for Agentic Applications, so you can put standard names to every chain you just found and speak the same language as the reports and the defenders.
