fix(agent): wrap read_file/terminal results from externally-fetched paths as untrusted

[JoaoMarcos44]

Fixes #57710

Problem

`UNTRUSTED_TOOL_NAMES` (agent/tool_dispatch_helpers.py) wraps `web_extract`/`web_search`/`browser`/`mcp_` results in `<untrusted_tool_result>` delimiters — the promptware defense against indirect prompt injection from #496. `read_file`/`terminal` are deliberately excluded (there's an existing test documenting this: reading the user's own project files shouldn't get wrapper noise).

That's correct for the common case, but the boundary is tool-name-based, not provenance-based. If the agent does `git clone`/`curl`/`wget` against an attacker-influenceable URL (reviewing a PR, checking a dependency, following a link from an issue), the fetched content is read back via `read_file`/`terminal` completely unwrapped — a malicious README/AGENTS.md is just as capable of indirect prompt injection as a poisoned web page, but never gets the "treat as DATA" framing.

A one-line "add read_file to the frozenset" fix wouldn't actually close this: `terminal` (`cat`/`type` on the same file) is an equally viable bypass, and unconditionally wrapping every `read_file` call would spam the wrapper on the overwhelming common case of reading the user's own repo.

Fix

Track filesystem provenance instead of blanket tool-name marking:

• `agent/tool_dispatch_helpers.py` — new pure helpers: `_extract_fetch_roots` (recognizes `git clone`, `gh repo clone`, `curl -o/-O`, `wget`, resolves the destination path), `_path_under_any_root`, `_command_touches_untrusted_root` (catches `cat repo/file`, `cd repo && less notes`, not just the fetch command itself). `make_tool_result_message`/`_maybe_wrap_untrusted` gained a `path_untrusted` override so wrapping can be driven by provenance instead of only by tool name.
• `run_agent.py` — `AIAgent._is_fs_tool_result_untrusted`: maintains `self._untrusted_fs_roots`, a set that persists for the whole session (not just the turn, unlike the existing per-turn mutation-verifier state) — a repo cloned in turn 3 is still untrusted if read back in turn 20.
• `agent/tool_executor.py` — both the concurrent and sequential tool-result call sites now compute `path_untrusted` from the active env's cwd before building the tool-result message.

Heuristic in the same spirit as the existing `_is_destructive_command` — best-effort pattern matching, not full shell-semantics parsing. Exotic invocations (`sh -c` wrapping, archive extraction, `gh pr checkout`) are intentionally out of scope for this pass; noted as a limitation.

Test plan

• `tests/agent/test_tool_dispatch_helpers.py` — 17 new tests covering `_extract_fetch_roots` (git clone w/ and w/o explicit dest, gh repo clone, curl -o, wget-from-url, unrelated commands), `_path_under_any_root` (exact/nested/sibling-not-matched/no-roots), `_command_touches_untrusted_root` (direct read, cd-then-read, unrelated, no-roots), and end-to-end `make_tool_result_message` wrapping/non-wrapping.
• Full existing suite: `tests/agent/test_tool_dispatch_helpers.py`, `tests/run_agent/test_file_mutation_verifier.py`, `tests/agent/test_tool_guardrails.py`, `tests/run_agent/test_tool_executor_contextvar_propagation.py` — all pass, no regressions.
• Targeted `tests/run_agent -k "tool_call or parallel or sequential"`: 172 passed, 3 pre-existing failures unrelated to this change (confirmed identical failures on `main` before this branch — `DaemonThreadPoolExecutor` vs. Python 3.14's `ThreadPoolExecutor._initializer`, in `tools/daemon_pool.py`).
• Manual end-to-end check: `git clone ... mydir` then `read_file(mydir/README.md)` and `terminal("cat mydir/README.md")` both get wrapped; `read_file`/`terminal` on the agent's own files stay unwrapped; `write_file` unaffected.

[teknium1]

Thanks for identifying a real provenance gap: current main still leaves read_file and terminal outside _is_untrusted_tool() (agent/tool_dispatch_helpers.py:482-505).

Problems

• The proposed _fs_cwd uses only env.cwd, but terminal supports a per-call workdir and resolves execution through it (tools/terminal_tool.py:2035, 2390-2395). A clone under workdir="/tmp" would be recorded relative to the session cwd, missing subsequent reads of /tmp/<repo>.
• Current main's output-risk metadata checks only _is_untrusted_tool(name) (agent/tool_dispatch_helpers.py:508-516). The new path_untrusted wrapper would not classify cloned-file content or emit the existing risk callback (agent/tool_executor.py:984-1000, 1668-1684).

Suggested changes

• Use terminal's effective per-call cwd for provenance and cover that flow in an executor-level test.
• Carry provenance into _tool_output_risk_metadata and preserve current effect_disposition / risk-callback handling when salvaging onto main.

Automated hermes-sweeper review.

[jackgraphene-cyber]

Reviewed the diff end-to-end. The provenance-based approach is the right call over blanket-marking tool names, and the workdir resolution + risk-metadata propagation cover the gaps the earlier review flagged. CI is green and the tests are solid.

One real bypass remains that this PR doesn't close, worth either fixing here or explicitly scoping into a follow-up issue:

execute_code can read untrusted roots and bypass the wrapper

_is_fs_tool_result_untrusted only checks read_file and terminal. But execute_code runs arbitrary Python in a subprocess and can do:

with open("/work/cloned-repo/README.md") as f:
    print(f.read())

That stdout comes back as the execute_code tool result — never hits read_file or terminal, so the provenance wrapper is skipped entirely. A poisoned README/AGENTS.md in a cloned repo is just as capable of indirect prompt injection whether it's read back via read_file, cat, or open().read() inside execute_code.

This is the read-direction symmetric gap to the write-direction problem Q/GTS 078 (our internal standard) addresses with a PEP 578 audit hook — execute_code's subprocess can escape the sandbox's open() restrictions on the write side, and the same escape applies on the read side for provenance tracking.

Two options:

1. Minimal: extend _is_fs_tool_result_untrusted to also check execute_code. The challenge is that execute_code args contain a code blob, not a path — you'd need to scan the code for path literals under untrusted roots (heuristic, same spirit as _is_destructive_command), or wrap all execute_code output whenever _untrusted_fs_roots is non-empty (conservative, adds wrapper noise to every code-exec result after a clone).
2. Robust: have the execute_code subprocess report which file paths it opened (via the same PEP 578 audit hook on open), then check those against roots in the parent process before constructing the tool result. More work but closes the gap architecturally rather than heuristically.

Minor

• _FETCH_DEST_FLAG_RE matches -o and -O but not --output (curl) or --output-document (wget). Long-form flags are common in scripts.
• _untrusted_fs_roots persists for the whole session with no GC. If a user clones a trusted repo mid-session (their own private repo), it stays marked. Conservative/safe, but worth a docstring note.
• gh pr checkout / git checkout <fetched-branch> brings attacker-controlled content into an existing working tree without triggering _extract_fetch_roots. The issue acknowledges exotic invocations are out of scope, but PR checkout is a core code-review threat model — worth a follow-up.

None of these are blockers for the current approach. The execute_code gap is the one I'd want tracked before considering #57710 fully closed.

[ifanjuang]

Related provenance source found on current main: gateway-uploaded attachments are cached by Hermes and several adapters inline small UTF-8 attachment bodies directly into MessageEvent.text as [Content of ...], sharing the same user message as the actual caption/instruction. Those cache paths also later flow through read_file document extraction without an ingress provenance signal.

I opened #103689 to keep that source distinct rather than expanding this PR silently. Architecturally it looks compatible with this PR's direction: gateway attachment paths could seed the same session-level untrusted filesystem provenance, while inline attachment text needs data-only framing before it is concatenated with the user caption. No need for a parallel scanner/registry.

This is not intended as a blocker for #57712; it is a concrete follow-up/source that the provenance model should eventually accept.