By Mike Loukides
Mike Loukides recounts how a Claude skill he built to aggregate O’Reilly Radar–related content was unexpectedly blocked by Anthropic’s Sonnet real‑time safeguards. The episode illustrates how broad, conversation‑level safety filters can produce false positives, break working tools without warning, and reduce the practical usefulness of models.
What the skill did
The skill scanned roughly a dozen well‑known sites — for example The New Stack, The Next Web, and Hacker News — and produced a daily digest of the most important articles published in the last day. Loukides used it as a sanity check: had he missed anything important, or was he overlooking potential leading indicators?
He had been using the skill daily for months when it suddenly stopped with this error message:
API Error: Sonnet 5’s safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate cybersecurity work. Apply to the Cyber Verification Program to reduce these interruptions. Send feedback with /feedback or learn more: https://support.claude.com/en/articles/14604842-real-time-cyber-safeguards-on-claude
Investigating the failure
In a new Claude Code session using Haiku the skill ran fine; Loukides did not test Opus or Fable, but assumes Sonnet would have flagged those the same way. GPT‑5.6 with “high” reasoning also executed a very similar skill without issues. This suggested the problem lay with Sonnet’s safeguards rather than the skill itself.
Pasting the error into another Claude Code session and asking what happened, Loukides learned that Sonnet had reacted to certain descriptions in the conversation. In particular, the Hacker News description contained the phrase “vulnerabilities, exploits, threat reporting,” which triggered Sonnet’s guardrails. Ironically, that description was incorrect and had been generated by Claude.
Sonnet offered three remedies, including rewriting the skill with more neutral descriptions such as “security industry news.” Loukides edited the descriptions himself, but the original session remained dead — it would only repeat the error message, would not execute the skill, and would not commit the edited skill to his GitHub repository. At the same time, Sonnet was able to execute the same skill correctly in a new Claude Code instance.
Conversation‑level scoring and lost context
Sonnet explained that its security decisions are based on the entire conversation, not only the specific skill called: if the model deems a call potentially problematic, that call becomes part of the conversation and the whole context can be marked as unacceptable. The practical effect is that a single false positive can render an entire session unusable.
Two problems arise from this behavior:
- Stability: working programs can stop because environmental constraints outside the user’s control change. Teams and users depend on stable behavior; an AI ecosystem that breaks functioning tools unpredictably damages productivity.
- Lost context: if a mistaken alert causes the entire conversation to be invalidated, the accumulated, useful context disappears. Guardrails intended to prevent harm can end up preventing legitimate projects.
Balancing safety and usefulness
Loukides invokes the receiver operating characteristic (ROC) trade‑off: perfect classification is impossible. To ensure no true positives (real dangers) get through, you would have to reject everything; to eliminate false positives you would accept everything, including dangerous actions. The practical task is engineering a compromise that minimizes both kinds of error in a way that preserves utility.
The author does not deny the reality of abuse: prompt injection, articles describing malware like the Morris worm, or posts that could instruct harmful actions are genuine concerns. But treating reading reputable public sources as an automatic security risk — especially when the trigger may be an AI‑generated, incorrect description — is troubling.
Conclusions
Guardrails will always have unintended consequences. The ROC teaches that you cannot perfectly reject all dangers while never rejecting benign activity, but teams should still aim to approach the ideal as closely as possible. Currently, Loukides argues, the balance is off: overly broad and opaque safeguards make models and agents less useful rather than safer in practice. Malicious actors will find ways to do harm regardless; handicapping legitimate users is not an effective solution.
Note: the account is based on Mike Loukides’s firsthand experience with a Claude skill and Sonnet’s real‑time safeguards.
