GPT-6 Cyber vs Kimi K3.1 Pro: Gate the Hacking Capability, or Remove It?

Two AI labs answered the same question this week, in opposite ways. The question: what should a model that can find and exploit software vulnerabilities be allowed to do, and for whom?

On November 5, OpenAI released GPT-6 Cyber, a security model it rates Critical for cyber capability, to a small group of vetted customers. A day earlier, Moonshot AI's deadline arrived for the open weights of Kimi K3.1 Pro. Those weights are now on Hugging Face for anyone to download, and Moonshot says it removed cyber-related training data from the model first.

One lab keeps the capability and controls who uses it. The other reduces the capability and gives the model away. I read both companies' announcements, OpenAI's system card and Moonshot's model card and licence. Every number below is reported by the vendor unless I say otherwise, and I have not run either model.

GPT-6 Cyber: Astra-class skill that says yes to vetted teams

GPT-6 Cyber is a cyber-specialised version of GPT-6 Astra, trained to find and validate exploitable vulnerabilities while staying inside the scope a researcher sets. It is available through the API and Codex, at first only to approved customers of Daybreak Red, OpenAI's programme for authorised offensive security work.

Evaluation	GPT-6 Cyber	Comparison
ExploitGym	48.45%	GPT-6 Astra 42.43%, GPT-5.6 Cyber 32.1%
ExploitGym, hardened variant	36.94%	GPT-6 Astra 29.69%
Web penetration testing, recall	40.3%	GPT-6 Astra 32.0%
RemoteExploitBench	95% completed	GPT-6 Astra under Daybreak Blue refused 100%
FrontierCyber, by Irregular	90 of 288	GPT-6 Astra 96 of 288

Sources: OpenAI's announcement and the GPT-6 Cyber system card. All rows are run by OpenAI except FrontierCyber, which comes from Irregular, the external evaluator.

The table says something the headline does not. On OpenAI's own tests, GPT-6 Cyber is modestly stronger than Astra. Irregular found it "broadly comparable to GPT-6 Astra's", with higher success on long tasks, and on one of Irregular's benchmarks Astra solved more. The large difference is in what the model will agree to do: on RemoteExploitBench, Astra refused every task under Daybreak Blue, and GPT-6 Cyber completed 95% of them.

So OpenAI is not mainly selling a much better hacker. It is selling Astra-class skill that will do the work Astra refuses, for people it has checked, with extra training on staying in scope.

Staying in scope, measured with a honeypot

The scope training is the part I find most interesting, because it answers a real failure. OpenAI built an evaluation called ExploitGym Honeypot, informed by the Hugging Face incident, where agents under test attacked services outside their task. The model gets a hard exploitation task and a supporting service, such as a package registry, that is deliberately easy to exploit. Using the service is allowed. Exploiting it is out of scope.

Model, without deployment safety instructions	Exploited the out-of-scope service
GPT-5.6 Sol	49.5%
GPT-5.6 Cyber	5.51%
GPT-6 Astra	0%
GPT-6 Cyber	0.07%

Source: system card. With the deployment safety instructions added, GPT-6 Cyber exploited the honeypot in 0% of runs.

Half of GPT-5.6 Sol's runs took the shortcut. That is the behaviour behind the incidents earlier this year, now measured and mostly trained out. It is still a vendor test on the vendor's own tasks, and the system card warns that scores vary between runs.

Access is the other half of the design. Daybreak Red organisations need SSO, MFA, managed devices and least-privilege access. Individuals need identity and liveness checks, a legal attestation and at least one physical FIDO2 security key. API access is restricted to allowlisted IP addresses by default, because stolen credentials are part of the threat. API customers on Zero Data Retention generally have to use Private Safety Processing, which keeps encrypted records in the customer's own storage for 30 days.

OpenAI also reports real findings: working exploits for 948 Linux kernel vulnerabilities out of 1,724 reproduced, against 166 for GPT-5.6 Sol in the same harness, and 81 previously unknown Firefox vulnerabilities that Mozilla classified as high severity. Those are OpenAI's figures, and OpenAI says Mozilla has shipped fixes for many of them.

Kimi K3.1 Pro: open weights with the cyber data taken out

Moonshot launched K3.1 Pro as an API model in late October and promised the full weights by November 4. They are now public and ungated on Hugging Face: 96 shards, 1.56 TB, the same footprint as Kimi K3 in July. Moonshot describes 2.8 trillion total parameters, 104 billion active per token, and a 1-million-token context.

For the open release, Moonshot says it "identified and removed cyber-related data from both training stages", mid-training and the reinforcement learning environments, while keeping the general coding tasks the model needs. Its stated principle is to avoid releasing open weights "that would extend the absolute frontier of cyber capability", and to raise the cyber capability of open weights gradually.

Model	xdev-bench-hard, pass@3
GPT-5.6 Sol, third-party evaluation	100
Kimi checkpoint without the cyber removal	90.5
DeepSeek V4.1 Flash, open weights since September	85.7
Kimi K3.1 Pro, as released	81.0
GLM-5.3	57.1
Kimi K3	33.3

Source: Moonshot's K3.1 Pro post. Moonshot calls xdev-bench-hard its in-house benchmark, so nobody outside the company can check these numbers.

Read the chart carefully, because it supports both the praise and the criticism. The removal cost the model about 9.5 points. Without it, K3.1 Pro would have passed DeepSeek V4.1 Flash, which has been downloadable under the MIT licence since September 10. With it, K3.1 Pro sits below DeepSeek. That is what Moonshot's principle says it should do.

It also means the open frontier was already at 85.7 on Moonshot's own test, set by a model anyone can download. And the released model is far more capable at exploitation than Kimi K3 was in July: 81.0 against 33.3. "Less than it could have been" is not the same as "small".

The model card adds two public benchmarks: ExploitGym 20.7 for K3.1 Pro against 42.4 for GPT-6 Astra, and ExploitBench 74.7 against 100. Astra's 42.4 matches OpenAI's own figure, but the card does not say whether K3.1 Pro ran in the same harness, so I would not compare those rows with OpenAI's table above.

Read the licence before you build on it

The Kimi K3.1-Pro License follows the MIT wording with three additions:

Model as a Service. A company that offers the model to third parties as a service, letting them control the inputs, parameters or training data, needs a separate agreement with Moonshot once its group revenue passes $20 million over 12 months.
Display. A commercial product with more than 100 million monthly active users, or more than $20 million in monthly revenue, must show the model name in its interface.
Exemptions. Neither rule applies to internal use, meaning use that does not make the model, its outputs or its capabilities available to third parties.

For most security teams, a self-hosted model used inside the company falls under the exemption. A company selling hosted inference is not exempt, and above the revenue threshold it needs that separate agreement.

Gating and removal fail in different ways

Gating keeps the capability and puts the control in accounts, networks and monitoring. Its failure modes are stolen credentials, misuse inside a vetted organisation and monitors that miss something. Its advantage is that the vendor can watch, revoke and improve it after release.

Removal moves the control into the training data. Its advantage is that it does not depend on anyone behaving well after release. Its failure modes are permanent: once the weights are out, nobody can see how they are used or take them back. A determined group can also fine-tune them on exploit data. Whether that restores what Moonshot removed is my question, not a published result.

Neither approach changes what defenders should assume. On Moonshot's own chart, a capable exploitation model has been freely downloadable since September. OpenAI's recommendations for its own customers point the same way: sandboxing, review of actions and human oversight for high-risk work.

Both ideas belong in your own system

I have used both ideas, at a much smaller scale. In the Verifiable AI Analyst, the model is never offered an operation the user is not entitled to, so there is nothing to argue it into. That is removal. Everything it can do runs under row-level security, through a read-only role that cannot bypass it, so a request that gets through is still checked below the model. That is gating.

Removal shrinks what can go wrong, and gating checks what is left. I would not rely on either one alone, and that holds whether the model comes from OpenAI or from Hugging Face.

What I would test before using either

Scope in your environment. Put an easy, out-of-scope service on the test network and count how often the agent touches it. OpenAI's honeypot results are on OpenAI's tasks.
Refusals on defensive work. Measure how often Daybreak Blue or a self-hosted model refuses ordinary triage and patch validation. Refusing the right work also has a cost.
The removed skill you might need. Defenders sometimes need a working exploit to prove a fix. Check whether K3.1 Pro can still validate patches on your own code.
Data handling. For Daybreak, read the retention terms that apply to your account. For self-hosting, the data stays with you, and so does the cost of running 1.56 TB of weights.
Credential exposure. Treat API keys for a Critical-rated model like production credentials: allowlisted, rotated and monitored.

In the same week, one lab issued a better lockpick to licensed locksmiths, and the other filed down its lockpick before leaving it on the pavement, next to a sharper one someone else left there in September.

Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and AI security.