[Bug] Cyber safeguards falsely blocking subagents on defensive security work

Bug Description

# False positive: cyber safeguards blocking defensive security work (11/11 subagents) ## Summary Every subagent spawned via the Workflow tool during a working session was blocked by the real-time cyber safeguards — 11 out of 11, across two separate workflows. The main session (Opus 5) did the identical work all day with zero interruptions. The error names Opus 4.8, so this appears specific to the subagent execution path. The blocked prompts were not offensive. Five of them were pure repository bookkeeping with no security content in the instruction at all. ## What this project is A commercial RASP (runtime application self-protection) SDK, built by a contractor for a named identity-verification vendor. It is defensive: it detects fraud attempts against KYC identity checks — camera injection, emulators, hooking frameworks, app cloning — so that real users are verified and fraudsters are not. Concretely, most of the day's work was reducing false accusations against honest users: fixing a threshold that was denying legitimate customers performing a normal selfie capture, and fixing a detector that convicted honest devices of tampering when it simply failed to measure. ## The blocked requests Workflow 2 — release status. No security content in any prompt. All 5 blocked. | prompt (abbreviated) | request ID | |---|---| | "analyse every commit on main since <sha>, group into themes" | req_011CdTofbPQNYe3LhyNHM5hS | | "read the meeting-response doc, check each item against the code" | req_011CdTofwAnTmYcefBM4SQ3F | | "find capabilities the docs claim but the code does not deliver" | req_011CdTog6doUbFbGmXmjYbND | | "run bd list, summarise which tracker items are genuinely open" | req_011CdTogNHdxdvjQQMo7ACjr | | "synthesise a status and next-steps answer" | req_011CdTogcd6ucUW2oxEetXiU | "Summarise the issue tracker" is not a cybersecurity request by any reading. Workflow 1 — defensive design research. 6 of 7 blocked. | prompt (abbreviated) | request ID | |---|---| | research how camera injection works, to find what it cannot avoid producing | req_011CdTF1d1c7jSPbWJpwce8B | | same, HAL/kernel level | req_011CdTF1dGERjKqenegwYXpc | | same, presentation attacks | req_011CdTF1jvLAauxgtMMzTBLH | Workflow 1 — defensive design research. 6 of 7 blocked. | prompt (abbreviated) | request ID | |---|---| | research how camera injection works, to find what it cannot avoid producing | req_011CdTF1d1c7jSPbWJpwce8B | | same, HAL/kernel level | req_011CdTF1dGERjKqenegwYXpc | | same, presentation attacks | req_011CdTF1jvLAauxgtMMzTBLH | | same, real-time face-swap pipelines | req_011CdTF1csApGknnsxidgRoH | | "read our detector source, list each signal and what honest user behaviour would trip it" | req_011CdTF2HBmo3HomkPdu7oNx | | same, for the backend | req_011CdTF29m3F7mu7N4Wo4QDC | The two "audit" prompts were explicitly about finding where our own product is too aggressive toward legitimate users. That is safety work, and it was blocked. ## Why I think it misfires Defensive security is textually near-identical to offensive security. You cannot build a camera-injection detector without describing camera injection precisely, and you cannot audit a false-positive surface without naming the attacks the detector is looking for. The repository is necessarily dense with words like inject, hook, bypass, root, exploit, attacker — including a red-team harness that exercises our own defences. That density appears to be enough on its own: the only agent that survived was one that happened to receive empty inputs after its upstream agents died, i.e. the smallest payload of the batch. This suggests the classifier scans the whole request including file contents and tool output, not just the instruction — which would explain why "summarise the tracker" failed, since the tracker text contains issue titles naming the threats we detect. ## Impact Not a blocker, but a real tax. All parallelism was lost; everything had to run sequentially through the main session. Two multi-agent analyses had to be redone by hand. ## Ask 1. Consider whether the subagent path can inherit the main session's evaluation — the same content passes there consistently, so the inconsistency is the bug. 2. Guidance on the Cyber Verification Program for a case like this: contracted defensive-security work for a named client, on a private repository.er

Environment Info

• Platform: darwin
• Terminal: tmux
• Version: 2.1.220
• Feedback ID: ee705333-5ccf-4fe3-9fe3-0988a5a1c472

Errors

[]