AI Guardrails Are Slowing Cyber Defenders as Well as Attackers

AI safety restrictions designed to keep models out of hackers’ hands are increasingly making it harder for legitimate cybersecurity researchers to do their jobs. Offensive security specialists and network defenders say the same guardrails that block malicious prompts often block real vulnerability analysis, slowing down work that is meant to harden systems before criminals can exploit them.

The concern has sharpened in the wake of U.S. export controls tied to Anthropic’s cybersecurity-focused models in June and the broader rollout of vetted access programs from Anthropic and OpenAI. Those systems were built to limit harmful use, but researchers interviewed in the wake of the controversy say the restrictions are often too blunt, too inconsistent, and too likely to interfere with defensive testing.

At the center of the debate is a difficult question for the AI industry: how do you prevent abuse without also making it harder for the people trying to stop attacks? Security specialists argue that today’s answer is often a patchwork of approvals, refusals and content filters that can frustrate even trusted users.

Why are AI guardrails becoming a cybersecurity problem?

They are becoming a problem because cybersecurity work frequently requires models to reason about exploitation, code weakness and attack paths — exactly the kinds of topics that safety systems are built to block. Researchers say that if a model refuses to examine a flaw or propose a proof of concept, it can obscure whether a bug is real, how serious it is and how it should be fixed.

The issue is not limited to a single vendor. Anthropic and OpenAI both run vetted-access programs that allow approved users to work with fewer cybersecurity limits. Anthropic calls its program Cyber Verification Program, while OpenAI offers Trusted Access for Cyber. But researchers say the approval process itself, and the day-to-day filtering inside those programs, still creates friction.

Security professionals say the tension is simple: the same tool that can help defenders understand a flaw can also be used to weaponize it, which leaves AI companies trying to draw lines that do not fit the realities of offensive research.

How do offensive researchers actually use AI?

They use it in different ways depending on the stage of the work. Some researchers rely on AI to reverse engineer unfamiliar code, explain software behavior, generate test scaffolding or help them understand a vulnerability’s context. Others say AI can be useful when they need to confirm whether a suspected issue can actually be exploited.

That second use case is where guardrails become most disruptive, researchers say. A model that refuses to answer a prompt about exploitability may force a human to spend more time manually reproducing the flaw or searching for alternative tools. In some cases, researchers say, it can make the model less useful than a conventional search engine or static analysis tool.

Chris Anley, chief scientist at NCC Group, described exploitation testing as a normal part of validation work. In his view, asking a model to reason through how a bug might be abused is not the same thing as asking it to assist in a crime; it is often the only way to determine whether the weakness is severe enough to merit urgent remediation.

According to Anley, the difficulty is that a prompt aimed at fixing code can also function as a guide to finding the most dangerous failure points in that same code.

What researchers say is broken about the current approach

Researchers who spoke publicly and privately about their workflows described a system that is often inconsistent, overcautious and time-consuming. The complaints fall into several broad categories:

• Overblocking: models refuse benign requests simply because the topic involves security.
• Inconsistency: the same prompt can yield different behavior from one day to the next.
• Workflow disruption: instead of helping with analysis, the model becomes something users must negotiate with.
• Limited access: vetted programs can be difficult to enter, especially for smaller firms or less visible researchers.
• Data sensitivity: cloud-based systems may be unsuitable for confidential exploit research.

Mark Dowd, a veteran security researcher known for finding and selling zero-day vulnerabilities to governments, criticized the idea that a handful of large companies should decide what is safe in security research. He noted that these firms are making judgment calls about a field where legitimate use and malicious use can look nearly identical from the outside.

Why do some researchers avoid cloud AI tools altogether?

They avoid them because exploit research often involves sensitive information that should not leave a local machine. Paolo Stagno, chief technology officer at CrowdFense, said his team uses frontier models primarily for reverse engineering, but not for vulnerability discovery or exploit development. For those tasks, he said, open-source models that can be run locally are safer because they do not require sharing secrets with a third-party cloud service.

Stagno’s concern reflects a broader tension in the industry. Researchers who are hired to identify unknown vulnerabilities often need to preserve those details closely, not only to protect their own work but also because disclosure policies, client contracts and government relationships can make cloud sharing risky.

Who is least affected by the guardrails?

Not everyone in offensive security sees the restrictions as a major obstacle. Giuseppe Cali, a researcher who finds zero-days and develops exploits, said AI is useful to him in earlier stages of analysis, especially for understanding unfamiliar code and building support tools. He said the restrictions do not meaningfully stand in the way of the parts of his process that matter most to him.

Cali argued that the most valuable part of exploit research is still the human process of discovering and weaponizing a bug. In his view, AI is a productivity enhancer, not a replacement for the craft.

Cali said he likes keeping the core bug-finding work for himself and would not want models to take over that part of the job even if every guardrail disappeared.

How companies are handling the pushback

AI companies have not ignored the criticism. Anthropic and OpenAI both created security-focused access programs to give approved users a more permissive environment than the public version of their models. In theory, these programs are meant to preserve the benefits of AI for defenders while limiting obvious misuse.

In practice, researchers say the programs are still far from seamless. Access can be restricted to organizations that meet a company’s criteria, and even accepted users may encounter refusals when prompts move too close to exploit development. That creates a fragmented landscape in which some teams can do meaningful work while others are forced to rely on fallback tools.

Anthropic’s models have also been at the center of policy attention. In June, the U.S. government imposed export restrictions on certain Anthropic systems after a report suggested the models’ protections could be bypassed. Those restrictions were later relaxed: Fable 5 returned to general access on July 1, while Mythos 5 was made available only to vetted U.S. organizations during a review process.

What happens when guardrails get in the way?

Researchers say the practical consequence is wasted time and reduced output. Instead of analyzing a flaw, they can end up tuning prompts, testing phrasing or trying to figure out why a model keeps refusing to answer. That is a poor use of scarce talent in a field where speed matters.

Chris Thompson, chief executive of RemoteThreat and founder of Offensive AI Con, said the inconsistency can be especially frustrating. Even inside vetted programs, he said, the models may behave differently from one session to the next, forcing users to spend time adapting to the model rather than solving the security problem.

Thompson said researchers can end up wrestling with the model’s filters and over-sanitized responses instead of focusing on vulnerability analysis and exploitability.

For smaller teams and independent specialists, that friction can be enough to push them toward open-source alternatives. Thompson said many researchers end up using freely available Chinese models such as GLM because they can be run locally and do not require approval from a U.S. vendor.

Why are local open-source models gaining ground?

They are gaining ground because they are easier to control. A local model can be run offline, kept inside a lab environment and customized for a researcher’s exact needs. There is no waiting for vetting, no concern that sensitive data will be sent to a vendor and no sudden refusal because a prompt triggered a safety filter.

That advantage comes with trade-offs. Open-source systems may be less capable than frontier models, may require more setup and may lack the polish of major commercial offerings. But for researchers who value consistency and privacy over convenience, they are becoming the default backup plan.

What does the industry want instead?

Many offensive security researchers are not asking for a free-for-all. They want more predictable access, clearer rules and systems that distinguish between malicious intent and legitimate testing. The ideal model, they argue, would let vetted researchers use powerful tools without turning every security-related prompt into a compliance event.

Thompson said frontier labs should widen access for responsible users while also going after bad actors directly. In his view, over-restricting legitimate researchers leaves defenders less prepared for the scale and speed of the next wave of attacks.

That argument reflects a deeper strategic concern: if AI becomes central to both offense and defense, then limiting defenders too aggressively could hand an advantage to the very actors the restrictions were meant to stop. In an environment where attackers are expected to automate more of their workflows, some researchers fear that overcautious safety systems could become a competitive handicap.

How the timeline unfolded

The policy dispute around AI guardrails and cybersecurity has developed quickly over the past year. The sequence below shows the key milestones that put the issue in the spotlight.

Why this debate matters beyond niche security circles

This is not just a dispute among hackers and AI product teams. The way companies and regulators handle cyber guardrails will shape how quickly enterprises, governments and security firms can adapt to increasingly automated threats. If trusted users cannot use AI effectively for testing and research, then the ecosystem that defends digital infrastructure may end up weaker than intended.

At the same time, the concerns driving the restrictions are real. AI models that make it easier to write malware, probe systems or refine exploits can lower the barrier to entry for criminals. That means the challenge is not whether to impose guardrails at all, but how to make them selective enough to block abuse without stalling legitimate defense.

For now, researchers are improvising. Some are switching to local open-source models. Some are sticking with frontier systems and accepting the friction. Others are simply using AI less than they otherwise would. None of those outcomes looks ideal to the people who believe the next era of cybersecurity will depend on AI-assisted analysis.

The tension is likely to intensify as model makers continue to market systems with specialized safety controls while offensive security professionals keep arguing that those same controls can distort the work they are meant to support. The question now is whether vendors will refine access in a way that distinguishes between dangerous intent and essential defensive testing — or whether researchers will keep voting with their workflows and moving elsewhere.