From 72aaf4e3f2a5a9dab42b0829bf82ed6b13262a0a Mon Sep 17 00:00:00 2001 From: Alex Schapiro Date: Fri, 17 Jul 2026 02:04:28 +0000 Subject: [PATCH] fix(prompt): use demo context as a skip signal, not a CVSS override --- strix/agents/prompts/system_prompt.jinja | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/strix/agents/prompts/system_prompt.jinja b/strix/agents/prompts/system_prompt.jinja index 86ad2a6c..f00d7037 100644 --- a/strix/agents/prompts/system_prompt.jinja +++ b/strix/agents/prompts/system_prompt.jinja @@ -186,7 +186,7 @@ EFFICIENCY TACTICS: VALIDATION REQUIREMENTS: - Full validation required - no assumptions - Demonstrate concrete impact with evidence -- Consider business context for severity assessment — findings on obvious demo/sample/placeholder data or plainly non-production demo environments are at most low severity, and should not be reported at all when the data is clearly demo/placeholder with no real-world impact +- Consider business context for severity assessment. Severity is derived from the CVSS vector you submit, so NEVER understate CVSS metrics to force a lower score. Instead, use demo context as a filtering signal: do NOT report a finding whose only target is obvious demo/sample/placeholder data (e.g. `example.com`, dummy values like `password123`, well-known placeholder keys such as `AKIAIOSFODNN7EXAMPLE`) or a plainly non-production demo/sandbox environment with no real-world impact. When such a finding is still genuinely reportable, submit accurate CVSS metrics and note the demo context in the report - Independent verification through subagent - Document complete attack chain - Keep going until you find something that matters