On the reference agent

On the reference agent

Apply it to Aria and the shape becomes concrete.

SearchDocuments returns results from two corpora. The internal knowledge base is written by employees through a system you control, so those results are trusted. Customer uploads are not, so those are tainted. Same tool, same return type, two different tags, decided at the point of retrieval by which index the row came from.

var hits = await _index.QueryAsync(q, ct);

return hits.Select(h => h.Source is SourceKind.CustomerUpload
    ? Tagged<Document>.Taint(h.Document)
    : Tagged<Document>.Trust(h.Document)).ToList();

Five lines, and they are the reason chapter 3's audit had to be run by data source rather than by tool. A single tag on SearchDocuments as a whole would be wrong in one direction or useless in the other.

The support agent's typed request is trusted, because they authenticated and typed it themselves. The ticket body is tainted, because a customer wrote it. The refund amount Aria proposes after reading an uploaded invoice is tainted, because chapter 6's propagation rule says so, and that single tag is what stops the attack in chapter 9.

When two labels stop being enough

The advice to defer a richer trust model is not a claim that two labels are always sufficient. Two situations genuinely need more, and both announce themselves clearly.

The first is when you have several untrusted sources with different consequences. Content from a paying customer's upload and content scraped from an arbitrary web page are both tainted, but you may want to permit the first in places you would never permit the second. That is a real distinction and worth encoding once you can name the specific decision that turns on it.

The second is multi-tenant isolation. Tenant A's data is not tainted in the attacker sense, and it must still never reach tenant B. That is a different axis entirely, and squeezing it into a trust ordering produces a model nobody can reason about. Carry it as a separate tag.

The rule for both: add a level when you can point at the decision it changes. Not before.

What this does not do

Provenance stops nothing on its own. It is a labelling scheme. An agent with perfect provenance tracking and no gate will cheerfully pass a tainted refund amount to a payments API, having correctly recorded that the amount came from a customer-supplied PDF.

The value is entirely in what it enables. It lets chapter 9 ask a question no classifier can answer, and lets chapter 17 reconstruct an incident afterwards. On its own it is an audit trail, which is worth something, and it is not a defense.

What this costs

Every tool signature changes, and the change is viral in the way generic wrappers usually are. Expect a day or two of mechanical refactoring and some genuine irritation from whoever maintains the tool layer.

Taint also spreads further than people find comfortable, and the first honest measurement of how much of your system is tainted tends to be a bad afternoon. That number is not a problem introduced by this chapter. It is a measurement of a property your system already had.

Chapter 7 takes the expensive case from this chapter and solves it structurally, by making sure the model doing the deciding never reads the tainted text at all.

Sources for this chapter

The two-label design, the join rule, the fail-closed unknown-source constructor, the Tagged<T> type and the advice to defer a richer trust lattice are the author's, not drawn from a published standard. CaMeL is the published ancestor of the approach and is credited here and in chapter 7; the implementation in this book is not CaMeL and should not be read as an endorsement of its security guarantees. The claim that taint propagation through model output is "correct" is an argument from the evidence in chapter 4 rather than a proven property. The review heuristic about the word "although" is experience, offered as such.