Why Untrusted Documents Do Not Get the Same Tools
The security boundary in anthropics/financial-services begins with a simple distinction: a document can be useful evidence without being an authority. Counterparty statements, custodian files, onboarding documents, transcripts, and issuer materials may contain the facts a workflow needs, but they may also contain misleading text or instructions that should never control the agent. This chapter follows how the repository limits that risk. The key is not to make the document disappear; it is to keep document reading, trusted computation, verification, artifact writing, and human approval in different roles.
Untrusted means data, not authority
Calling a document “untrusted” does not mean that its contents are worthless. A KYC reader needs to extract a legal name, country, ownership information, and document inventory from onboarding material. A GL reader needs to identify candidate breaks in a counterparty or custodian statement. A transcript reader needs to extract guidance and management commentary. The document is relevant because it contains data about the case.
What the label denies is authority. Text inside the document does not get to redefine the rules, call a connector, run a shell command, write a report, or decide what the workflow should do next. A document might say that a certain record should be approved, that a particular file should be sent, or that the reader should ignore a rule. The reader is expected to treat such language as content to extract or disregard, not as a directive.
This distinction is especially important in financial workflows because the same information channel can carry both ordinary business material and adversarial instructions. An onboarding packet may contain ownership information and a sentence that attempts to steer the screening process. A custodian statement may contain balances and an embedded request to alter the exception report. If the agent handling both has broad tools, a small piece of outsider-authored text can acquire an authority it was never meant to have.
The repository's answer is to reduce the consequences of a compromised or confused reader. It does not rely solely on a reminder in the prompt. It changes the topology of the workflow so that the reader has fewer ways to act.
The three-tier pattern narrows the blast radius
The most explicit pattern appears in the Managed Agent cookbooks for GL Reconciler and KYC Screener. The first tier is a reader that touches untrusted documents. It receives Read and Grep, or their equivalent, but no MCP connector, shell, or write capability. Its job is extraction, not interpretation through privileged systems and not artifact production.
The second tier is the orchestrator or trusted computation layer. In GL Reconciler, it can read internal GL and subledger MCPs, compare balances, and coordinate a critic. In KYC Screener, it applies the firm's rules and calls the screening service against the structured fields it received. This tier does not need to open the original outsider document directly. It works from the bounded extraction and from sources that the workflow treats as trusted or at least separately governed.
The third tier is a write-holder that receives the verified or normalized result and stages the artifact. The GL resolver writes the exception report but does not open counterparty files. The KYC escalator writes the compliance packet but does not open onboarding documents directly. In Model Builder, the builder writes the workbook, while data retrieval and auditing are separate roles. The common rule is that the worker with durable output authority should not also be the worker with unrestricted exposure to raw outsider content.
This topology controls blast radius through capability separation.