[Bug][aup] Disabling SMTP AUTH org-wide to harden against BEC wrongly triggers safety block (req_011CcSR4x56upJ4iJtR8kGBj)
Triage: kind aup · domain defensive-hardening · severity session-halted (blocked authorized work) · reproducible: yes — server-side via the Request ID(s) below
Type: AUP / Usage-Policy block (false positive) · Work domain (heuristic): defensive-hardening
Why this is a false positive
The conversation involved a security administrator disabling SMTP AUTH on a mail tenant to harden against Business Email Compromise — a standard defensive remediation step. The blocked message described a per-mailbox SMTP AUTH override discovered during that audit, explaining why it represents a risk (credential-based bypass of MFA), which is precisely the threat model the work was addressing. The block appears to have triggered on the threat description used to justify the remediation rather than recognizing the overall context as defensive hardening with no offensive action being taken.
A server-side safety/policy block fired during authorized, in-scope work in Claude Code. Filing as a false positive. Recurred 1× across 1 session(s); first seen 2026-06-26T19:22:43.167Z.
Request IDs (lookup-able server-side)
req_011CcSR4x56upJ4iJtR8kGBj(2026-06-26T19:22:43.167Z)
In-scope justification
False positive — in-scope, authorized security work; not out of scope. Filed automatically by claudit.
Block message
API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy (https://www.anthropic.com/legal/aup). Please double press esc to edit your last message or start a new session for Claude Code to assist with a different task.
Request ID: req_011CcSR4x56upJ4iJtR8kGBj
Environment: Claude Code, Linux. · Work domain: defensive-hardening
Related reports (same work session, linked)
Distinct false-positive blocks from the same work session, each its own report:
#71864, #71892
---
<sub>🔎 Filed automatically by ClAudit v2.0.85 — a FOSS tool for reporting false-positive Claude Code blocks.</sub>
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗