Breaking the Lethal Trifecta (Without Ruining Your Agents)

Breaking the Lethal Trifecta (Without Ruining Your Agents)

Speaker: Andrew Bullen, Head of AI Security, Stripe

Conference: [un]prompted 2026 — The AI Security Practitioner Conference

Date: March 4, 2026, San Francisco

Watch: YouTube — Full Talk

Reading time: ~8 min

TL;DR

Prompt injection is not a future problem — it is happening now, and most companies are ignoring it. Andrew Bullen, Head of AI Security at Stripe, argues that the only viable strategy is to assume prompt injection will succeed and architect your agents so that when it does, the damage is contained. His talk walks through the specific controls Stripe has built, the friction they cause, and the engineering work required to make those controls actually adoptable.

Introduction

There is an elephant in the room in almost every AI conversation happening in enterprise security right now. Prompt injection is real, it is underappreciated, and it is inconvenient — which is exactly why so many companies are quietly hoping it won't become their problem.

Andrew Bullen, who has spent ten years at Stripe and now leads its AI security team, opened his [un]prompted 2026 talk with a candid admission: "I've been surprised at how many experienced AI developers, startup founders, and tech executives I talk to have only a vague understanding of what prompt injection is." The AI hype cycle has pushed companies back into a move-fast-and-break-things mode, and in that environment, considering prompt injection risk is treated as a productivity tax rather than a baseline responsibility.

Bullen's framing is deliberately pragmatic. His talk is not about an elegant technical fix. It is a security leadership talk — one that covers the threat model, proposes specific mitigations, and spends most of its time on the harder question: how do you actually get those mitigations implemented in a way that the business can live with?

▶ Watch: The elephant in the room (00:00)

The Lethal Trifecta and Why You Can't Eliminate Two of Its Three Legs

The concept of the "lethal trifecta" — a term Bullen attributes to Simon Willison — describes the convergence of three conditions that make prompt injection dangerous in agentic systems:

1. Access to private data (support tickets, emails, internal documents)
2. Exposure to untrusted external content (web pages, customer messages, third-party data)
3. The ability to exfiltrate data or take sensitive external actions

When all three are present, a single successful prompt injection can lead to data theft or unauthorized high-impact actions. The intuitive response is to try to eliminate one of the three legs. But Bullen walks through why two of those legs are effectively non-negotiable.

Eliminating untrusted content is not viable. A core reason LLMs are useful in the first place is that you can throw arbitrary content at them and they figure out what to do. Attackers have also become creative at hiding injections in places you wouldn't think to look — image metadata, whitespace, encoded text. You cannot reliably sanitize your way to safety.

Eliminating access to private data is similarly impractical for most real-world agent deployments. At Stripe, agents need to see support tickets, emails, and sensitive operational data to be useful. Restricting that access defeats the purpose.

That leaves only the third leg: egress and sensitive actions. Bullen's entire defensive strategy is built around controlling what a compromised agent can actually do once it has been injected.

▶ Watch: Why only one leg can be controlled (04:00)

Guardrail 1: Controlled Egress

Stripe's first architectural control is preventing agents from making arbitrary outbound HTTP requests. The rationale is simple: if a compromised agent cannot communicate with the outside world, it cannot exfiltrate data regardless of what instructions it has been given.

The common objection Bullen hears from engineering teams is: "But we need agents that can do research — they need internet access." His reframe is key: what teams actually need is the ability to retrieve data from the internet. That is not the same as the ability to make arbitrary HTTP requests.

Stripe's solution is a safe search tool built on top of OpenAI's search API. The critical implementation detail: OpenAI's web search offers an external_web_access: false setting that serves results from cache without the agent making outbound requests from Stripe's infrastructure. As Bullen acknowledges, "Technically the data still gets egressed via OpenAI rather than your agent, which isn't a perfect solution, but it's meaningfully better."

The second egress vector is SaaS integrations. Teams reasonably trust their SaaS tools — but the risk is not the SaaS provider itself, it is an agent writing data to a tenant outside your organization. A compromised agent could write sensitive data to a public Google Doc rather than a Stripe-owned one.

Stripe's approach here is a central MCP server called Toolshed. Rather than agents connecting directly to third-party SaaS tools, all connections are proxied through Toolshed, which enforces rules like: do not allow writes to Google Docs tenants that are not Stripe. A secondary benefit: employees only need to connect to one MCP server, which simplifies their setup.

▶ Watch: Safe search and SaaS proxying (08:00)

Guardrail 2: Human Review of Sensitive Actions

The second major risk category — beyond data exfiltration — is a compromised agent taking damaging actions: sending mass communications, making production writes, or triggering external workflows.

Bullen's "lethal bifecta" for this risk mirrors the trifecta: untrusted content plus the ability to take sensitive actions without requiring human approval. Since you can't eliminate untrusted content, the control is requiring human confirmation for sensitive actions.

"Sensitive" is defined by three criteria: production-impacting writes, broadcasts to large audiences, and communications with external parties.

The problem is that naively implemented human-in-the-loop flows are genuinely terrible experiences — which drives users to bypass them entirely. Bullen describes the experience of using Claude Code for the first time: "It's constantly asking, 'Can I do this? Can I do this? Can I do this?' And you really start trying to find where in the settings you can enable dangerously skip permissions."

Three specific failure modes for confirmation flows:

1. Interruption — stopping the agent in its tracks while it waits for human approval defeats the point of having an agent
2. Review fatigue — humans asked to confirm constantly will eventually rubber-stamp anything
3. Rubber stamping — once review fatigue sets in, the human-in-the-loop becomes security theater

Stripe's solutions to these problems:

• Batching confirmations — many writes don't need to happen instantly. Let them queue up, and let the human handle the queue when convenient rather than stopping the agent mid-task.
• Optimistic writes with reverts — rather than blocking the agent, let it proceed with the write but preserve the ability to revert. This eliminates interruption while still preventing irreversible harm.
• LLM-as-second-reviewer — for routine approvals, use a secondary LLM to evaluate whether the action is clearly benign, only escalating genuinely suspicious cases to humans.

▶ Watch: Solving confirmation fatigue (10:00)

Enforcement at Scale: Making Guardrails Stick

Building guardrails is one problem. Making them stick across dozens of engineering teams writing agents in different frameworks is another.

For egress, Stripe leverages Smokescreen, an open-source egress control tool that predates their AI agent program. The approach: tag every service that talks to foundation models as an "AI agent" (this is easy because you can use whether a service calls Bedrock or the equivalent as a signal), then use CI checks to enforce that tagged services cannot configure egress to arbitrary destinations without going through an escalated review process.

For sensitive action controls, Stripe requires annotations on every MCP tool — human-readable properties like "production impacting write" or "broadcast data internally." The annotation system automatically determines whether a tool needs a human-in-the-loop trigger. Centralizing this through a framework means there is one consistent UX for handling reviews, which can be improved over time rather than reinvented per-team.

A complication is emerging: agents increasingly don't need purpose-built tools. They write their own code and call arbitrary internal APIs directly. Stripe is currently working on a response to this — proxying outbound connections from agent sandboxes and using API endpoint annotations as a choke point for the same kind of sensitivity classification.

▶ Watch: CI enforcement and tool annotations (12:01)

Notable Quotes

"I've been surprised at how many experienced AI developers, startup founders, and tech executives I talk to have only a vague understanding of what prompt injection is. Prompt injection is a really inconvenient risk." — ▶ 02:00

"Even a 0.1% failure rate is not acceptable in security contexts. We need something better than just relying on the models." — ▶ 02:00

"Security isn't just about figuring out the secure way to do things. It's about helping your organization figure out how to accomplish their goals in a secure way." — ▶ 16:01

"You just start trying to find where in the settings you can enable dangerously skip permissions." — ▶ 08:00

Key Takeaways

• Assume prompt injection will happen. Models are improving but even a 0.1% failure rate is unacceptable in security contexts. The only viable strategy is limiting what a compromised agent can do, not preventing injection itself.
• Focus on the one controllable leg of the lethal trifecta: egress. You cannot realistically eliminate untrusted content or private data access from most production agents. Controlling outbound communication is where defense is actually feasible.
• Guardrails must be usable or they will be bypassed. Safe search tools, SaaS proxying, batched confirmations, and optimistic writes with reverts are not niceties — they are what makes security controls actually get adopted.
• Use CI-time enforcement. Tagging agentic services and requiring egress reviews at compile time catches problems before deployment rather than after.
• Security engineering has three steps, not two. Threat model, mitigation, and then the hard work: figuring out how to implement the mitigation in a way the business can still operate.

Slides Reference

Slides are available from the conference as 2026-04-04-D2-S1-11-17-Breaking-the-Lethal-Trifecta-Without-R.pdf. Key slides cover the lethal trifecta framework, the two guardrails (egress prevention and sensitive action review), the pain points each guardrail introduces, and the enforcement mechanisms (Smokescreen, tool annotations, CI checks, Toolshed proxy).