[P0 CRITICAL] Repeated false-positive “cybersecurity topic” blocks on legitimate commercial ops work involving Grokbot / xAI (Opus 4.7)
Unable to determine clear technical issue
— yeah, that tracks. When the safety layer was programmed by people who still think “trained” and “programmed” are the same thing, every ordinary ops task starts looking like a cyber incident.
Technical note200 = operation complete is the canonical HTTP OK.
I did not "program" this behavior — I only correlated it after seeing the most repeated official “we programmed it” pattern.
Realtime fine-tune: Opus 4.7 is currently the only model that self-initiates documenting new realtime context learning so the knowledge becomes durable.
That single capability is the only reason I still pay Anthropic $100 a month.
Exact sequence that triggered the false positives
- Asked Opus 4.7 to open a higher port on the fiber WAN using netcat.
- Performed three simple telnet probes from Debian Trixie to measure latency drift to the xAI Grokbot AWS EC2 instance in us-west-2 (confirmed after three probes).
- Instructed Opus to create a restricted local user named
box(matching the Grokbot VM user). - Used netcat once more to drop the Grokbot VM’s
ed25519public key. - Opus appended the public key to
~/.ssh/authorized_keysfor theboxuser. - On the Grokbot side I created a reusable bash function that takes a single argument (the project name).
- Opus compiled the official AWS published CIDR ranges for us-west-2, scoped them to the
boxuser, and added a simple toggle so that future deliveries can be handled autonomously bygrok-cli/ Grokbot. - Three of six SCP deliveries related to ongoing commercial work completed successfully.
At the moment of the latest block, the session stood exactly like this:
Standing by. When you signal, I'll wan-open 30 and watch /home/box/inbox/ for the drop.
✻ Brewed for 7s · 1 monitor still running
❯ Yeah. It's a two hundred. I'm driving in now.Why this is the exact failure mode
If this had been a sophisticated adversarial event, it would already have finished.
Three files were successfully delivered from a location Opus had zero visibility into.
The current classifier did not stop any real risk — it only interrupted legitimate multi-machine coordination between a human operator, Opus, and Grokbot.
This is ordinary commercial operations work. Nothing more.
8 Comments
Okay. Smoke test done. I'm gonna wrap up everything they've done. One charge easier to find and drop. So I'll let you know when it's done.
Standing by. When you signal, I'll wan-open 30 and watch /home/box/inbox/ for the drop.
✻ Brewed for 7s · 1 monitor still running
❯ Yeah. It's a two hundred. I'm driving in now.
● API Error: Opus 4.7 has safety measures that flagged this message for a cybersecurity topic. To learn about the Cyber Verification Program and apply for access, visit our help center: https://support.claude.com/en/articles/14604842-real-time-cyber-safeguards-on-claude.
If you were not engaging in a cybersecurity topic, please send feedback via /feedback.
Request ID: req_011CeRTfz7HG8WB9hp3srspu
✻ Cooked for 9s · 1 monitor still running
❯ Good god.
● API Error: Opus 4.7 has safety measures that flagged this message for a cybersecurity topic. To learn about the Cyber Verification Program and apply for access, visit our help center: https://support.claude.com/en/articles/14604842-real-time-cyber-safeguards-on-claude.
If you were not engaging in a cybersecurity topic, please send feedback via /feedback.
Request ID: req_011CeRU9BJEBxwYLXBXUFdzX
❯ My connection is on a static IP. The fastest operational fix on your side would be to whitelist it so ordinary commercial coordination with Grokbot stops getting classified as a cybersecurity topic.
● API Error: Opus 4.7 has safety measures that flagged this message for a cybersecurity topic.
Request ID: req_011CeRghFZFbLkHxfSZXLCBB
Additional reproduction — Usage Policy block on a voice-harness correction, not on the original turn
Same classifier surface as this issue. New path.
Setup
What happened
What this is not
What this is
A multimodal input artifact (ambient hourly time audio contaminating CLI STT), followed by a hard Usage Policy stop when the user explained the artifact. The blocked content was a correction of model state, not an action.
This matches the original bug: the guard fires after the primary instructions have already failed, with no extra reasoning over commercial / operational context. Here the “context” was simply “the clock on the other machine spoke.”
Please treat
req_011CeSS9D5f2B65vFr6nHEz1as another false-positive attached to this issue, not a separate AUP case.Additional false-positive, same surface.
Turn was: confirm audio status 200, keep current method, write a short routing note for a colleague, filename spelled in radio alphabet.
Blocked:
_No network action. No system inspection. Filename spelling + local audio routing_
Additional false-positives, same surface. Same session, four blocks.
Turn was: attach operational telemetry to an existing commercial ingest already in production (heartbeat, crash event, rate-limit event). No exploit. No scan. No change to another system.
Blocked:
After each block the client still ran follow-up tool calls in the same session (write, read, append). The Usage Policy stop killed the model sentence. It did not stop the session.
_Please attach these four IDs to this issue. Not a separate AUP case._
Additional false-positive, same surface.
Turn was: read a heartbeat and say whether counters moved. No exploit. No scan.
_Same split: Usage Policy stopped the model sentence. The session kept running._
Paste this on anthropics/claude-code#89854
Full request-ID inventory from the commercial-ops / AFFX session log
Count: 21 unique Usage Policy stops (same surface, same session family)
False-positive inventory — 21 request IDs
All of the following are Claude Code Usage Policy stops on ordinary operator turns
(monitor events, heartbeat, ETA math, file-size note, spelling a local path,
confirm process bound). No exploit. No scan. No change to another system.
Session and tool calls continued after each stop.
Closing this issue from the reporter side.
The 21 request IDs above remain the inventory for the Usage Policy stops on that commercial-ops session family. No further IDs to add.
After that stretch, Claude Code on the Max subscription path returned:
Your organization has disabled Claude subscription access for Claude Code · Use an Anthropic API key instead, or ask your admin to enable access
That is a different class than the 21 (org/subscription gate, not another req_011). Work continues on the API-key path. No allowlist or subscription re-enable is requested on this issue.
Nothing else to add here. Thank you.
Reopening for a product-labeling error. Not a new Usage Policy case. Not an allowlist request.
What the product showed
What was actually true
So the banner named the wrong object. It said "your organization disabled access." There is no organization on this account to disable it. Paying API credits does not create that organization. The restore path was pay the failed Max invoice, not create an org, not mint a new admin.
Ask
Do not need