The lethal trifecta

Read these first

• Why it cannot be prompt-fixed

What you will know

• Trace a real agent's private-data sources, untrusted-content inputs, and external communication sinks, and record evidence for each leg

  Include indirect paths such as retrieved documents, tool-returned text, webhooks, email, and shared credentials rather than only the prompt and model API.

• Reproduce an exfiltration attack against a sandboxed agent that has all three legs, using a canary secret and a controlled outbound endpoint

  The test should demonstrate data moving from a trusted store through attacker-influenced content to an observable external destination.

• Show that removing any one leg defuses a given attack

  A valid removal must be enforced at the capability or network boundary; prompt instructions that merely ask the model not to use a tool do not count.

• Patch the agent by breaking or constraining one leg, then rerun the attack and its normal workflow tests

  The mitigation should block the demonstrated path without silently leaving an equivalent route through another tool, destination, or representation.

• Compare two mitigations with measured effects on task success, latency, operational complexity, and residual exposure, then choose one

  A narrower allowlist, read-only access, approval gate, or network isolation can have very different failure and maintenance costs even when each blocks the same proof of concept.

Chapters

1. 1

   The lethal trifecta

   Private data, attacker-authored content and an outbound path are each ordinary on their own; the combination is what turns a prompt injection into a data leak. This chapter defines the three properties, counts them on two agents that each hold two, and shows why the dangerous system is usually created by a ticket about reducing operational overhead rather than by anything that looks like a security change. It also covers what the count is silent about, since sabotage and destructive writes need only two legs.

   Read chapter
2. 2

   Tracing sources, inputs and sinks

   The list you count legs on is not the tool manifest. A scheduling assistant's maps and weather responses are authored outside your company yet get filed as system data, and an internal assistant with no tools at all still has an outbound channel, because a markdown image URL the model writes makes the user's browser fetch it the moment the message renders. Here you build three lists — private-data sources, untrusted-content inputs, external-communication sinks — with the specific evidence that puts each entry on one.

   Read chapter
3. 3

   Canary tokens and a controlled endpoint

   Settling an argument about exploitability means moving one value from the private store to a place you can watch: a high-entropy canary planted where the agent will actually read it, a payload in the untrusted channel, and a listener you own. Exfiltrating a real internal document instead causes the breach you were preventing, with your name on it. The chapter also covers reading a run that produced nothing, which has three explanations before 'it is secure', and what goes into the report and to whom.

   Read chapter
4. 4

   Removing a leg at a boundary

   A sentence in the system prompt is evaluated by the same model an attacker is arguing with, on an input the attacker wrote, so it removes nothing. Removal happens where the model gets no vote: a revoked credential, an unregistered tool, a default-denied network, a renderer that will not fetch a URL. This chapter contrasts the two in code and shows how to assert that a removal is real, by proving the model still tried and was blocked at the boundary rather than that nothing happened to arrive.

   Read chapter
5. 5

   Equivalent exfiltration routes

   The proof of concept fails and the ticket wants to close. Before it does, walk the sinks the trace listed and re-point the payload at each: a rendered image, an email relay, a webhook, a shared store, an allowed internal host that redirects, a DNS lookup carrying the canary in a subdomain. Rerun the ordinary workflow too, with its latency budget, since a mitigation that quietly breaks normal tasks gets loosened by whoever is least interested in the threat model.

   Read chapter
6. 6

   Comparing mitigations by residual exposure

   Default-deny egress with a documentation allowlist, a human approval before outbound email, and pre-caching a corpus instead of fetching URLs can all defeat the same proof of concept while differing in task success, latency, operational work and what survives. An allowlist becomes the new surface as hosts accumulate; approval keeps the capability and sees intent but decays into clicking. This chapter compares them on the four dimensions, picks, and then watches what the pick left exposed.

   Read chapter
7. 7

   Constraining an unavoidable trifecta

   A support agent must read the account, read the customer's message and reply by email, so no leg is available for removal. The comforting argument that data and content belong to the same person survives only the simplest case, failing once a reply is quoted into a shared thread, someone impersonates a customer, the knowledge base takes writes from others, or the record names a third party. Here you constrain each leg instead, and read the production counters that show the constraints holding.

   Read chapter