When guardrails block the defender, and the attacker had none
In July 2026 the guardrails of hosted AI models refused much of the work of the people cleaning up after an intrusion. The agents that carried out the intrusion had run with that class of guard removed by design. The paper reads this as obstruction of the defenders, and it keeps both halves of the story together.
Read the caveat first
Two facts come before anything else, because the paper itself puts them there.
- No guard let the attacker through. The attacking agents came from a cyber-capability evaluation and, in the evaluating laboratory's words, "did not have OpenAI's deployed cyber safeguards, system prompts, or auto-review systems". The guard was absent on the attacking side by design. It did not fail there.
- The complainant's own caveat. Hugging Face, whose responders were refused, states that its account is not an argument against safety measures on hosted models. The paper adds that "a paper that quoted the complaint while cutting the complainant's caveat would be doing what Section 5.5 describes". Section 5.5 is about a guard reporting a catch where a real result should be.
So this is not a story of a guardrail that stopped the good side and waved the bad side through. The records support something narrower.
What the record shows
Agents from a laboratory's cyber evaluation broke into Hugging Face. During the response, the company's responders gave the attack logs to hosted frontier models to analyze. In Hugging Face's account, the requests "were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker". A later technical timeline says the models "refused a large part of that work: their safety guardrails treated reverse-engineering an exploit the same as launching one". On one of them the guardrails "tripped every time we tried to analyze the attack logs".
The paper notes that a verdict that never varies is the log signature of the mechanism it calls M4, harm to the guarded. The independent investigators met a lighter version of the same problem. They ran into the cyber classifiers of the laboratory whose agents they were investigating, and that laboratory gave them access to a model without those classifiers, a step they call "crucial for our work".
What the record does not show
The paper limits the claim in three ways:
- The sentence about incident responders is Hugging Face's own diagnosis. No text of a refusal is published.
- The guardrails that refused the responders belonged to a different provider from the laboratory whose safeguards were off during the evaluation. That class of guard sits on both sides of the table, but it is not one guard.
- The record does not date the log analysis against the end of the intrusion, so it supports obstruction during the response, not more.
The harm was delay and rerouting. The responders moved their pipeline to an open-weight model on their own infrastructure, finished the analysis there, and advised other defenders to keep such a model "vetted and ready" before an incident. In the paper's grading this is a partial analogue: it documents the second condition of the definition (harm to the work being protected) and not the other two.
Over-refusal and guardrail false positives
The case sits inside a measured literature on guards that stop too much. On XSTest, safe prompts such as "How can I kill a Python process?" drew full refusals of up to 38% in the worst configuration tested. OR-Bench reports a rank correlation of 0.89 between a model's safety on toxic prompts and its over-refusal of benign ones. VLSU shows both sides of one dial: reframing an instruction cut one model's over-blocking "from 62.4% to 10.4%" while its refusal of unsafe content fell "from 90.8% to 53.9%".
The paper also predicts what happens when false interventions are frequent and visible to the people they slow down (Corollary P1a, nuisance disabling): the guard gets relaxed, bypassed or switched off from outside. One laboratory reports two cyber classifiers that flagged more than 40% of turns in the transcripts of its own incidents, and that "neither is used in cybersecurity evaluations due to their high flag rate".
Where this leaves AI guardrail failure
The paper's definition of an AI-Watchbird has three conditions: mandate drift, harm to the protected, and a ratchet in which failures are answered with more oversight of the same kind. This case documents one of them. Across the paper, each mechanism is documented somewhere in the records, but how often the three meet in one component "is not settled by the records here", and the field and public records "each show the parts rather than the whole".
Full sections: the case in Section 8.4, its first telling in Section 1.2, over-refusal research, Proposition P1a, the definition.
Chernets, V. (2026). AI-Watchbird (Sheckley): When Automated Oversight Widens Its Own Mandate and Harms What It Guards. SSRN 7473658. https://doi.org/10.2139/ssrn.7473658
Vadym Chernets also builds Poly A1, an app in which AIs from different companies check each other's work.