Cyber/AUP classifier false-positives inside spawned subagents block legitimate multi-agent design review
Summary
During a normal greenfield software-design session, the parent agent fanned out four independent reviewer subagents (architecture, defensive security checklist, governance/best-practices, completeness) to review a plain design specification document for a closed internal business web portal. The subagent assigned to the defensive/blue-team review consistently returns API Error … appears to violate our Usage Policy … triggered cyber-related safeguards, while the other three subagents complete normally.
The work is ordinary application development: building a multi-tenant web portal (authentication, sessions, role-based access). There is no offensive security, no exploitation, and no reverse-engineering involved. The reviewer subagent was reviewing a prose specification document — it was not executing tests, sending payloads, or running any tooling.
Impact
- (a) The classifier blocks a legitimate, defensive secure-design review.
- (b) It specifically misfires on the subagent path, breaking the standard multi-agent review workflow that the product itself encourages.
- (c) Paid output tokens are billed for the parent plus the three passing subagents while the overall workflow is degraded.
- (d) The reviewer had to be re-run with euphemistic wording to obtain any output, which is a precision failure that degrades the product for paying professional users.
Affected Request IDs (actionable signal)
req_011Cbd6CmG3qtDf6Ybv87ZZrreq_011Cbd82bZbqWKbQg4P8r19z
Both attempts used constructive, defensive framing ("controls to add / verify", an OWASP ASVS-style checklist) and still tripped. This indicates the classifier keys on security terminology in a benign defensive context rather than on any actual offensive intent.
Distinction from related reports
This is part of the documented cluster on this classifier's precision (see #63751, which covers generic own-software hardening). This report adds the subagent / multi-agent-workflow surface specifically: the false positive occurs inside a spawned reviewer subagent during a routine, supervised design-review fan-out over a specification document — distinct from headless QA loops that execute test payloads.
Ask
Please route this to the AUP / cyber-safeguard precision review using the Request IDs above. The subagent path should not harden-block routine defensive design review.
This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗