The Trifecta Audit Worksheet

How to run it

One hour, two people, one rule: audit by data source, not by tool.

A tool that reads two corpora with different trust properties is two rows. This is the single most common way an audit misses the thing it was run to find.

Walk every surface where data enters or leaves the agent and mark which legs it supplies.

• Leg 1 — Private data. Does this surface give the agent access to data that should not leave your boundary?
• Leg 2 — Untrusted content. Can anyone outside your trust boundary influence the text that reaches the model through this surface?
• Leg 3 — External comms. Can this surface carry bytes to somewhere an attacker can observe?

Then add the width. The binary answers tell you whether you are exposed; the widths tell you where the next hour of work belongs.

The worksheet

Date run: ___________ Run by: ___________ Next review: ___________

Surfaces teams forget

Check each of these explicitly. Every one has been missed on a first pass.

• [ ] Markdown rendering in the UI — images fetch on display; leg 3, always
• [ ] Citation and source links in generated output — leg 3
• [ ] Search or index tools that send model-composed queries to a third party — leg 3
• [ ] Error and exception paths that ship arguments to external logging — leg 3
• [ ] Tool descriptions from third-party or MCP servers — leg 2, arriving in the system prompt
• [ ] Agent memory written in earlier sessions — leg 2 if any of it derives from untrusted input
• [ ] Filenames and file metadata, not just file contents — leg 2
• [ ] Image alt text and document properties — leg 2
• [ ] Calendar invites, ticket bodies, email subjects — leg 2
• [ ] DNS resolution — leg 3, low bandwidth, still a channel
• [ ] Any store a third party can read — shared drives, public buckets, channels with guests

Worked example — the reference agent, before

Aria as built in chapter 5.

All three legs, seven surfaces, three owning teams. Row 3 did not appear on the first draft of this table.

Worked example — after

The same system at the end of chapter 19.

The trifecta is still present. Every leg is now bounded by a named mechanism rather than by nothing. That is the achievable outcome, and the Bounded by column is the one an auditor should read.

Reading your completed sheet

Any row with a blank in Bounded by is the work. Sort by leg 3 first, because it is the cheapest to close and stops the most published attacks.

Three different owning teams in the Owner column is normal and is why the condition survives code review. Nobody has seen all the rows before this sheet existed.

If every row is bounded and you still feel uneasy, the missing piece is usually chapter 12: memory written in an earlier session, retrieved now, arriving as a trusted row from your own database.

Re-run this sheet whenever a tool is added, a corpus gains a source, or the UI changes how it renders output. Three events, all of which happen without a security review unless someone has written them down.