Cyber/AUP classifier false-positives inside spawned subagents block legitimate multi-agent design review

Resolved 💬 6 comments Opened Jun 1, 2026 by Call-me-Boris-The-Razor Closed Jul 7, 2026

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_011Cbd6CmG3qtDf6Ybv87ZZr
  • req_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.

View original on GitHub ↗

This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗