A master’s student at MIT builds LLM agents that fly a simulated spacecraft. The model keeps deciding he must be doing something military. That is one of the stories developers shared with VentureBeat on September 30, and it captures the problem with AI safeguards that flag routine work: the filter reads keywords, not intent, and the engineer pays for the mistake in lost time.
This matters now because agents are no longer a side tool. The JetBrains Developer Ecosystem Survey, which covered more than 15,000 professional developers between May and July 2026, found that 90% use AI coding agents at work at least weekly and 68% use them daily. At that volume, a small false-positive rate stops being an annoyance and becomes a line item.
What developers are actually reporting
The VentureBeat piece collects complaints from people working in aerospace, robotics and security. Alejandro Carrasco, the MIT student, said the model sometimes assumes military use because he works with a space department, and that Claude is “a lot more aggressive” than other frontier models. Martin Kemka said he hit a lot of blocks on robotics projects, even benign ones, especially when asking for real device parameters or hardware connections.
Elvis Saravia, co-founder of DAIR.AI, called the refusals “a big problem” and said he canceled his Anthropic subscription over them. Rohan Balkondekar of Xsolla said models “hate the word cyber” and that his team keeps open models such as Moonshot AI’s Kimi on hand for the moments when closed models refuse.
Four developers is an anecdote, not a measurement. Neither vendor publishes a false-positive rate, so nobody outside the labs can say how many hours are lost. But the pattern is consistent across very different fields: the work sounds dangerous, so it gets stopped.
Why the filters err on the side of blocking
The vendors are not hiding it. OpenAI told VentureBeat its safeguards “can slow, pause, or stop legitimate work,” including defensive cybersecurity. Anthropic acknowledged false positives too. Digital Applied documents that when Anthropic redeployed Claude Fable 5 on July 1 with a retrained cyber classifier, it blocked a reported jailbreak technique in over 99% of cases, and it also flagged benign requests more often during routine coding and debugging.
A classifier tuned to catch the worst misuse will catch some of your Tuesday afternoon too. Academic work points the same way: the Defensive Refusal Bias paper argues that safety-aligned models refuse legitimate defensive security tasks disproportionately, which means the people trying to protect systems often face more friction than the people attacking them.
What the vendors are doing about it
Anthropic’s answer is tuning. With Fable 5.1, it says its newest cyber safeguards block 60% fewer false positives, and Claude Code users should see around 60% fewer interventions per session, according to Anthropic. The model can now be used to discover vulnerabilities, but not to develop exploits. Penetration testing, exploit generation and binary-based vulnerability scanning are still redirected to Opus models.
OpenAI’s answer is identity. Daybreak is a trusted-access program: per OpenAI’s Daybreak documentation, it uses identity verification, monitoring, approved-use restrictions and legal attestations, with Daybreak Blue aimed at defensive work like secure code review, vulnerability discovery and incident response. OpenAI also says GPT-6 Astra and GPT-6.1 Sol are less likely than GPT-5-series models to refuse harmless requests.
Both approaches help, and neither removes the problem. Tuning shifts the error rate. Verification only works if your team qualifies and enrolls.
What overzealous guardrails cost an engineering team
The direct cost is interruption. An agent that stops mid-task forces a person to notice, reword the prompt, retry, or switch tools. Saravia’s reaction, switching providers, shows the second cost: teams start routing around the guardrail instead of through it.
Routing around has its own price. Balkondekar’s fallback to open models means code and context now flow through a model your security review may never have covered. When the safeguard is too blunt, shadow tooling is the predictable result.
There is also a budget angle. If a blocked request silently falls back to a different model, as Digital Applied describes for Fable 5 and Opus 4.8, the model that served the request may not be the one you thought you were paying for.
How to build for refusals instead of being surprised by them
Treat a refusal as a normal state of the system, the way you treat a timeout. A few practices follow from the evidence above:
- Branch on the API’s refusal signal, not on response text, and wire a fallback model so a blocked request retries instead of dying.
- Log which model actually served each request so cost and quality reports stay honest.
- Keep a short list of prompts and workflows that trigger false positives, grouped by vendor, so you know where friction lives before a deadline.
- If your work is defensive security, apply for the trusted-access program that fits it instead of fighting the default filter.
- Set a policy for fallback models, including open ones, before individual developers invent their own.
Digital Applied recommends the same core move for Anthropic’s API: design for model substitution as a standing condition, because the model you requested may not be the one that answers.
The bottom line
Guardrails are not going away, and they should not. But a safeguard that regularly interrupts a satellite simulation or a robotics project is a cost, and engineering leaders should measure it like one. Start by asking your team where the blocks happen this week, then decide which of them are worth a fallback, an enrollment, or a different vendor.