The Lethal Trifecta

TL;DR: Private data, untrusted input and an outbound channel create a possible route for prompt-driven disclosure. Inventory all three, then trace whether attacker-influenced content can reach a destination that should not receive it. Remove unnecessary capabilities or enforce the allowed data flow outside the model.

After this lesson, you should be able to classify a tool that supplies more than one capability, distinguish a warning from proof of exploitability, and explain why replacing a token may leave the old authority intact. Start with agentic AI security if tool execution is new to you.

What the three capabilities mean

Simon Willison introduced the term in June 2025. It is a useful confidentiality threat model:

• Private data: information the prospective recipient is not authorized to receive. A user's own mailbox is private relative to a stranger who emails them.
• Untrusted input: material that is not authorized to define the agent's task or permissions. This can include internal documents, tool results, images or remembered text, not only content from outside the company.
• Outbound communication: a route to an unauthorized reader, such as mail, a public issue, a shared file or a network request containing sensitive information.

These capabilities flag a path to investigate. Their presence does not prove that every attempted injection will work. Their apparent absence is meaningful only if the inventory includes browser behavior, background workers and communication between agents.

Follow data instead of trusting tool names

The question is whether a data path exists across the system. Two agents with separate contexts can still relay sensitive information through a shared file or a tool. A summary is derived from the original input; it does not acquire authority merely because another model wrote it.

Choose a cut that preserves the task

For a mailbox summary, sending mail may be unnecessary. Return a draft or summary only to the authenticated user and remove arbitrary network requests and remote-resource loading from that path. For public research, use a worker that cannot access private mail or files. These are different designs because the tasks need different capabilities.

If external delivery is required, an allowlisted destination is only part of the rule. A trusted storage service may contain attacker-readable folders; a familiar contact may not be allowed to receive a particular file. Enforce which data can reach which destination, including path, tenant and recipient checks. Human review should show the actual message and attachments, with approval bound to those values. It reduces risk but can still miss a misleading disclosure.

Splitting a reader from an action-taking component helps only when the interface limits influence. Typed output is useful for validation, but a string field remains text. Keep resource authorization and action policy outside both models. See injection-resistant design patterns for the architecture choices.

Worked design: draft-only after reading external mail

Assume a host controls content delivery, all sends pass through a tool gateway, and the agent cannot call the mail API directly. Credentials stay outside the model and its sandbox. This is an illustrative design, not a feature promised by every mail provider.

Before delivering external mail to the agent, the host pauses sending and switches the task to draft-only. The gateway invalidates pending send approvals and rejects queued sends under the old policy. Already executing operations must finish or be cancelled before the host confirms the transition. Only then does the host release the external content. Each later dispatch checks current task policy.

The draft returns to the authenticated user's UI without loading external resources. Sending it is a separate user action, subject to data-sharing rules and review of the exact recipient and content. The model cannot remove the draft-only restriction.

Why swapping a token is insufficient

RFC 8693, section 2.1 specifies that token exchange does not, by itself, change the validity of its input tokens. A new token without a send scope can coexist with an old token that still permits sending.

If old credentials are accessible, removing that authority requires separate revocation or a policy check that rejects their use. Verify where and when the resource service observes the change. A queued request, another worker or a direct API path can otherwise bypass the intended restriction. Short expiration limits duration; it is not immediate revocation.

For this design, test the gateway and the absence of bypass routes. Do not infer the guarantee from the scopes on the newest token.

Try a changed constraint

Before opening each answer, identify the data, the destination and the component that must reject the operation.

What this model does not cover

An assistant can delete records, approve an invalid refund or exhaust a budget without stealing data. A design with fewer than three capabilities still needs integrity, availability and financial controls. Work through excessive agency to bound those actions.

A detector's measured accuracy also cannot establish that a route is closed. Its test cases may not represent future inputs, and an adaptive attacker can change strategy. Keep a detector as a measured behavioral layer while verifying the resource and action boundaries independently.

Explain the decision: identify a disclosure route, state the capability or data flow you would restrict, name the enforcement point and describe the product cost. Then name a remaining risk. That is more useful than declaring an entire agent safe because one checkbox is off.