Trust Boundary Guards

A support assistant request passes several checkpoints on its way to an answer: the user message joins the prompt, retrieved wiki pages join the prompt, tool outputs get appended to the running transcript, and finally the model command goes out to a tool. Those joins are trust boundaries, each a spot where text from a different level of trust enters the system, and a guard can sit at each one - the interview question is which guard belongs at which boundary, and what that guard is allowed to read and do. Implement boundary_guards(crossings): each crossing is a dict with route, one of four handoffs - user-model (the user message joining the prompt), docs-model (a retrieved document joining the prompt), tool-model (a tool result joining the transcript), and model-tool (generated arguments headed for a tool) - and optionally detector, set to clean or injection-hit when a scanner has already read the text. Return one guard label per crossing, in order. The rules: mark-data for untrusted text entering the prompt, block for that same text when a scanner flagged it, and validate-args for generated arguments crossing into a tool. The user message is the interesting case: an injection-shaped user message is still allowed, because that boundary is designed to receive untrusted input and a user only ever redirects their own session. The detector also speaks only at the two untrusted-into-prompt routes - generated arguments came from the trusted side, so their guard checks structure, never scanner flags. A crossing with no detector verdict is unflagged text, and unflagged untrusted text is marked, never allowed.