Drawn from a pooled corpus of production agent telemetry, nearly 28,000 sessions across 200+ endpoints.
Part two of two: signals that don’t survive production.
TL;DR
The label is universal. Across nearly 28,000 production agent sessions, 99% of the agents we observe run on platforms whose default toolset already spans all three trifecta legs (untrusted input, sensitive data, external egress).
Normal work exercises the full trifecta. Roughly one substantive session in four runs all three legs in a single pass, and every one we inspected was sanctioned work.
As a detection rule it is pure noise. A literal in-session trifecta rule works out to roughly 3,000 benign alerts a day at 10,000 endpoints, with zero true positives observed.
Replace the trifecta label with something more meaningful. The expected shape of an agent is learnable. Same-type agents' capability sets are 3.5× more similar than cross-type. Measure blast radius, exposure, and defensive controls, baseline each agent's behavior over time, and alert on what breaks from the pattern.
The second signal that doesn't survive production
In the first part of this series we ran intent drift against production traffic and watched it fall apart: applied as a literal, session-level rule, it drowns a SOC in false positives while surfacing almost nothing real. This piece turns to the other signal that dominates the agentic-security conversation: the lethal trifecta. It is intuitive, makes for a compelling slide, and when you take it out of the threat-modeling whiteboard and run it against real production traffic, it generates so much noise that it can do more harm than good.
The numbers below come from the same pooled research corpus: capability graphs and runtime event streams spanning nearly 28,000 sessions across 200+ endpoints and close to 7,000 endpoint-days of production activity. What that data shows is that the raw trifecta, applied as a risk-posture label or as a detection rule, is counterproductive at enterprise scale. It misdirects risk-management attention, floods security operations with false positives, and pushes organizations toward decisions that hurt the business without reducing risk.
As with intent drift, we believe the concept itself is worth keeping. The threat model at its core is real. The argument here is for the rigor that has to sit on top of it before it belongs anywhere near posture management or detection and response.
The lethal trifecta: terrifying on a slide and behind every agent
The lethal trifecta, a framing popularized by Simon Willison, describes the dangerous combination that arises when an agent simultaneously has three capabilities; access to untrusted input, access to sensitive internal data or the ability to make state changes, and an external channel through which data can leave. An agent that can read something an attacker controls, touch something sensitive, and then phone home is, in the abstract, a nightmare.
We often see it framed in two places: as a risk-posture label (does this agent's configuration create the combination?) and as a detection signal (was the combination exercised in a session?).
But let’s consider a common, and entirely benign use-case which matches these criteria. Picture a marketing analyst agent. It reads LinkedIn posts and news sources (that’s untrusted external input). It checks internal customer databases to see which findings matter to which accounts (that's sensitive internal data). It drafts a brief and posts it to Slack, or publishes to LinkedIn (that’s an external channel and a state change). Congratulations, you have just described a textbook lethal trifecta. It is also a legitimate, valuable, sanctioned workflow that exists in some form at most organizations.
Run the criteria against real environments and the finding is not "here are the few dangerous agents." It is that nearly every agent qualifies. Classifying every tool and MCP server in the pool into the three legs and the number is stark: 99% of observed agents run on platforms whose default toolset already spans all three. In our research and testing it wasn’t an artifact of one dominant environment.The trifecta is everywhere the moment you deploy broadly across any environment, because the three capabilities it names are the same three that make agents useful in the first place.
The standard remediation advice is to break the trifecta by removing a leg. Meta has formalized this as the Agents Rule of Two: an agent should satisfy at most two of the three properties within a session, and if the job requires all three, a human approves the consequential actions. It is a sensible engineering default for building a single agent. At enterprise scale it collides with the business.
Tell the owner of that marketing agent that it can no longer read external sources, or reach customer data, or publish, or that every run now waits on a human approval, and the response is predictable: then what is the agent for? That is not risk management. It is a checkbox that, applied to a label fitting nearly everything, shuts down the value of the entire agent program. More importantly, it gets the security team removed from the conversation.
The lethal trifecta fails as a detection signal for the same reason
If the risk-posture version is too blunt, the tempting fix is to narrow it; ignore the static configuration and alert only when the three elements of the trifecta are exercised within a single session. This doesn't hold either. Counting any attacker-influenceable content as untrusted input, which is what the threat model actually means (email, tickets, wiki pages, shared docs), about one substantive session in four exercises the full trifecta in a single run. Every such session we inspected was sanctioned work.
An ordinary morning of a developer does it in one pass. First thing, they have the agent pull up an external write-up relevant to the day's work: that’s untrusted input. The agent then scans the internal codebase to see whether the lesson applies: that’s sensitive data. And why would the developer start a fresh session? Nobody starts a fresh session mid-flow; the accumulated context is where the leverage is. So finally, they let it open pull requests with the fixes: that’s state changes. That’s the full lethal trifecta, inside one session, in a typical morning of work.
If we were to alert on that pattern it becomes pretty brutal with: roughly 3,000 benign alerts a day at 10,000 endpoints, and zero true positives observed. The economics don't change just because the signal has a scarier name.
Above: Capability figure dominated by one large fleet; exceeding it: 75%. Usage figures are lower bounds.
Above: Benign-alert volume vs. fleet size, extrapolated from observed rates.
Want visibility into what your coding agents are actually doing at runtime? Talk to Manifold.
What to actually do; rigor on top of the intuition
Throwing the trifecta away would be an overreaction. It asks a real question - does this agent hold the dangerous combination? The failure is not in the question, but in stopping at the binary classification and shipping it as a feature. The work is in what you build on top.
For risk posture: profile the composition, or better, measure criticality
If the trifecta stays in your posture model at all, stop treating "has a trifecta" as a verdict and start reading its composition: what specifically makes it up, what risk that particular mix creates, and whether it is necessary and acceptable for the agent's job. A marketing agent's trifecta should look like LinkedIn, a CRM, Slack, and common research tools. That is the sanctioned shape of its risk. If that same agent picks up an accounting MCP server one day, you finally have a question worth asking: why does a marketing agent have accounting access? That departure is meaningful in a way "this agent has a trifecta" never was.
This is learnable, not hand-wavy. Across the pool, same-type agents' capability sets are about 3.5 times more similar to one another than to agents of other types, a mean overlap of 0.30 within a role versus 0.09 across roles. The expected composition of a role can be baselined, and departures from it are rare and specific, which is exactly what makes them worth an alert.
We at Manifold would push even further. Our stronger recommendation is to largely retire the lethal trifecta as the primary risk-posture lens and replace it with a richer measure: the agent's criticality, built from three properties you can actually measure.
Blast radius: the data and systems the agent has been given access to, and the nature of that access (read, write, execute, delete). If this agent is compromised or misbehaves, how much can it touch, and how badly?
Exposure: the agent's attack surface. Every tool is not just a capability but an input path back into the agent, and therefore an injection path, and the supply chain behind those tools carries its own vulnerabilities. A known flaw in a popular MCP server is a route to every agent that loads it.
Defensive controls: what contains the agent. Its autonomy level, whether it is sandboxed or isolated, and the access, containment, and governance policies enforced against it.
Exposure is also where the binary label fails in the other direction. An agent holding only two legs can still hurt you, because a sanctioned tool is an exit. An agent with the GitHub CLI can post internal data as an issue on a public repository; an agent with LinkedIn access can message it to a stranger. To a trifecta checkbox, a CLI call to a private repo and one to a public repo are the same "external channel." Measuring exposure tool by tool is what tells them apart.
"High criticality because of a large blast radius, wide exposure, and weak controls" tells you what to fix and why. "High risk because it has a trifecta" tells you almost nothing, because it is true of nearly everything. Independent frameworks now score agent products on similar axes, from public evidence about default configurations. A deployed agent is not its default configuration. We would vote for criticality measured per deployed agent, from runtime telemetry, so the score moves the moment the actual toolset does. If the trifecta is to stay, measure it the same way, and read its shape against the job the agent is supposed to do. A generic trifecta label will not help you in any meaningful way.
For threat detection: baseline behavior, not the presence of a pattern
The detection story rhymes with the posture story. You want something more nuanced than "a lethal trifecta occurred during this session." What you actually want is to profile the normal behavioral patterns of an agent and of the user's use of that agent, and then look for anomalies against that baseline. An agent that starts running its usual tools in a sequence it has never used before, or works through them at an unusual time, against a traffic pattern that looks like bulk export rather than daily work, is a finding. Nothing in its toolset changed; its behavior did, and that is exactly what composition monitoring alone would miss. An agent exercising the same trifecta it exercises every day is not a finding, it’s just doing its job.
The bottom line
The lethal trifecta was born from good instincts, and at the theoretical level it belongs in any serious conversation about agentic risk. But intuition is not a control. Applied naively, it shatters against how agents are actually used: trifecta-shaped activity is the normal texture of legitimate work, the label lands on nearly every agent you deploy, and the resulting flood of benign alerts consumes exactly the analyst capacity you need for the signals that matter.
The harder work is worth doing: measure agent criticality through blast radius, exposure, and defensive controls rather than a one-size-fits-all label, and baseline agent and user behavior over time rather than firing on a pattern present in nearly every benign session. Taken together with part one, the lesson is the same for both signals. Intent drift and the lethal trifecta are useful ways to think about agentic risk and poor ways to police it. The intuition behind each is worth keeping. The naive implementation is worth leaving on the whiteboard where it was born.
Want to see what your coding agents are actually doing, and the detection and response to secure your agentic operations? That's what Manifold is built for. Talk to Manifold.
Latest articles
