AI Cyber Guardrails Are Frustrating Some Offensive Security Researchers, TechCrunch Reports

Cybersecurity researchers who test systems for vulnerabilities say AI safety guardrails are sometimes blocking legitimate security work, according to a TechCrunch report based on interviews with offensive security professionals. The concern is not simply that models refuse harmful requests; it is that the same techniques used to validate and fix flaws can resemble the steps an attacker would take.

The report focuses on a difficult policy boundary for AI labs, security teams and governments: how to restrict malicious use of powerful models without making them less useful for defenders, exploit researchers and vulnerability analysts.

The policy conflict

TechCrunch describes a growing tension around vetted access programs and stricter model behavior from major AI providers, including OpenAI and Anthropic. Both companies have created paths for certain cybersecurity users to request access with fewer restrictions: OpenAI’s Trusted Access for Cyber and Anthropic’s Cyber Verification Program.

The premise of those programs is that cybersecurity is a dual-use domain. A model that helps analyze a bug, reverse-engineer code or reason about exploitability could help a defender prioritize a patch. The same capability could also help an attacker weaponize a weakness.

Researchers quoted by TechCrunch argue that the current implementation can be too blunt. Chris Anley, chief scientist at NCC Group, told the publication that asking a model to test whether a bug can be exploited may be part of proving the issue is real and worth fixing. If the model refuses at that stage, the refusal can obstruct defensive work rather than prevent harm.

Key facts

Why researchers say the guardrails matter

Several researchers interviewed by TechCrunch described practical friction rather than a single, uniform failure. Chris Thompson, chief executive of RemoteThreat and founder of Offensive AI Con, said model behavior can be inconsistent even inside looser access boundaries. In his account, researchers may spend time trying to understand why a model over-sanitized an answer instead of analyzing the vulnerability itself.

That matters for security teams because vulnerability research often depends on iteration. A researcher may need to understand whether a flaw is reachable, whether a proof of concept is reliable and whether a fix actually removes the risk. If the model blocks that reasoning because it detects security-sensitive language, the tool becomes less predictable for professional workflows.

The report also includes a view from a researcher at a smartphone-component manufacturer, who spoke anonymously because they were not authorized to talk to the press. That person said Anthropic’s tools were barely useful for vulnerability discovery at their employer because the organization was not part of Anthropic’s Cyber Verification Program.

Why some work moves to local models

The TechCrunch article points to a second factor beyond refusals: data sensitivity. Paolo Stagno, chief technology officer at CrowdFense, said his team uses frontier models for reverse engineering but avoids using them to find vulnerabilities or build exploits because submitting sensitive vulnerability data to a cloud-based system creates leakage and training-data concerns.

That concern is familiar to enterprise AI buyers. Even when a provider offers privacy commitments, some categories of security research are too sensitive for external processing. Unknown vulnerabilities, exploit chains and customer code can carry operational, legal and national-security implications.

As a result, some researchers said they use open-source models locally. Local deployment can reduce data-sharing concerns and remove provider-level guardrails, but it also shifts responsibility to the organization running the model. For ReviewArticle readers evaluating AI tools, the takeaway is not that local models are automatically safer; it is that security, governance and capability trade-offs differ sharply between hosted frontier systems and self-managed models.

The government access backdrop

TechCrunch also connects the debate to government scrutiny of advanced cyber-capable AI systems. The report says the U.S. government placed export-control restrictions in June on Anthropic’s Mythos and Fable models, at least partly following concerns about guardrail bypasses. It adds that those controls were later lifted for Fable 5, which returned to general access on July 1, while Mythos 5 was reintroduced only to vetted U.S. organizations as part of a government review process.

Those details are significant because they show the policy debate is not limited to product design. Model access, export controls and national-security review are becoming part of how advanced AI systems are distributed. For developers and security vendors, that means product planning may depend not only on model quality and price, but also on access terms, compliance status and program eligibility.

What remains unclear

The report does not establish a complete benchmark of how often OpenAI or Anthropic models refuse legitimate cybersecurity prompts, nor does it compare refusal behavior across model versions in a controlled test. It also does not include enough information to determine whether specific refusals were caused by provider policy, organization-level settings, prompt wording or changing model behavior.

That limitation matters. Offensive security researchers have strong incentives to seek maximum model capability, while AI labs have strong incentives to prevent abuse and regulatory backlash. Both positions can be reasonable at the same time. The unresolved question is whether current guardrails are precise enough to distinguish professional defensive work from harmful requests at production scale.

What AI teams should check next

Security leaders using AI tools should review whether their current providers offer vetted cybersecurity programs, what data is retained, whether sensitive prompts can be excluded from training, and how refusal behavior is documented. Teams evaluating local open-source models should test not only capability, but also logging, access control, isolation and internal policy enforcement.

The immediate practical issue is procurement risk: a model that performs well in general coding tasks may still fail in vulnerability triage if guardrails are too restrictive or inconsistent. Before standardizing on a hosted or local AI stack for security work, teams should run controlled tests using sanitized examples that reflect their real workflows.

Source: TechCrunch, “How AI guardrails are impeding the work of offensive cybersecurity researchers” — https://techcrunch.com/2026/07/23/how-ai-guardrails-are-impeding-the-work-of-offensive-cybersecurity-researchers/