Every security team now runs a model somewhere in its stack. Most do not know which one, who can change it, or what happens to the data on the way to it.
That was an acceptable gap when the model only drafted emails. It is not acceptable now. Teams paste alerts, log excerpts, source code, and malware samples into these systems. The model has become part of the response path. So the question "which model" needs the same rigor as "which EDR."
Frontier models are built for the average customer
A frontier lab serves millions of customers. Its safety policy has to hold for all of them at once. That forces two things.
First, a refusal floor. The model hedges on questions that look dangerous in isolation. A defender asking how a payload works gets a lecture. A red team asking the same question gets the same lecture. The model cannot see your authorization, your incident ticket, or your job.
Second, a data policy written for the average customer. Retention windows, human review, and training use are set globally. Some providers now offer zero retention as an add-on or an enterprise tier. Many do not. When legal asks where the sample went, "we bought the enterprise plan" is the answer.
Neither of these is a flaw. Both are what a shared product looks like. The problem is that defenders are not the average customer.
The defender's failure mode is different
For a consumer product, a refusal is an inconvenience. For a defender, it is a time cost during an incident. The analyst rewrites the prompt, tries a different phrasing, or gives up and does it by hand. The clock keeps running.
Data retention is worse than an inconvenience. It is a decision the security team usually cannot make alone. If the model provider keeps prompts, then sending raw incident data requires a legal review. That review takes days. Most teams skip it by redacting first, and redaction is where context dies. The analyst who removes the hostnames is the analyst who removed the clue.
So the effective policy becomes: use the model on the least sensitive slice of the problem. That is the opposite of where AI helps most.
What open weights change
An open-weight model is a file you can run. Three things follow.
You control the guardrails. If your team is authorized to analyze malware, the model can be tuned to answer those questions. You write the policy, and you can show it to an auditor.
You control the data path. Run it in your own account or on a vendor that keeps nothing. Retention becomes a property of your architecture, not a clause in someone else's contract.
You control the version. A closed model can change overnight. A pinned open-weight model cannot. For anything in the response path, that matters.
None of this is free. You own the risk now. A model with fewer refusals will also answer questions it should not, and you are responsible for who can reach it. That is the trade: control for responsibility.
What to check before you pick one
Ask these before you sign anything.
Who can change the model under you? If the answer is "the provider, whenever they update," then treat it as a moving dependency.
Is zero retention real, or a tier? Ask for the architecture. Prompts that are "not used for training" are often still stored.
Can you point it at your existing tools? Anything OpenAI or Anthropic compatible saves months of integration work. Claude Code and the standard SDKs both speak those formats.
What is the model good at? A model tuned for chat is not a model tuned for reading a 400-line log at 3 a.m. Test it on your own incidents before you trust it.
Where we land
We run Boker Open for this reason. It is an open-weight model, served with zero data retention, built for defense work, and reachable through the same APIs your team already uses.
We are not arguing that closed models are bad. They are better at many things, and for plenty of teams the tradeoffs do not matter. We are arguing that for the security function, the model is part of the threat model. Choose it like you choose anything else in that path: by asking what it does with your data, who can change it, and whether it works when you need it at 3 a.m.