· Solveion · Perspectives · 5 min read
The model that refuses mid-incident
During a live security incident, the AI you depend on can decline to help, because the work of a defender looks a great deal like the work of an attacker. That is an argument for owning a model you control, not for abandoning safety.
Picture the worst hour of a security team’s year. An intrusion is live. Something is moving laterally through the network, and the people responding need to read a malware sample, trace how an exploit chained together, and understand what the attacker can reach next. They turn to the AI assistant they have come to rely on, and it declines. The request looks like the thing it was trained to refuse.
This is not hypothetical, and it is not rare. A recent study of thousands of real defensive-security conversations measured how often mainstream models refuse legitimate work: malware analysis was declined about a third of the time, and system hardening closer to half. The safety training cannot tell the difference between a defender studying an exploit and an attacker building one, because at the level of the request there often is no difference. The intent lives in the context, and the guardrail does not have the context.
The failure that makes no sound
There is a comforting version of this problem where the model refuses, you notice, and you route around it. That version is disappearing.
The same research found that the usual workarounds collapse the moment the model is acting as an agent rather than a chat partner. An autonomous system running part of your incident response does not surface a refusal for a human to override. It detects the intrusion, tries to analyze the malware, is quietly declined by its own safety layer, and continues as though nothing is wrong. The intrusion is still there. The tool simply failed to engage it, and reported nothing.
That is the part worth sitting with. A refusal you can see is an inconvenience. A refusal you cannot see, inside an automated pipeline, during the seventy-odd minutes it now takes a fast intrusion to reach your data, is a hole in the floor.
Why this is suddenly urgent
The timing is not incidental. Attacks have accelerated to a speed that assumes machine assistance on both sides. Palo Alto’s incident-response data has the fastest quarter of intrusions reaching data exfiltration in about 72 minutes, down from nearly five hours a year earlier. In July an autonomous agent breached Hugging Face’s own infrastructure, working through more than 17,000 recorded actions, and the responders fought back the only way that scaled: they pointed an LLM at the full attacker log.
So the defender’s AI is no longer a convenience. It is part of the response, and at machine speed there is not time to discover, mid-incident, that the tool has principles about the very work you need it to do.
The wrong lesson and the right one
It would be easy to read all this as an argument for the ungoverned models now circulating in large numbers, the ones stripped of every safeguard. We think that is the wrong lesson, and a dangerous one. The problem is not that safety exists. The problem is depending, in your most critical hour, on a model whose refusal behavior you neither set nor control, running on infrastructure you do not own, tuned to a risk appetite that is not yours.
The right lesson is ownership. An open-weight model that you host and tune is one you can align to your actual situation: it will engage with a malware sample because you have told it, in a governed and logged way, that analyzing malware is this team’s job. Recent security-specialized models make this practical rather than theoretical. Cisco’s Foundation-Sec, for instance, is an open-weight model built for exactly this work and designed to run on your own hardware, and the research around it suggests that reasoning ability, not scale, is what forensic analysis actually needs, which puts a capable, self-hosted defender well within reach for a normal organization.
This is not about removing the brakes. It is about being the one who decides where they are. A model you control still refuses things. It refuses the things you decided it should, for reasons you can audit, rather than surprising you in the one hour you cannot afford a surprise.
What we would tell a security team to do now
Two questions are worth answering before the incident, not during it. First, if a live intrusion required your AI tooling to analyze hostile code right now, would it, and how do you know? Most teams have never tested this, and the honest answer is usually a shrug. Second, does any part of your automated response depend on a model that could refuse silently? That is the one that ends careers, and it is findable in an afternoon.
If the answers are uncomfortable, the remedy is a defensive capability you own: an open-weight model, hosted where your data already lives, tuned and evaluated for the work your responders actually do, with its refusal behavior set deliberately and logged. This is precisely the kind of system we help organizations build and stand up to daily use. The worst hour of the year is a bad time to learn what your tools will not do. The time to find out is now, while nothing is on fire.