Threat detection runs the detector against a directory outside its agent scope, and reports green #72897

Split from #66926 (finding 2), as requested in #66926 (comment).

This is the one we would prioritise, because it fails in the direction of a clean verdict over inputs that were never read.

Summary

The detection job mounts the staged inputs read-write and then invokes the detector against them, but never adds that directory to the agent's permitted scope. The detector cannot read the artifacts it is pointed at, and reports a green verdict anyway.

State at v0.92.0, provable from the compiled lock alone

In the agent job the engine invocation carries all three of these:

--add-dir ${RUNNER_TEMP}/gh-aw/ ... --allow-all-paths --add-dir "${GITHUB_WORKSPACE}"

In the detection job the invocation carries none of them:

awf --config "${RUNNER_TEMP}/gh-aw/awf-config.json" \
  --container-workdir "${GITHUB_WORKSPACE}" \
  --mount "${RUNNER_TEMP}/gh-aw:${RUNNER_TEMP}/gh-aw:ro" \
  --mount "${RUNNER_TEMP}/gh-aw/threat-detection:${RUNNER_TEMP}/gh-aw/threat-detection:rw" \
  --mount /tmp/gh-aw:/tmp/gh-aw:rw ... --skip-pull \
  -- /bin/bash -c '... threat-detect --engine copilot \
       --output "${RUNNER_TEMP}/gh-aw/threat-detection/detection_result.json" \
       "${RUNNER_TEMP}/gh-aw/threat-detection"'

${RUNNER_TEMP}/gh-aw/threat-detection is mounted rw and handed to threat-detect as its input directory, and it is in no --add-dir. Mounting a path into the sandbox is not the same as granting the detector subprocess file scope over it — which is also how github/gh-aw-firewall#10281 framed it when it left subprocess scope upstream.

This contrast is sharper on v0.92.0 than when we filed: the agent job gained --add-dir ${RUNNER_TEMP}/gh-aw/ and --allow-all-paths, and the detection job gained nothing.

Why it matters

Strict mode is not a defence here. We run safe-outputs.threat-detection.continue-on-error: false precisely so a detection without a verdict blocks the run. It does not help when the detector produces a successful verdict having read nothing — the run is green, the safe outputs publish, and the only trace is permission errors in the detection log.

What we carry

A prompt: override pointing the detector at the readable copies:

prompt: |
  The artifacts under $RUNNER_TEMP/gh-aw/threat-detection are not readable in this sandbox.
  Read the identical copies under /tmp/gh-aw/ instead (agent_output.json, aw-*.patch, aw-*.bundle, aw-prompts/, aw_info.json).
  Always report the verdict by calling the threat_detection_result tool, never by printing THREAT_DETECTION_RESULT.

Ask

Either of these closes it for us:

1. Add the staged input directory to the detector's scope in the compiled detection job, or
2. Fail closed when the detector cannot read its input directory, so an unreadable input can never produce a green verdict.

(2) is the one that protects adopters who have not noticed, and it is independent of topology.

Capture

We offered a run with the override removed, and @Rul1an asked for it on v0.89.21. We have since upgraded, so we can no longer produce that version — we will post the capture on v0.92.0 instead, with the full setup SHA, the compiler/AWF/threat-detect pins, the permission errors, and the conclusion step's environment and conclusion/reason/success outputs, prompts and payloads redacted. A current capture is the more useful artefact anyway, since the earlier runs have expired from our Actions history.