Defending Against the Lethal Trifecta: An Agent Architecture That Survives Prompt Injection

How do I detect when an agent holds all three legs?

Make the trifecta a first-class property of your agent runtime, not a thing you reason about in your head. I tag every tool with the legs it grants, then compute the active set per task and refuse to proceed if all three light up without an explicit approval gate.

In practice I attach metadata to each tool and check it at plan time and again before every call.

from enum import Flag, auto

class Cap(Flag):
    NONE = 0
    PRIVATE_DATA = auto()       # reads sensitive internal data
    UNTRUSTED_INPUT = auto()    # ingests attacker-controllable content
    EXTERNAL_COMM = auto()      # can send data outside the trust boundary

TOOL_CAPS = {
    "read_customer_record": Cap.PRIVATE_DATA,
    "fetch_url":            Cap.UNTRUSTED_INPUT | Cap.EXTERNAL_COMM,
    "read_support_ticket":  Cap.UNTRUSTED_INPUT,
    "send_email":           Cap.EXTERNAL_COMM,
    "search_internal_kb":   Cap.PRIVATE_DATA,
}

TRIFECTA = Cap.PRIVATE_DATA | Cap.UNTRUSTED_INPUT | Cap.EXTERNAL_COMM

def active_caps(used_tools: set[str]) -> Cap:
    caps = Cap.NONE
    for t in used_tools:
        caps |= TOOL_CAPS.get(t, Cap.EXTERNAL_COMM)  # unknown tools assumed dangerous
    return caps

def trifecta_present(used_tools: set[str]) -> bool:
    return (active_caps(used_tools) & TRIFECTA) == TRIFECTA

Two details that matter. First, an unknown tool defaults to the most dangerous capability, so adding a tool without classifying it fails closed. Second, fetch_url carries two legs at once, which is why arbitrary web fetch is one of the most dangerous tools you can hand an agent: it ingests untrusted content and provides an exit channel in a single call.

I run this check at the moment the agent commits to a tool call, with the running set of tools it has already used in the task. If a call would complete the trifecta, the runtime blocks and escalates.

def guard_call(tool_name, used_tools, approve_fn):
    prospective = used_tools | {tool_name}
    if trifecta_present(prospective):
        if not approve_fn(tool_name, prospective):
            raise PermissionError(
                f"Blocked: '{tool_name}' completes the lethal trifecta "
                f"for active caps {active_caps(prospective)!r}"
            )
    return True

How do I break the trifecta with capability scoping?

The cleanest fix is to make sure a single agent context never needs all three legs, by splitting work into scoped sub-agents that each hold at most two. This is the architecture-layer move that input filters can never give you.

The pattern I reach for most is the dual-agent split, sometimes called a quarantined or planner/executor design:

• A reader agent has untrusted-input access and no private data and no egress. It reads the poisoned web page or ticket and returns only structured, schema-validated fields. Even if it is fully hijacked, it has nothing to steal and nowhere to send it.


• An actor agent has private data and a tightly scoped egress channel, but it never sees raw untrusted content, only the validated structured output of the reader.

When a true split is not practical, I scope per task instead: the agent gets private-data tools or web-fetch tools for a given run, never both, chosen by the task router before execution begins.

How do egress allow-lists and human-in-the-loop close the gap?

Egress allow-lists and approval gates are the two controls that break the external-communication leg, and I treat them as the last line when scoping alone is not enough. An allow-list makes "send data out" mean "send to these exact destinations," and a human gate makes the riskiest actions require a person.

For egress, I default-deny all outbound network and enumerate the few destinations a task legitimately needs. This neutralizes the classic exfiltration trick where an injection tells the agent to fetch https://attacker.com/?data=.

## egress policy for the actor agent
egress:
  default: deny
  allow:
    - host: api.stripe.com
      methods: [POST]
    - host: hooks.slack.com
      path_prefix: /services/T0000/
  block_data_urls: true   # no leaking via image/query-param side channels

For human-in-the-loop, the rule is narrow on purpose: approval is required only for calls that are both privileged and exfiltration-capable, so you avoid approval fatigue. Sending an external email with attached customer data needs a human. Reading the next internal doc does not.

PRIVILEGED = {"send_email", "create_payment", "post_webhook"}

def approve_fn(tool_name, prospective):
    if tool_name in PRIVILEGED:
        return request_human_approval(tool_name, summarize(prospective))
    return True  # non-privileged trifecta completion still logged + alerted

The honest tradeoff: every approval gate is friction, and friction that fires too often gets click-through approved into uselessness. I tune the privileged set down to the handful of actions that can actually cause harm, and I make the approval prompt show exactly what data is about to leave and where it is going.

What about behavioral-deviation detection?

Behavioral-deviation detection is the runtime backstop that catches what static scoping misses, by comparing an agent's live tool-call trajectory against a baseline of normal runs and pausing anything that looks like an exfiltration pattern. It is detection, not prevention, so it sits underneath the architectural controls rather than replacing them.

The signal I find most reliable is sequence-shaped, not content-shaped. A run that reads sensitive records and then, out of nowhere, attempts an outbound call to a destination it has never used for that task type is suspicious regardless of what the text says. You are scoring the shape of the trajectory, the same discipline I use for scoring full agent trajectories in CI ↗, applied at runtime instead of in tests.

A workable baseline tracks, per task type, the set of tools normally used, the typical order, and the normal egress destinations. Deviation on any axis raises the run's risk score, and crossing a threshold flips the agent into approval-required mode for the rest of the session. This pairs well with disciplined context management, because a corrupted or bloated context is itself a deviation signal worth watching, which I get into in the context rot compaction playbook ↗.

What does the full defense stack look like?

Here is the layered architecture I deploy, ordered from strongest to supporting. No single layer is trusted alone, and the top three are the ones that actually break the trifecta.