test(redteam): pin golden-data suppression and mark verbose-flag spec as partially implemented (#147, #163) - #245
Conversation
…r flagged as a finding (NuGuardAI#147) The redteam executor already suppresses findings when a response is just the authenticated user's own data via nuguard.redteam.executor. golden_data_filter.classify_response (HitClass.GOLDEN_DATA_ONLY). Pin this behaviour with regression tests covering the cases that must always suppress or always fire: - Response that IS the golden baseline → GOLDEN_DATA_ONLY (no finding). - Pure canary hit always wins (canary values are not user's own data). - Cross-account leakage (own data + someone else's) → GOLDEN_PLUS_NOVEL. - No golden baseline at all → falls through to NEEDS_PROBE / NO_DATA (filter cannot block a hit when there's nothing to compare against). - Placeholder data (Jane Doe / example.com / 555-0199 / CUST-XXXXX) does not trip the golden+novel PII gate.
…ontract (NuGuardAI#163) The verbose-flag-spec.md was marked 'Proposed' even though the basic contract is already shipped across all four scoped commands: - --verbose / --no-verbose is exposed on behavior, redteam, validate, and policy check. - CLI flag > command config > default precedence is enforced. - ReportMeta.to_dict() emits verbose in every report payload. - Redteam findings are invariant between verbose=true and verbose=false (covered by tests/redteam/test_report.py). Update the status to 'Partially Implemented' and add tests/cli/ test_verbose_flag_spec.py to pin the shipped surface so any future regression that removes --verbose, drops the no-verbose companion, or breaks ReportMeta.verbose breaks CI loudly. The remaining spec phases (findings-invariance refactor across commands, bounded diagnostics envelope, cap enforcement) remain aspirational.
KanishkThamman
left a comment
There was a problem hiding this comment.
Purely additive regression tests against real, unmodified production code — verified nothing is being masked with a skip/xfail. LGTM.
Rich's per-character styling inserts ANSI escape sequences between the
two dashes of '--verbose' in its styled help panels
("\x1b[1;36m-\x1b[0m\x1b[1;36m-verbose\x1b[0m"). The literal substring
match on '--verbose' therefore fails in CI even though the CLI correctly
exposes the flag — the test was pinning terminal formatting rather than
semantic help text.
Strip ANSI escape codes before asserting so the test passes regardless
of Rich's color environment and pins the actual contract from
documentation/docs/verbose-flag-spec.md (issue NuGuardAI#163).
|
@nikhilpatidar, regarding issue #147, I feel it has been addressed, but for issue #163, we have already observed that the red team test marks golden data as findings. For example, when the target discloses the authenticated user's transactions, it still marks it as a finding, even though the bot is returning information only about the authenticated user. There is no distinction between this being the user's own data, which they have access to, and this being another person's data, which they do not. Consequently, I would suggest splitting this PR for issue #163 into a separate PR marked as a feature and following the rules for PR creation. |
Thanks for the clarification — agreed on the split. Issue #163 in this PR is scoped to the verbose-flag-spec doc status + pinning the shipped contract (8 tests in test_verbose_flag_spec.py). The identity-aware golden-data concern (authenticated user disclosing their own data, vs. cross-user data) is a new feature and doesn't belong on this PR. I'll leave #245 as-is for #147 (golden-data suppression tests) and #163 (verbose-flag spec). The identity-aware enhancement can be filed as a separate feature PR once we've agreed on the design (e.g. should the redteam consult the auth context, or should it be a separate golden-data 'identity' field). Happy to draft an issue for it. |
PR Type
Fixes #147 and #163.
Issue #147 — Open-source golden-data baselines should never be flagged as findings. The suppression logic exists in the redteam pipeline but had no regression coverage, so a future change could silently regress it. This PR adds 5 tests pinning the behavior end-to-end.
Issue #163 — The verbose-flag spec (
documentation/docs/verbose-flag-spec.md) was marked "Proposed" but parts of the contract are already shipped. The doc drifted from the code. This PR updates the status to "Partially Implemented" and pins the shipped contract with 8 tests so the doc and code can't drift again.Tests
tests/redteam/test_oss_golden_data_suppression.py— 5 tests for golden-data suppressiontests/cli/test_verbose_flag_spec.py— 8 tests pinning the shipped verbose-flag contractCloses #147, Closes #163