What Is a Cyber Model? The Category, and What It Actually Changes

Three products get called a "cyber model" every week and they have almost nothing in common. One is a generalist with security corpora in its training mix. One is an ordinary model wrapped in a loop that gives it a sandbox, a fuzzer and retries. One is the same model as everyone else's, behind a verification form. Only the first of those is a different model. The other two are product decisions — good ones, in some cases — and they are marketed with the same phrase, which is why the category resists comparison. A benchmark table that does not say which of the three it measured cannot be compared with one that does, and most tables do not say. This is a guide to the distinction, to the small number of models that genuinely sit in the first category, and to what a security team should do with the answer. It is also the category view that sits behind the 400 agent incidents catalogued in the AI incident archive, where the question "was the model the problem or the deployment" comes up constantly.

The three things the phrase covers

Start with the difference that matters operationally: what changed when the vendor built the thing.

Trained for security means the weights changed. Security corpora went into the training mix, the base is often a generalist that was already strong, and the resulting model is measurably different at tasks where security knowledge is the bottleneck — reading a crash, reasoning about memory layout, recognising a vulnerable pattern across a large diff. Models in this group are usually reported against security-specific benchmarks such as CyberGym or CyberSecEval, and they can be open-weight or API-only.

Wrapped in a harness means the loop changed and the model did not. The vendor added a sandbox, tools, retry logic, a planner, maybe a fuzzer, and built a system that performs well at security tasks because the system is well engineered. This is a legitimate and often underrated product. It is also the category where a score becomes ambiguous, because the number belongs to the harness as much as to the model — and the harness is not something you can swap independently.

Gated by access means the door changed. The model may be identical to a public one; what is different is that you must be a verified business, doing authorized work, under terms that restrict use. This is a policy product, and a defensible one, but no capability claim follows from it. A model that is dangerous in the wrong hands and safe in the right ones has not become more capable; it has become more controlled.

The practical consequence: when you read that some model is "a cyber model", the next question is which of the three, because the answer determines whether you are buying capability, engineering, or permission — and those have different prices and different failure modes.

Why the category exists at all

Security work is unusually sensitive to two properties that general models exhibit inconsistently: long-context reasoning over code that was not written to be read, and the willingness to describe an attack in enough detail to be useful. The first is a capability question and is why models in this group tend to advertise context windows in the hundreds of thousands or millions of tokens. The second is a safety question, and it is the reason the category is entangled with access control.

A model that reasons well about a codebase but refuses to write a working proof-of-concept is useless for triage, because the proof-of-concept is the evidence. A model that writes proof-of-concepts freely is useful to a defender and equally useful to someone who is not one. Cyber-tuned models are, in effect, an attempt to resolve that tension by narrowing who may ask rather than narrowing what may be answered — which is a coherent design and a hard one to enforce at the model layer, since the enforcement is a verification process rather than a weight change.

Where the capability is actually argued

The claimed advantages of cyber-tuned models are specific and checkable, which is refreshing in a field that usually argues in adjectives. The ones that recur are long-context ingestion of an entire repository or audit trail in one pass, structured output for pipeline use, and tool or function calling stable enough to sit inside an automated workflow. Those are engineering claims as much as model claims, and they are testable against your own corpus in an afternoon.

The evaluation side has grown institutions of its own. Wiz Research runs a Cyber Model Arena that evaluates AI agents composed of a foundation model plus a standard harness across real-world cybersecurity tasks, and reports model quality against efficiency — success rate plotted against cost, time or steps per solve over k independent attempts. That framing is worth adopting wholesale, because it captures the thing a raw pass rate hides: two agents can reach the same success rate at very different cost per solve, and the expensive one is often the one that spent its budget on retries.

Note what that construction implies. It is a benchmark of agents, not models — foundation model plus harness — which is exactly the ambiguity the category has. The arena is honest about it by naming the harness in the definition. Most launch posts are not.

The access gate, and why it is the category's real boundary

If you look at how cyber-tuned models are actually delivered, the verification gate is more defining than any benchmark number, because it determines who can run the evaluation at all. The pattern is consistent: a business-verification step, terms that restrict use to authorized security work, and an acceptable-use policy that the access is logged against.

Two design details in that pattern are worth stealing even if you never buy a cyber model. The first is business verification rather than self-attestation, because a checkbox is not an accountability mechanism. The second is co-locating the gate with the runtime controls — the same gateway that holds the model also holds the firewall, the guardrails and the logging, so that the permission and the enforcement are in one place. A verification gate that lives on a different system from the traffic is a gate you cannot audit.

Our own cyber tier follows that shape: models for offensive work, gateway controls for defensive work, and verification in front of both. It is also the honest answer to "can I just call this model" — for the offensive tier, the answer is that access is a decision someone makes about you, not a field in an API request.

Which cyber models exist, and how to tell them apart

The population is small enough to hold in your head, and it divides by the three categories above rather than by vendor.

• Genuinely cyber-tuned models. Trained with security-heavy data, usually reported on CyberGym or CyberSecEval, with a measurable difference in crash-reading and patch-writing tasks. Some are open-weight, which makes local evaluation possible; some are API-only under verification.

• Generalists with strong security behaviour. Frontier models that happen to be good at the work without having been tuned for it. Often the correct choice for defenders, because the same model does the rest of the job too.

• Agent products. A model plus a security-specific loop — sandbox, fuzzer, planner — sold as a system. Judge these on cost per solve and on what the loop does when it fails, not on a model benchmark.

• Gated versions of the above. Same models, restricted access. The gate changes who may use them, not what they can do.

The comparison that actually matters for a security team is rarely model versus model. It is whether the work you need done is knowledge-bound or loop-bound. Reading an audit report and reasoning about an exploit chain is knowledge-bound and favours a tuned model. Running a fuzzer for six hours and triaging the crashes is loop-bound and favours good engineering. Most real programs need both, which is why the useful procurement question is "which of these two jobs am I buying for" rather than "which model scores higher".

What to ask before adopting one

Five questions separate a category decision from a marketing one.

• What changed — weights, loop, or access? The vendor should be able to answer in one sentence. If the answer is "the loop", evaluate the product as a product.

• Which benchmark, run by whom, in which harness? A CyberGym number without the harness is a number about a configuration you cannot reproduce.

• What is the cost per solve, not the pass rate? Wiz's framing is the right one; two agents at the same success rate are not the same purchase.

• What does the gate do when I fail it? Any deployment that depends on verified access should tell you what happens on a false negative, because your own engineers will be the false negatives.

• What can it not do? The defensive-only variants document their own limits, and that documentation is a feature — a model that cannot be turned to offense is a different risk object from one that can.

The category is real, the capability differences are real, and most of the confusion comes from three different products sharing a name. Once you separate the weights from the loop from the door, the comparison tables stop being contradictory and start being about different things — which is the only condition under which a security team can make a decision with them.