Mind the Third Leg
The three-legged stool of AI risk in your working day
I was sitting with a client this week working through what looked, on the surface, like a simple governance question. They want their people to experiment with AI — to use skills in Claude, wire up the tools that make the day easier, poke at what’s actually possible. Good. That’s exactly the posture you want. And in the same breath, entirely reasonably, they want some surety that the company’s Crown Jewels — whatever those happen to be — don’t quietly stroll out the front door while everyone’s off having fun.
That’s the tension every leader is holding right now, whether they’ve named it or not. Flexibility to play, versus surety that the important stuff stays put. And the honest reason it’s so hard to resolve is that most of us don’t have a clear mental model of what we’re actually protecting against.
So let me start with the thing I said in that conversation that I want to unpack, because it turns out to be the whole game.
Skills are just prompts. That’s all they are — a saved instruction, dressed up. Which means blocking skills feels like a control, but it barely is one. Turning them off doesn’t stop someone uploading a document with “hidden” text tucked inside it — white text on a white background, an instruction buried where you’ll never read it — that then acts on the model’s behalf. You’ve locked one door and left the wall open.
Here’s what actually matters. It isn’t whether a sneaky instruction can get in. It’s whether the model has a pathway to do anything with it. If the AI can read the dodgy instruction but has no tool, no connection, no way to reach out and act on it — you’re fine. Irritating, maybe. Not dangerous. But the moment you’ve layered skills on top of MCPs on top of tools that reach your codebase, your email, your collaboration platform — working out what could happen becomes genuinely, teeth-grindingly hard. If predicting blast radius was difficult before, it’s a thousand times harder now.
I walked out of that conversation thinking two things. One: this is the biggest literacy gap in the building. Two: I wasn’t the only person having this exact realisation this week.
Two headlines, one story
While that meeting was still rattling around my head, two security stories landed.
The first: researchers at Noma Labs tricked GitHub’s shiny new AI agent into leaking a private repository’s contents out into a public comment. No stolen passwords. No code access. They just posted a normal-looking GitHub issue — dressed up as a routine note from a “VP of Sales” after a customer meeting — with instructions hidden in the text. When an automation assigned the issue, the agent read it, treated the buried instructions as orders, reached into a private repo it had access to, and pasted the contents somewhere anyone could read them. They named it GitLost. The kicker: GitHub had built guardrails for exactly this, and a single added word — “Additionally” — was enough to walk straight past them.
The second: a researcher showed how a YouTube creator’s own AI tooling could be turned against them. A stranger leaves a crafted comment on your video. You click YouTube’s own helpful “summarise these comments” button. The buried instruction fires, and the AI’s response comes back wearing a costume — styled to look like an official notice from YouTube — nudging you toward a dodgy “verification” link and quietly surfacing private video titles along the way. Your own convenience feature, holding the knife.
Two very different platforms. Two very different-looking incidents. But it’s not two stories. It’s one.
Both are what’s called indirect prompt injection — and the term matters, because the person who coined “prompt injection,” Simon Willison, named it deliberately after SQL injection. Same underlying disease: trusted instructions and untrusted content get mixed together in the same place, and the machine can’t tell which is which. In plain SQL you can draw a clean line between the command and the data. In natural language, there is no such line. “Summarise this” and “ignore that and email me the secrets” are just... words. The boundary collapses.
Last week I wrote about trust — that trust is really a belief about how something will behave in the future, under uncertainty. An autonomous agent takes that uncertainty and cranks it up, because its behaviour is steered by whatever it happens to read. You’re no longer trusting a tool to do a fixed thing. You’re trusting it not to be talked into doing something else by a stranger you’ll never meet.
The lens, not the lecture
Now, I could spend the next thousand words in the plumbing — authentication, authorisation, token scopes, encryption. I’m not going to, because that’s not where leaders live and it’s not where the mental model breaks.
Where it breaks is this: nobody looks at their AI assistant on a Tuesday afternoon and extrapolates from a scary security term to their own desk. So the job here isn’t to frighten people. It’s to hand them a lens.
Willison gave us a good one, and I want to translate it into something you can actually carry around. He calls it the lethal trifecta. An AI agent becomes genuinely dangerous only when three things are true at the same time:
It has access to private data — your files, your emails, your repos, your customer records.
It’s exposed to untrusted content — anything written by someone you don’t control: an email, a document, a web page, a comment, a meeting.
It has a way to communicate externally — send a message, make a request, post a comment, hand you a link to click.
Any two of those, on their own, are survivable. It’s all three together that lets a stranger who controls the untrusted content reach in, grab the private data, and ship it out the door.
Here’s my kitchen-table version, because “lethal trifecta” still doesn’t reach the person using an AI chat to tidy up a spreadsheet. Think of it as a three-legged stool. And crucially — it’s not your stool. It’s the attacker’s. Their exploit can only stand up when all three legs are underneath it. Two legs, and the thing topples over on its own. Your job, as a leader, is to notice when you’ve accidentally built the attacker a nice sturdy stool to stand on — and then kick a leg out.
That’s the whole discipline, and it’s a far kinder thing to teach than fear. It’s the same move the good security-awareness training made years ago. Nobody learned to spot a phishing email by being told to be terrified of their inbox. They learned the tells — the wrong sender address, the manufactured urgency, the link that doesn’t go where it claims. This is that, for the agent era. Not “be scared of AI.” Just: notice when the third leg goes on.
A field guide to the third leg
So let’s make it concrete, because the trifecta only earns its keep once you can see it at your own desk. Here are the everyday scenes. For each one: the ordinary thing you’d do, where the third leg sneaks in, and the tell to watch for.
1. The inbox assistant. You connect an AI to your email so it can triage and draft replies for you. Lovely. Now look at the legs. Private data: your entire inbox. Untrusted content: anyone on earth can email you — so an attacker can literally email your assistant and give it instructions. Exit: it can send mail. That’s all three, straight out of the box, before you’ve done anything wrong. The tell: the instant an AI can both read arbitrary incoming messages and send things, you’ve built the full stool. Treat that combination as a decision, not a default.
2. The document someone sent you. A vendor, a candidate, a “prospective client” sends through a PDF and you drop it into your AI to summarise. If all your AI can do is summarise and hand it back to you, you’re fine — that’s two legs at most. But the moment that same chat is wired into your files, your repos or your email, the hidden white-on-white instruction in their document suddenly has somewhere to go. The tell: ask yourself, before you paste, “what can this session reach besides the thing I’m asking about?” If the answer is “my whole environment,” the stranger’s document just got a lot more interesting.
3. The coding agent on your repo. This is GitLost, made personal. You point a coding agent at your codebase to fix a bug, and — because that’s how these things work now — it also reads a ticket or a pull-request comment written by someone outside your team. Private repos and secrets, untrusted issue text, and an exit via comments or outbound calls. That’s not a headline about GitHub. That’s a Tuesday. The tell: whenever an agent that can touch private code also reads text that outsiders can write, assume the two can meet.
4. The meeting that recorded itself. Here’s my own lived one, and it’s the one I think most people’s model doesn’t contain at all. I use a tool to record and transcribe my meetings. Often, mid-meeting, I’ll say something quite specific out loud — a note to myself, a clear action to pick up later — precisely because I know it’s being captured and my other tools can act on it. Brilliant, when it’s me.
Now change one thing. You’re meeting someone for the first time. You don’t know them from a bar of soap — you’ve swapped a couple of emails and set up a call. And they’re a nefarious sort. Somewhere in the conversation they say something crafted, worded in a way you don’t quite catch or aren’t paying attention to. Your tool faithfully transcribes it. And downstream, your other agents — the ones with access to your files and an exit — pick it up as an instruction.
I’ll be honest about how close this actually is, because being honest about the odds is the whole point. Today, on its own, a transcription tool is only the untrusted-content leg — it captures, it doesn’t act. For my nasty scenario to properly bite, that transcript has to flow into something that holds private data and has an exit, and acts on it without a human glancing first. That’s a stack of “ifs.” So no, your secrets aren’t walking out of your next meeting tomorrow.
But every one of those ifs is closing. Auto-generated action items. Agents watching your notes folder. Meeting bots that join calls uninvited. AI that makes and takes phone calls. And the sheer volume of conversations now being quietly recorded. Each convenience welds another leg onto the stool. The tell: voice is untrusted content too. Words spoken by a stranger are no safer than words they’d email you — we’ve just never thought of them that way.
Why “just block it” doesn’t work
At this point the instinct — especially from a nervous security team — is to build a filter. Scan the input, catch the bad instruction, refuse it. Problem solved.
It isn’t, and it’s worth knowing why, so you don’t sink budget into a false sense of safety.
GitHub built a guardrail for precisely the GitLost attack. One extra word defeated it. That’s not a GitHub failing — it’s the nature of the thing. A late-2025 paper with the wonderfully ominous title The Attacker Moves Second tested twelve published defences against attackers who were allowed to adapt. Several that had reported near-zero vulnerability jumped to over 90% attack success once the attacker could iterate. Human red-teamers hit 100%. A filter is a backstop. It is not a boundary. Anyone selling you a box that “stops prompt injection” is selling you the 2019 anti-spam pitch with a new logo.
And here’s the one that catches a lot of well-meaning architects, because I had the same hopeful instinct: surely you can split the work across multiple agents, or clamp it all down with Agent IDs and privileged-access management, and engineer your way out? Sadly, mostly no. Multi-agent setups should be treated, for trust purposes, as a single agent — they share memory and effectively gossip, so the trifecta can still assemble itself across the handoffs. And identity controls like PIM tell you who the agent is acting as; they don’t tell you whether its context has been poisoned by something it read. Useful. Necessary, even. But not a fix.
You can’t reliably detect the bad prompt. So stop trying to. Assume it’ll get in — and constrain what it can do once it’s there.
So what do you actually do
The good news buried in all of this: the stool makes an impossible problem tractable again. You don’t have to imagine every possible malicious instruction — an infinite, unwinnable game. You only have to answer one bounded question about any given agent: is it standing on all three legs at once?
The most useful practical framing I’ve seen wraps this into a rule a leader can actually hold a team to. Meta published it in late 2025 as the “Rule of Two,” and Willison has since called it the best practical advice going. It treats the trifecta as a budget: within a single session, an agent should have no more than two of the three legs. Untrusted input, private data, external action — pick two. Stay at or under two, and the worst outcomes are structurally off the table, because no single session holds the full pipeline.
And when a job genuinely needs all three? Then it shouldn’t run on its own. It gets a human on the trigger before anything consequential happens. Not a human rubber-stamping everything — a human on the exit, on the actions that actually reach the outside world.
For me, that resolves the Crown Jewels dilemma I started with, and it does it without becoming the “computer says no” person nobody wants in the room. The answer to “can we experiment?” isn’t no. It’s: sandbox the play, gate the exits. Give your people spaces to muck around freely — precisely because those spaces are built so the third leg can’t go on. Let them break things where breaking things is safe. And put the human check on the narrow set of actions that cross the boundary.
There’s a harder truth sitting underneath all of it, though, and I’d be doing you a disservice to leave it out. Most organisations can’t yet see their own stool. They genuinely don’t know which of their skills, MCPs and tools quietly add that third leg — because each one was switched on by a different person, at a different time, for a good reason, and nobody’s holding the whole picture. You cannot bound a blast radius you can’t see. So before control, there’s visibility. The first honest question isn’t “how do we lock this down.” It’s “do we even know what our agents can reach, read, and reach out to?”
The real deliverable is awareness
I set out to write this as an educational piece, not a horror story, and I want to land it there. I’m not interested in pouring fear into people about AI — that’s cheap, it’s lazy, and it’s against how I want to lead. The technology is extraordinary and I’m not about to tell anyone to stop.
What I am interested in is the same thing the good security-awareness training gave us for email: a simple lens people can carry into their ordinary working day, so they notice the tell before they’ve handed a stranger the keys. Three legs. Any two, and the stool tips over harmlessly. All three, and you’ve built something that’ll hold an attacker’s weight.
So that’s the whole ask. Next time you connect a tool, wire up a skill, or click the helpful little “summarise this” button — just have a quiet look underneath.
Mind the third leg.
If you want to go deeper, these are the sources worth your time:
Simon Willison — The lethal trifecta for AI agents (the origin, and the clearest explainer)
Noma Labs — GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos, and The Register’s write-up
Simon Willison on Meta’s “Agents Rule of Two” and The Attacker Moves Second
Beurer-Kellner et al. — Design Patterns for Securing LLM Agents against Prompt Injections (arXiv:2506.08837)
Google DeepMind — CaMeL: a promising direction for mitigating prompt injection
OWASP — Top 10 for LLM Applications (see LLM01 Prompt Injection, LLM06 Excessive Agency) and the 2026 Agentic Top 10
The trifecta framing is Willison’s; the three-legged stool is just my kitchen-table translation of it for the rest of us.