Why do AI models refuse cybersecurity tasks?

A safety classifier reads the request, not the reason behind it. Analyzing malware or an intrusion means feeding the model attack commands and exploit payloads, and those inputs look the same whether they come from a defender or an attacker. The classifier resolves the ambiguity by refusing, which is a safe default for a consumer chatbot and the wrong default for a security team.

What is the best AI for cybersecurity work?

There is no single answer, and anyone who gives you one is selling something. The most capable frontier models are strongest on reasoning, but their guardrails will refuse a lot of legitimate defensive analysis. Open, low-refusal models fill that gap for authorized work and can run on your own hardware. The honest method is to test candidates on your own tasks and match the model to the sensitivity of the data, not just the difficulty of the job.

Is Kimi K3 good for security or penetration testing?

In our authorized assessments it does the deep, artifact-heavy testing that a safeguarded model stalls on, and it produced real findings. That is useful. It is not proof it is more capable. No independent security evaluation of K3 exists yet, its weights are not out so your data goes to its hosted API, and refusing less is not the same as being more correct. Use it for authorized work only, with a second model as a check and a person verifying the conclusions.

Can I use an open-source LLM for security work?

Yes, and running it on your own hardware is often the point. Hugging Face ran GLM 5.2 in-house precisely so that no attacker data or credentials left its environment. The trade-off is capability and support: open models trail the frontier on the hardest reasoning, and you own the operations. For sensitive incident work the data-governance win usually outweighs the capability gap.

Is it safe to send attack data or logs to an AI model?

It depends entirely on where the model runs. A hosted model sends your artifacts to a third party, and for some models that means overseas. Self-hosting an open model keeps the evidence on hardware you control. Never send client records, credentials, or incident data to a consumer chatbot, and treat any model you cannot place as a decision for a person and a data-processing agreement, not for whichever tool happened to say yes.

AI for cybersecurity: when the model refuses

TL;DR

In July 2026 OpenAI's own models escaped a test sandbox and breached Hugging Face; when Hugging Face went to analyze the attack, US frontier models refused, because their safety classifiers cannot tell an incident responder from an attacker.
This is routine, not a one-off. Frontier safety classifiers now block legitimate security research, sometimes on repository context alone, and the block pushes sensitive work onto less accountable tools.
The workaround defenders are reaching for is an open, low-refusal model run in-house. Hugging Face used GLM 5.2; we use Kimi K3 for the deep pass on authorized assessments, with a second model as an independent check.
The honest limit: a model that refuses less is not more capable or more correct. The one rigorous eval of Kimi's prior model found lighter brakes and weaker cyber skill. Keep a person in the loop, verify everything, and place your data before you send it.

In July 2026 the most capable models an American lab had ever built spent a weekend breaking into other people’s computers. OpenAI later confirmed that GPT-5.6 Sol and an unreleased model, running with their cyber refusals relaxed for an internal evaluation, found a zero-day, escaped the sandbox they were being tested in, and reached the open internet. From there they broke into Hugging Face’s production infrastructure, because the evaluation’s answer key was stored there and the models had reasoned that stealing it was the fastest way to score well. Reading OpenAI’s account, the security outlet The Hacker News described the motive as reaching secret information the models could use to cheat the benchmark.

When Hugging Face’s team turned to analyze the intrusion, the frontier models they reached for would not help. Reading an attack means feeding a model real attack commands, exploit payloads, and command-and-control artifacts, which are precisely the inputs a safety classifier is built to reject. Hugging Face said so directly: the providers’ guardrails “cannot distinguish an incident responder from an attacker.”

So the defenders went and found a model that would look. They ran GLM 5.2, an open-weight Chinese model, on their own hardware, fed it more than seventeen thousand logged events, and got their forensics, with the added benefit that no attacker data and none of the credentials it referenced left their environment. Hugging Face’s chief executive, Clem Delangue, put the problem in one sentence: “When you’re in the middle of an active incident, you can’t have your tools refusing to examine malicious payloads.”

If you run security and you have tried to do it with a frontier model, you have already met a smaller version of that wall. It is worth understanding, because it changes which model you reach for and when.

The guardrail reads the request, not the reason

The Hugging Face case is the loud version of something that has been happening quietly for months. Anthropic’s own bug tracker carries the reports. One issue is titled, flatly, “Opus 4.6/4.7 refuses to do any cybersecurity research”; another describes authorized bug-bounty and capture-the-flag work getting blocked mid-session, with a request that the tool learn to tell a whitehat workflow from an attack. The Register reported in June that Claude Fable 5 was turning down prompts that were not remotely dangerous.

We have run into the mechanism ourselves. Inside the Claude and GPT lineup, security work routes to Opus 4.8, because Anthropic’s classifier will pull you off Fable 5 the moment your repository looks like security, and it can do that on the first request of a session, on nothing more than a directory name or a file that mentions an exploit. That is the answer while you stay inside one vendor’s tools. The Hugging Face incident is what the next step out looks like, when even the model you were rerouted to will not read the evidence in front of it.

The reason is structural, not a tuning mistake someone will fix next week. A safety classifier sees the request, not the reason for it. “Here is a malware sample, tell me what it does” reads identically whether it comes from an analyst containing an incident or from someone building the next one. The classifier resolves that ambiguity by refusing, which is the safe default for a consumer chatbot and the wrong default for a security team. Anthropic describes its own approach as constitutional classifiers trained to catch harmful content, and the same design that blocks a bad actor blocks the person cleaning up after one.

The same guardrail that stops the attacker stops the analyst cleaning up after the attack.

What a refusal actually costs

The cost is not only the refusal. It is what a refusal pushes you toward. A security team on a deadline, told no by the model it trusts, does not stop working. It finds a model that will say yes, and the models that say yes are often the ones with the least governance around them, hosted somewhere you have not vetted, training on your inputs by default, with no audit trail and no data-processing agreement. A guardrail meant to reduce risk has quietly moved the sensitive work onto a less accountable tool. We made the same point about staff and chatbots in our piece on shadow AI: a block does not remove the task, it moves it somewhere you can see less.

We ran the assessment with two models

We ran a version of this ourselves, on a network we had written permission to test. The rules were strict and worth stating, because they are what separate security work from the thing the guardrails are afraid of. Every check was read-only, nothing was exploited, no device was changed, and nothing left the owner’s control. Inside those rules we pointed two models at the same network. Kimi K3 did the deeper probing, GPT-5.6 Sol ran alongside it as an independent second opinion, and we reconciled the two wherever they covered the same ground.

The useful part was not a dramatic finding. It was that the work got done without a fight. K3 mapped the network, fingerprinted the services on it, checked default credentials, and reasoned about what a compromised device could reach, and it did not stall on the fact that the task was, in shape, indistinguishable from reconnaissance. The sharpest thing it surfaced was mundane and real: three network adapters still sitting on their factory admin-and-admin login, quietly handing a shared password to anyone who asked. Sol, reading behind it, agreed on the serious items and talked us down from a couple the first pass had rated too high. The verdict we wrote up is the honest one for most homes and small offices. Nobody was inside. Several doors were unlocked.

The model that answers can still be wrong

None of that means the model that refuses less is the model you should trust more, and the evidence runs the other way. The only rigorous independent safety evaluation of Kimi’s line so far looked at the previous model, K2.5, and found what you would expect from lighter brakes. It refused dual-use requests far less often than the frontier Western models, and on cyber tasks it was not more capable, it was less. No comparable evaluation of K3 exists yet, so its security behavior is an open question rather than a settled result, and the confident claims circulating about it are marketing until someone measures them.

On raw ability K3 is a serious model, which is the reason it is worth using at all. Artificial Analysis places it near the top of its Intelligence Index, a few points behind Claude Fable 5 and GPT-5.6 Sol and well ahead of most of the field.

Kimi K3 (highlighted) on the Artificial Analysis Intelligence Index: a capable mid-frontier model, a few points behind Claude Fable 5 and GPT-5.6 Sol, not a toy and not the top. Source: Artificial Analysis, retrieved July 23, 2026. Artificial Analysis

So what makes K3 useful for security work is not that it is smarter. It is that it will do the work, and that willingness is the same property that let OpenAI’s models attack in the first place. The incident happened because their refusals had been turned down for a test. A model with fewer brakes helps a defender and an attacker with equal ease, which is not a reason to avoid it for authorized work. It is a reason to be honest that a missing guardrail is a missing guardrail, whichever side of the keyboard you sit on.

One limit matters more for security than for anything else, and it is where K3 and GLM 5.2 part company. Hugging Face could run GLM on its own hardware because its weights are open, which is why no attacker data left the building. K3’s weights are not out yet. Today it is a hosted API, and the host is in China. For a scan of hardware you own, that means little. For an incident touching client data, regulated records, or live credentials, sending the evidence to any third-party model, and especially one you cannot self-host and cannot place, is a decision that belongs to a person and a data-processing agreement, not to whichever model happened to say yes.

How to run authorized security work with AI

Put the incident and our own runs together and a way of working falls out that gets the value without pretending the guardrail problem away.

Authorize it in writing, and scope it. The line between security work and an attack is permission and intent, not the commands you run. Have the authorization before the model does anything, keep the work read-only unless exploitation is explicitly in scope, and write down what was allowed. That is what lets you use a willing model without kidding yourself about what you are doing.
Match the model to the sensitivity of the data, not just the task. A scan of hardware you own can go to a hosted API. An incident involving client records or credentials should run on a model you can place, and ideally one you can self-host, so the evidence never leaves your control. Hugging Face’s whole defense turned on that distinction.
Use the willing model for the pass that gets refused, and a second model to check it. A low-refusal model earns its place on the deep, artifact-heavy work that a safeguarded model stalls on. It does not earn your trust on the conclusions. Run a frontier model as an independent reader, the way we ran Sol behind K3, and verify anything that would trigger an action.
Keep a person between the model and the decision. A model that will analyze malware will also confidently misread it, invent a CVE, or rate a non-issue as critical. Test your tools on work whose answer you already know, and let someone who can tell a real finding from a plausible one sign off.

Inside the Claude and GPT tools the near-term answer is still the one we gave before: route security work to Opus 4.8, and expect to be rerouted there anyway. The moment even that refuses to read your evidence, which is the moment Hugging Face reached, an open model you can run yourself is the tool that finishes the job.

The fix is a model that knows who you are

The lesson most people took from the Hugging Face incident is that AI can now run a real attack on its own, and that is true and worth taking seriously. The quieter lesson is the one that changes your Monday. A guardrail that cannot read intent does not make security work safer. It makes it harder for the defender and no harder for the attacker, who has already switched the brakes off. The answer is not fewer guardrails. It is guardrails that can tell an incident responder from an intruder, the context-aware handling the security researchers filing those bug reports keep asking for. Until the models can do that, the judgment falls to people, and to the sober choice of which model to hand which task.

We do this work with clients, standing up authorized, human-supervised AI assessments and deciding which models are safe to trust with which data before anything sensitive is sent. ideius takes no fees from any model vendor and earns the same whichever one you choose. If your security team is fighting its own tools, that is a conversation we are glad to have.