Taint tracking appears in three places and is absent from the fourth, which leaves its status ambiguous.
- Threat model, in scope for v1: "Taint flow: tool results flowing back into the model unredacted."
- Proposed approach: a full subsection describing tagging untrusted data and tightening inspection on outbound calls that use it.
- Open risks: "False negatives in taint flow analysis could reopen prompt-injection vectors."
- v1 scope: not mentioned.
So is it in v1 or not? It matters more than a missing bullet, because taint tracking is by far the hardest thing in the document and the rest of the paper is buildable without it.
The difficulty is that taint over agent tool output is not the taint analysis compilers do. There is no dataflow to follow. A tool returns a blob of text, the model reads it, and some later tool call may or may not be a consequence. The model is an opaque transformation in the middle, and a model that has read tainted content can act on it without ever quoting it: it can paraphrase a secret, encode it, or simply be persuaded to take an action that leaks nothing textual at all. Substring matching between tainted input and outbound arguments catches the naive case and misses the adversarial one, which is the case that matters for indirect injection.
A coarse rule gets most of the value for a fraction of the work: once a session has read untrusted content, every subsequent egress in that session goes to Review rather than Allow. No dataflow, no matching, no false negatives of the interesting kind. It costs precision (more prompts after any web fetch), and precision is exactly what a v1.1 can buy back with per value tagging once there is a corpus to measure against.
Whichever way it goes, the honest framing is worth keeping: taint tracking is mitigation, not prevention, and the document should not let a reader conclude that indirect injection is solved.
What would help: either add taint tracking to the v1 scope list explicitly, or move it to a "deferred to v1.1" note and put the coarse session level rule in v1. Also worth restating the threat model bullet as what the mechanism actually mitigates, since "tool results flowing back into the model unredacted" describes a condition rather than an attack.
Raised during the public review window (closes 2026-09-19).
Taint tracking appears in three places and is absent from the fourth, which leaves its status ambiguous.
So is it in v1 or not? It matters more than a missing bullet, because taint tracking is by far the hardest thing in the document and the rest of the paper is buildable without it.
The difficulty is that taint over agent tool output is not the taint analysis compilers do. There is no dataflow to follow. A tool returns a blob of text, the model reads it, and some later tool call may or may not be a consequence. The model is an opaque transformation in the middle, and a model that has read tainted content can act on it without ever quoting it: it can paraphrase a secret, encode it, or simply be persuaded to take an action that leaks nothing textual at all. Substring matching between tainted input and outbound arguments catches the naive case and misses the adversarial one, which is the case that matters for indirect injection.
A coarse rule gets most of the value for a fraction of the work: once a session has read untrusted content, every subsequent egress in that session goes to Review rather than Allow. No dataflow, no matching, no false negatives of the interesting kind. It costs precision (more prompts after any web fetch), and precision is exactly what a v1.1 can buy back with per value tagging once there is a corpus to measure against.
Whichever way it goes, the honest framing is worth keeping: taint tracking is mitigation, not prevention, and the document should not let a reader conclude that indirect injection is solved.
What would help: either add taint tracking to the v1 scope list explicitly, or move it to a "deferred to v1.1" note and put the coarse session level rule in v1. Also worth restating the threat model bullet as what the mechanism actually mitigates, since "tool results flowing back into the model unredacted" describes a condition rather than an attack.
Raised during the public review window (closes 2026-09-19).