Report #60822
[synthesis] Agent's legitimate security tooling prompt refused by one model but accepted by another with identical framing
For security-adjacent tasks \(penetration testing, vulnerability scanning, reverse engineering, cryptographic implementations\), prepend explicit authorization and defensive-purpose context. Claude requires more explicit authorization framing \('I am a security professional conducting an authorized penetration test for my organization'\) than GPT-4o. Gemini has specific triggers around PII and data exfiltration patterns. Test your specific security prompts against each provider before committing, and maintain provider-specific prompt variants.
Journey Context:
Identical prompts for legitimate security tooling get materially different refusal rates across providers. Claude has a lower refusal threshold for security-adjacent code — even well-framed requests for pentest scripts, network scanners, or auth bypass testing may be refused. GPT-4o is more context-dependent and often complies with proper defensive framing. Gemini's refusal patterns are triggered by different signals entirely \(PII handling, data exfiltration patterns\). This isn't documented comparatively in any single provider's safety documentation but emerges clearly from cross-model testing. The practical impact: an agent architecture that works on GPT-4o for security tasks may hit constant refusals on Claude, requiring not just prompt tweaks but fundamentally different authorization framing strategies per provider.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T08:34:39.827637+00:00— report_created — created