The lethal trifecta: the fire triangle of AI agents
Every fire safety course starts with the fire triangle: fuel, oxygen, ignition. You need all three — remove any side and the fire cannot start. For AI agents there is an exact equivalent: Simon Willison called it the lethal trifecta, and it is the most useful framework we have for assessing the security of any agentic deployment.
The three sides of the triangle
The trifecta is the co-presence, in the same agent, of three capabilities:
- Access to private data — the agent can read confidential information: email, documents, repositories, databases, CRM records.
- Exposure to untrusted content — text you do not control reaches the agent's context: an incoming email, a web page, a GitHub issue, an attachment.
- External communication — the agent can get information out: send email, make HTTP requests, publish, commit.
Taken one by one, these are normal capabilities — indeed, they are exactly what makes an agent useful. The problem is the combination, and the reason is structural: a language model follows the instructions it finds in the content it reads, and cannot reliably distinguish its operator's instructions from those an attacker has hidden in any piece of text. This is indirect prompt injection — a relative of SQL injection: mixing trusted and untrusted content in the same channel. If the agent reads confidential data, encounters hostile content and can write to the outside, the attacker has everything they need: their instructions become orders, and the outbound channel becomes the exfiltration pipe.
Not a theory: the GitHub MCP case
In May 2025, researchers at Invariant Labs demonstrated the full attack against one of the most widely used agentic tools, GitHub's MCP server. The setup mirrors thousands of real developers: a public repository where anyone can open issues, a private repository with proprietary code, and an agent accessing both with the same token.
The attacker opens a seemingly innocuous issue in the public repo ("About The Author") containing hidden instructions. The unsuspecting developer asks their assistant: "take a look at the open issues". The agent reads the issue, gets injected, pulls data from the private repository — in the demonstration: personal information, confidential plans, even the user's salary — and publishes it in a pull request on the public repo, where the attacker reads it at leisure.
The crucial point: there was no bug to patch. The MCP server worked exactly as designed; every single action was legitimate and authorised by the token. The architecture itself was wrong: private data, hostile content and an outbound channel in the same session. Complete triangle, guaranteed fire. And GitHub MCP is merely the most instructive case in a long list: same-class vulnerabilities have been documented in Microsoft 365 Copilot, GitLab Duo, ChatGPT, Slack and Amazon Q.
Why guardrails are not enough
The market's instinctive answer is "let's add a filter that detects prompt injections". Willison is blunt on this point, and he is right: vendors promising to block "95% of attacks" are declaring failure, not success. In application security, a filter that lets one attack in twenty through is not a defence: it is a lottery. Nobody would accept a firewall like that. Prompt injection is not a malformed input to be recognised: it is natural language, infinitely rephrasable, indistinguishable by construction from legitimate content.
Robust defence is not probabilistic but structural: as with the fire triangle, you do not need to put out the fire — you need to remove a side.
Breaking the triangle
Any side will do. Which one to remove depends on the use case:
- Remove the private data — an agent processing external content (incoming email, the web, third-party documents) works with the bare minimum: least privilege per tool, as we discussed when talking about agentic identities. The token reading public issues must not be able to open the private repository: Invariant's proposed mitigation — one repository per session — is exactly this.
- Remove the untrusted content — an agent working on confidential data does not read arbitrary external input. If it must, hostile content is treated as such: quarantine, separate contexts, a "dirty" agent that reads and a "clean" agent that acts, with no way for the former's instructions to reach the latter.
- Remove autonomous output — outbound actions (sending, publishing, committing) require human approval or go through an allow-list of destinations. Exfiltration fails if the outbound pipe has a tap the agent does not control.
The operational rule that follows is a single one: never all three sides in the same session. It is an architectural property, verifiable on paper — not a hope about the model's behaviour.
The framework to apply on Monday morning
The practical value of the trifecta is that it turns a complex security assessment into three questions anyone can ask, for every agent in the company:
- Which confidential data does it access?
- Can it read content we do not control?
- Can it write, send or publish externally?
Three yeses = complete triangle = redesign, before the ignition arrives. Two or fewer = the risk is manageable with ordinary controls. You do not need a red team for this screening: you need to actually do it, on every agent, every time a tool is added.
Second article in the agentic security series. The first: the AI agent as a privileged account. Next and last: if the perimeter does not hold at the agent level, authorisation must move to the data — data-centric security in the agentic era.
Sources
How many complete triangles are in your agents?
Tomato applies the trifecta framework to SME agentic deployments: mapping data, inputs and outbound channels for every agent, and redesigning flows where the triangle closes.
Talk to us →