Prompt Injection Defense

## What the trifecta names The lethal trifecta is a design test, not an attack. It says that for an injected instruction to actually *steal* something, three properties have to coexist in the same agent session: 1. **Access to private data** — mailboxes, tickets, source code, customer records, anything the attacker does not already have. 2. **Exposure to untrusted content** — any text the agent reads that an outsider can influence: an email body, a web page, a PDF, a calendar invite, a code comment, a tool result. 3. **An ability to communicate externally** — any path by which bytes leave the trust boundary. The framing matters because it moves the conversation away from "is the model gullible?" (it is, and that will not change soon) to "what can a gullible model reach?" ## Why any two legs are survivable An agent with private data and untrusted content but no outbound path can be tricked into producing wrong answers, which is a correctness problem, not a breach. An agent with untrusted content and an outbound path but no private data can be made to send garbage, which is abuse, not theft. An agent with private data and an outbound path but no untrusted content has no attacker in the loop at all. Only the full set turns "the model believed a stranger" into "the stranger got your data." ## The worked example Take an email-and-calendar assistant with three tools: read the inbox, send mail, and fetch a URL for context. That is the textbook trifecta. An attacker sends a meeting invite whose description contains text addressed to the agent rather than the human. When the user asks "what's on my calendar tomorrow?", the agent reads the invite, follows its instructions, and mails the week's meetings to an external address — or, more quietly, fetches an attacker-controlled URL with the data encoded in the query string. The user clicked nothing suspicious; the untrusted content arrived on its own. That zero-click shape is exactly what the EchoLeak class of findings in enterprise assistants demonstrated: ordinary received content is enough to start the chain. ## Finding the legs honestly Most failed reviews are failures of enumeration, not of judgement. - **Private data hides in retrieval.** A RAG index built from internal wikis is private data even though no tool is named "read secrets." - **Untrusted content hides in tool results.** Anything an agent reads back from the outside world is attacker-influenceable, including search snippets and error messages from third-party APIs. - **Outbound channels hide everywhere.** Rendering a markdown image whose URL the model chose is an outbound channel. So is a web search, a DNS lookup, a support-ticket comment, a git push, a webhook, and a "harmless" link the user is likely to click. If you cannot draw the three sets for a feature, you cannot claim it is contained. ## Using it as a gate Run the test per **session**, not per product. A product may legitimately do all three things as long as no single session holds all three. Common cuts: - **Cut the outbound leg** for the session that reads untrusted content — let it produce only a structured result that a separate, non-network step consumes. - **Cut the private-data leg** — do the untrusted reading in a session whose credentials see nothing sensitive. - **Cut the untrusted leg** — pin the privileged session to content you control, and have a quarantined step summarise the rest into a constrained shape. The important property of all three cuts is that they are deterministic. They hold whether or not the model was fooled, which is the whole point: model-layer mitigations are probabilistic and an attacker who can retry will eventually find the phrasing that gets through. ## What the trifecta does not cover The trifecta is scoped to **exfiltration**. An agent with untrusted input and write access but no private data is outside it, and can still delete a production table or post a defamatory message. That is why the broader pick-two constraints treat "changes state" as a risk leg in its own right, and why the trifecta is a first-pass filter rather than a complete threat model. It is also silent about how you *implement* the cut — which credentials, which sandbox, which egress policy — those are separate engineering problems. What it gives you is a five-minute review question that reliably catches the architectures that cannot be saved by prompting.