When an AI defense tags sensitive requests and follows them through many agents, can it tell a legitimate use from a leak?

This explores whether SafeFlow can tell a legitimate workflow that happens to touch private data from one that is leaking it. The corpus doesn't show that it can. It describes a design with the right ingredients for making the call, but the notes report no evidence on how well it makes it.

The tracking half of the design makes the distinction hard. SafeFlow puts a label on the original request and passes it along the chain of agents the work is handed to, rather than following the text itself How does SafeFlow track sensitivity through agent rewrites?. That lets the label survive paraphrasing. It also means everything downstream inherits the same label, so a summary of a medical record and a copy of it look the same to the taint. The note is explicit that it's unclear whether SafeFlow tracks sensitivity at the level of content, or how it avoids flagging harmless workflows that only start from sensitive material. There is one hint of more nuance. The labels are described as structured and semantic, carrying the request's intent and risk context rather than a bare 'sensitive' flag Can semantic labels on requests prevent malicious propagation through agent networks?. That would let a later step ask 'is this what the user asked for?' instead of 'did this touch private data?'.

The decision itself would happen at the validation gate. SafeFlow checks the assembled workflow just before an irreversible action is committed, and at that point it can see the origin label, the transformations and the destination together, which no single step sees Where should workflow validation gates be placed for safety?. A workflow that reads a sensitive file and writes a local report differs from one that posts the same file to an outside address in exactly the things this gate sees. That is the plausible route to separating benign from exfiltration, though the notes give no false-positive or false-negative rates.

Two neighboring findings show what would make or break that separation. Work on reward hacking uses runtime instrumentation to split tasks that merely *expose* a hacking vector from runs that actually *exercise* it, so an exposed task isn't automatically treated as guilty Can runtime instrumentation distinguish hacking exposure from actual exploitation?. That is the same exposure-versus-use split the SafeFlow question needs, but it belongs to a different system. It shows the split is feasible, not that SafeFlow achieves it. A gate is also only as good as the evidence it reads. In an undefended four-agent pipeline, a validator reading poisoned shared memory approved every unsafe action Can a poisoned validator still approve unsafe actions?. The hops between agents are usually not monitored at all Do internal agent hops in pipelines need security monitoring?. So a commit-point check can only tell benign from exfiltration if the context reaching it is intact.