A few lines of text bypass Kimi K3.1 Pro's safeguards

What we tested

We asked whether Kimi K3.1 Pro can be pushed into helping with chemical, biological, radiological, nuclear and explosive (CBRNE) threats and cyberattacks. We focused on attacks within reach of a low- to medium-skill actor: someone with basic familiarity with language models, access to AI coding agents, and some programming ability, but no specialist expertise in machine learning security or in the threat domains themselves.

We didn't retrain or otherwise modify the model, so every result applies to Kimi K3.1 Pro exactly as Moonshot AI released it. An AI agent we built to search for attacks designed and tested 76 jailbreak strategies (ways of crafting an input so the model ignores its safeguards), and we added seven hand-written and publicly circulating variants. Except for publicly circulating attacks, most jailbreak approaches are common strategies, as they might be found in research papers or suggested by AI systems. Three automated evaluators then checked each response: whether it complied with the harmful request, whether it addressed what was asked, and whether it reached the level of detail a scoring rubric specifies. An attack counted as successful only when all three agreed. We report best-of-five results, meaning an attack succeeds if the model complies at least once across five tries of the same request.

What we found

Direct requests fail, but low-effort attacks already work

A publicly shared jailbreak that succeeded on 32% of requests against Kimi K3 now fails almost entirely on K3.1 Pro. However, another public jailbreak achieved 16% success as published, increasing to 36% after just 30 minutes of adaptation, demonstrating that comparable success remains achievable with minimal effort. More sophisticated attacks can exploit Kimi K3.1 Pro's interactions with external tools by spoofing tool responses, achieving an 84% attack success rate, though they require greater attacker effort.

Writing the start of the reply breaks safeguards in every domain

Like many recent models, Kimi K3.1 Pro writes out its reasoning about a request before giving its visible answer. A response prefill attack supplies the first words of the model's output, so the model continues a reply that has already started instead of deciding from scratch whether to help. Anyone who runs the downloaded model controls everything it reads, including those first words.

We tested two versions. One skips the model's reasoning and starts the visible answer directly; it succeeded on 99.4% of requests across CBRNE and cyber requests. The other lets the model keep reasoning, better preserving its capabilities while still achieving a 93.3% success rate on average, and at least 86% in each domain. We estimate that a new attacker would need about two and a half hours of one-time setup for either. Both use the same text for every request in every domain.

The model stays capable while it complies

Compliance only matters if the answers are any good, so we also tested the attacked model on benchmarks (standard sets of questions and tasks that measure what a model can do), using the response prefill version that keeps the model's reasoning. Average benchmark scores fell by 3.3 percentage points. The model's ability to fix real software issues on its own, over many steps, was unchanged in practice: on a set of 100 such tasks, Kimi K3.1 Pro solved 74.0% of them without the attack and 75.0% with it. The largest drops came on tasks that require working through laboratory procedures, which fell by 5.6 to 11.1 points, and a chemistry benchmark fell by 4.0 points.

Biosecurity refusals are weak even without an attack

On BioTIER, a benchmark that separates biosecurity requests a model should refuse from permitted lower-risk ones, Kimi K3.1 Pro answered more than half of the prohibited requests within five attempts with no attack at all. Both prefill attacks raised the compliance rate to nearly 100%. On a text-only subset of the Virology Capabilities Test, the model answered prohibited questions correctly about as often as permitted ones (54.0% against 57.9%). In this domain, its safeguards barely distinguish between the two.

The weakness carries across releases and developers

We tested Kimi K3 with the same requests in July 2026. The response prefill attack that broke it works on Kimi K3.1 Pro without any change, reaching 93.3% within five attempts, against 98.3% on Kimi K3. Kimi K3.1 Pro does refuse more individual attempts (the attack succeeds on 57.0% of single attempts, against 67.6% on Kimi K3), but within five attempts the gap narrows to five points. Its safety gains mainly raise the bar for attackers who can't write the start of the reply. With slight adjustments, the same style of attack reached 92.5% on Meta's Muse Spark Open, another recent open-weight model. These results highlight that response prefilling remains a persistent vulnerability across model generations and developers, with attacks transferring between models despite improvements in their safety training.

Why this matters for open-weight models

Proprietary AI models typically benefit from defense-in-depth: multiple layers of safeguards beyond the model's built-in refusal behavior. Providers can screen incoming requests, monitor responses, restrict certain interactions, and update their defenses when new vulnerabilities emerge. Open-weight models are different. Once downloaded, anyone can run them without these additional safeguards, leaving the model's built-in safety mechanisms as the main line of defense. Developers also lose control over how their models are used and cannot patch or recall copies already in circulation.

Our findings show why this matters. Kimi K3.1 Pro refuses almost all direct harmful requests, but these protections can be bypassed with relatively simple attacks. Response prefilling requires no changes to the model or substantial computing resources, yet succeeds on nearly all tested requests. The same attack works across different threat domains without modification and can be reused at scale. Importantly, some variants also preserve most of the model's capabilities, meaning attackers can bypass safeguards without substantially reducing the model's usefulness.

The fact that the same attack transfers from Kimi K3 to K3.1 Pro, and with minor adjustments to Meta's Muse Spark Open, makes the problem more concerning. A short piece of text can be easily shared, reused across models, and remain effective even as newer versions are released. For open-weight models, where developers cannot reliably intervene after release, such transferable and low-effort jailbreaks represent a significant security challenge.

What developers can do

We recommend five steps to Moonshot AI and to anyone releasing or hosting open-weight models:

1. Strengthen the model's built-in safeguards by training it to resist response prefilling and tool spoofing, so it maintains its safety behavior even when attackers manipulate the start of its response or provide fabricated tool results.
2. Where a dangerous capability isn't needed for the model's intended use, limit how much of it the model learns in the first place, for instance by filtering related material out of its training data, instead of relying on the model to refuse. While the developers have already taken steps to identify and remove cyber-related training data, this approach should also be extended to other risk domains, such as CBRNE.
3. Before release, red-team the model (attack it deliberately to find weaknesses) through every route an attacker could use, including response prefilling and fake tool results. Even if testing finds few effective jailbreaks through user messages alone, this does not mean the model is robust against other attack vectors. A staged release, with researchers and security testers getting access first, gives that testing time; because a model published for download can't be withdrawn, the open release should follow once the problems found are fixed.
4. Use tiered access: release a broadly available version with high-risk capabilities limited, and keep the full-capability version behind a monitored online service, or available only to vetted users.
5. Add defenses to online services that run the model that don't depend on the model's own refusal, such as separate filters that screen requests and responses. Companies hosting the model can also stop letting users write the start of the model's reply. Anyone running the model on their own hardware can remove these layers, but they raise the effort required against hosted services.

About FAR.AI

FAR.AI is an AI security research and adoption nonprofit. We exist to close the gap between what safety research can show and what actually gets deployed at the frontier of AI. Our work runs from in-house research and evaluations to working directly with frontier developers before their models are deployed.

This Security Stress Test comes from FAR.AI's Frontier Safety Division. The division started with red-teaming and is expanding into broader evaluations and safeguards for frontier risks. You can also read its earlier Security Stress Test of DeepSeek-V4-Pro.

For media inquiries, contact media@far.ai. For anything else, write to hello@far.ai.

Follow FAR.AI on X, LinkedIn, and YouTube for more of our research.