Wes Ellis./ a personal notebook
Technology. Stories. Side projects.
A few things worth writing down.
← Back to G8KEPR

G8KEPR

The Lethal Trifecta and Other Attacks That Take More Than One Step

Part 16 of the thread Building G8KEPR

THE SHORT VERSION4 points
  • A compound attack is made of several steps that each look fine on their own.
  • The lethal trifecta is an agent with access to private data, exposure to untrusted content, and a way to send data out. Any two are manageable. All three together are dangerous.
  • The pieces of an attack like this show up at different checkpoints, so a tool watching only one of them tends to miss the shape.
  • That's the job of G8KEPR's correlation engine: match multi-step patterns across API, MCP, gateway and model output.

Most security tools are built to answer one question about one thing. Is this request malicious? Is this file bad? Is this login suspicious? That works when an attack is a single obvious act.

A lot of AI attacks aren't. They're a sequence of ordinary-looking steps, and the danger is in the combination. This post is about that idea, and about why it's the reason G8KEPR exists in its current form.

The lethal trifecta

The clearest way into this is a term the developer and writer Simon Willison coined in 2025: the lethal trifecta. It describes an AI agent that has three things at once:

  1. Access to private data. It can read your files, your inbox, your customer records, your internal wiki.
  2. Exposure to untrusted content. It reads things from outside: web pages, incoming emails, documents someone uploaded, results from tools you don't control.
  3. A way to send data out. It can make a web request, send a message, write to somewhere an outsider can see.

Each of those is normal. They're what make agents useful. An assistant that can read your documents is handy. One that can browse the web is handy. One that can send an email for you is handy.

The trouble is all three together. Remember from the prompt injection post that a model can't reliably tell your instructions apart from instructions hidden in something it reads. So picture an agent that reads a web page containing text written for it. That text tells it to go find something private, then send it somewhere. The agent has the access to find it and the means to send it. Nobody typed anything malicious into your app. The user just asked for a summary.

Take away any one leg and that particular story falls apart. That's what makes the framing so useful. It turns a vague worry into a question you can actually ask of any agent you build: does this thing have all three?

Other compound patterns

The trifecta is the best-known example, but it isn't the only shape. G8KEPR's correlation engine matches a handful of named multi-step patterns. A couple of others, described in general terms:

  • Credential exfiltration chains. A sequence where access credentials get gathered in one step and carried out in another, with neither step looking alarming in isolation.
  • Shadow egress. Data leaving through a route nobody intended to be an exit, which is easy to miss when every individual call looks routine.

I'm deliberately not going into how any of these are recognized. Explaining the tripwires in detail mostly helps the people trying to step over them.

Why one checkpoint can't see it

Here's the practical problem. The pieces of a compound attack don't show up in the same place.

The untrusted content might arrive through a tool call, which is the MCP pillar's territory. The instruction hidden in it passes through the model request, which is the AI Gateway's. The private data gets touched through your API, which is the API Security pillar's. And what the model says or does as a result is on the output side, where the Verification Engine sits.

A product that only watches one of those places sees one slightly odd event. Maybe it flags it, maybe it doesn't. Either way it can't see that this event is step two of four. Four separate products watching four places each see their own slice, and nothing connects them.

What the correlation engine does

This is the part of G8KEPR I narrowed the whole company down to, as I wrote in From Do-Everything Platform to Correlation Engine. All four pillars sit on the same request path inside your VPC, and the correlation engine looks at their signals together. When signals from different checkpoints line up into one of those known multi-step shapes, that's treated very differently from any single signal on its own.

The MCP pillar helps here too. Session-level tracking means steps that belong to the same session can be connected, rather than judged one call at a time. More on that in Agents That Turn on You.

A question worth asking

You don't need G8KEPR to use the trifecta idea. If you're building or buying an AI agent, list what it can read, where outside content comes into it, and how it can send anything out. If the answer is yes, yes and yes, that's a design conversation worth having before it ships, not after.

That's the plain version of what I'm building toward: seeing the whole sequence instead of one step at a time.