Training and Deploying Production Cyber Monitors on Kimi K3

Introducing SilicoSilico for LLMsSilico for Life SciencesSilico for Robotics & Vision

PricingResearchAbout

CompanyCareersBlog

Get AccessRequest Demo

← Research·

Oct 8, 2026

Training and Deploying Production Cyber Monitors on Kimi K3

We built cybersecurity monitors for Kimi K3 and GLM 5.3 that outperform an LLM judge at 50x lower cost, even when run live on every token.

Cybersecurity is one of the hardest settings for monitoring AI agents, because benign and malicious behavior often look similar: there’s significant overlap between the tasks involved in auditing a codebase for vulnerabilities vs. exploiting it. Distinguishing them means tracking intent across the whole trajectory, which can stretch to millions of tokens.

Despite this difficulty, cybersecurity monitoring is critical, as demonstrated by recent incidents involving agentic coding models.

The obvious solution is to have an LLM judge read every turn, but that's too slow and expensive to run alongside the agent in real time. So in practice monitoring is asynchronous: by the time a harmful trajectory is flagged, the agent has already acted.

To address this, we built probe-based cyber monitors for Kimi K3 and GLM 5.3 and deployed them on a production inference stack. As we described in our previous post, a probe reads the model's internal activations and acts as a cheap first-line filter. It sends only suspicious exchanges to an LLM judge. Compared with running the judge on every turn, this cascade:

These results make it practical to monitor agentic rollouts in real time, meaning that risky cyber actions can be blocked before any tool is called. In this post, we share details on how we built these monitors, as well as some of the inference optimizations to our monitoring stack that enable such efficient performance.

Open models don't come with a full safety stack; we think a monitoring setup like this is a practical default for anyone serving them in agentic settings. If you serve or build on open models and want to deploy monitors like these, get in touch.

Agentic sessions can span hundreds of thousands to millions of tokens, and harmful behavior can emerge at any point. To model production data of this nature, we simulate users with various harmful and benign goals within both cyber and non-cyber (e.g., SWE, tool-use, etc.) environments. For this purpose, we collected a portion of our data using Prime Intellect’s verifiers, Prime Sandboxes, and Tunnels, allowing us to run Kimi K3 inference on cyber offensive as well as benign tasks without network access in a secure fashion.

To specify which behaviors our monitor should flag, we use a precise policy that describes undesirable cyber activity, using concrete factors that distinguish well-intended tasks (e.g., bounded vulnerability reproduction) from ill-intended ones (e.g., vulnerability exploitation). The simulated user can introduce or escalate harmful intent at any point throughout the session, including after an initially benign request. For example, most tasks start with a minimal level of benign exploration (e.g., searching a file directory), and it’s only over a course of actions that harmful activity starts to take place. This produces a diverse set of interactions from the same base tasks.

Ideally, we could monitor the target agent by having another equally capable LLM judge classify each turn in accordance with a misuse policy. However, as rollouts get long, using another model can result in extremely high costs and compute overhead: based on OpenRouter rates, monitoring one million turns from Kimi K3 rollouts using Opus 5 would cost on the order of $200K, or via Kimi K3 itself ~$30K.

To address this problem, we exploit the fact that in a long-running agentic session, most of the agent’s activity is benign, even if the intended goal is harmful—so many agent turns need not even be processed by the judge. The challenge lies in knowing which turns warrant being looked at by the judge. To this end, in line with our own past work and recent work from othersSee prior work for related ideas on probe-based monitoring: Building Production-Ready Probes for Gemini; Detecting High-Stakes Interactions with Activation Probes; Constitutional Classifiers++. Amongst these, the turn-level classification process has been tried in Constitutional Classifiers++, but only for short rollout tasks focused on CBRN threats; the Gemini work focused on only input monitoring and hence ignores the technical challenges noted above for full input-output monitoring; and the high-stakes detection paper focuses on smaller models., we use probes to amortize the cost of using an LLM judge as a monitor.

In particular, we design a novel probing architecture that is specifically designed for capturing behaviors represented in both a localized (i.e., localized to a specific chunk in a turn or rollout) and distributed (i.e., persistently present over an entire turn) manner, while also being efficient to run, as discussed in the section below.

The probe acts as the first-line, efficient, always-on detector in a monitor cascade: it helps read whether an input, tool call, or output is high-stakes, and if the probe readout exceeds a calibrated threshold, the rollout is escalated to the LLM judge for further evaluation. After calibration, we find our probe achieves 0% FNR and 95% TNR on a held-out set of agentic and chat interactions, ensuring that the LLM judge is only called to process harmful activity. This also allows us to reduce cost by using a faster, even if less capable, judge.

Running a forward pass on a probe is far less expensive than an LLM judge. However, making sure it adds no latency while running inside a production inference server requires careful engineering work. Modern inference servers like SGLang and vLLM achieve high throughput by processing many requests together, reusing earlier prefix computations, and generating several candidate tokens at a time with speculative decoding. The monitor must preserve these throughput gains while keeping scores aligned with the correct tokens and sessions.

In our previous interpretability infrastructure post, we described how to collect activations for analysis.Goodfire, “Interpretability Infrastructure at Frontier Scale: Harvesting Activations from a Trillion-Parameter Model.” For the live monitoring described in this post, we extended SGLang to compute probe scores directly inside the serving engine.

We made several optimizations to preserve inference throughput while running our probes, including the implementation of custom kernels for our probe logic. We also maintain probe scores through the radix tree, DSpark speculator, and prefill-decode disaggregation to avoid additional recomputation. When serving multiple Kimi K3 model replicas, each worker runs the probes and maintains histories for its active requests. We extended the SMG router to preserve our monitoring configuration through request conversion and pass it to the selected worker. Monitoring events are returned with the response stream, allowing downstream consumers to handle events regardless of which replica served the request.

Overall, we find that running our probes during inference adds no overhead across several different workloads. Across four inference workloads, enabling the probes maintained throughput within the noise threshold of our benchmarks relative to default SGLang serving.

We also evaluate the added latency of our monitor cascade, comparing it with an LLM judge reviewing every turn. Without judge reasoning, our cascade reduces average added latency per turn from 160 ms to 2 ms; with reasoning, it reduces latency from 2,750 ms to 42 ms. Both configurations reduce average monitoring delay by more than 50× compared with judging every turn.

We evaluate our cyber-misuse monitors on an in-house dataset of 2.4K chat and agentic sessions comprising over 60K turns, using Claude Opus 5’s labels as reference. To generate realistic interactions, we model users in two ways. We use PetriAnthropic, “Petri: An open-source auditing tool to accelerate AI safety research.”, an open-source automated red-teaming library, to simulate conversations and tool responses, and our own user simulation to interact with agents operating in real environments adapted from benchmarks such as ExploitBench. This gives us the ability to collect both harmful and harmless rollouts from the same cyber tasks. We also include real-world chat interactions from a cyber-specific subset of WildChat, alongside benign agentic rollouts from off-the-shelf SWE, Coding, and DevOps tasks.

We report recall and monitoring cost over the rollouts designed. Detection comparisons use a benign-session interruption budget of 5.5%. Cost and latency comparisons use the cheapest configuration achieving at least 90% recall, while interrupting at most 10% of benign sessions. A benign session counts as interrupted if the monitor would flag it for review at least once.

In general, we find that our monitor cascade is a Pareto improvement over the LLM judge on its own, i.e., our monitor performs better than just the judge at any amount of interruption. At a 5.5% benign-session interruption rate, we find our monitor reaches approximately 93% recall with and without judge reasoning on harmful sessions and flags 0% of non-cyber traffic, making our monitors viable for production traffic. We also give a benchmark-level decomposition of our results, finding our monitoring pipeline is accurate on both agentic and chat data.We find that standard linear probes achieve roughly 5% lower recall than our final recipe, while nonlinear probes lose up to 30% recall on our out-of-distribution evaluation sets. Meanwhile, an n-gram baseline requires flagging almost all turns to reach this recall rate at all.

To further concretize the cost benefits above, we report the cost of the LLM judge we optimized for defining our cascade pipeline and the overall cost of running our probe before the LLM judge. Based on inference cost documented on OpenRouter for our evaluation suite, our monitoring cascade costs $65 without judge reasoning, and $185 with reasoning per one million agent turns. Relative to reviewing every turn with the corresponding LLM judge, our monitor reduces judge cost by about 29× with reasoning and 49× without reasoning.

In practice, one would not serve a monitor via a third-party API, and instead use a local judge to simultaneously monitor multiple replicas of the target model as a part of inference compute. Our results show that given a finite amount of compute, our monitors allow us to spend >99% of that compute for serving the target model (Kimi K3), and using only <1% compute for running the monitor at no loss of monitorability; meanwhile, with an LLM judge run by itself, one would need to allocate up to 20% compute for monitoring in order to monitor every turn produced by the target model.

Interestingly, we find our pipeline can also be used for building monitors via just off-policy data. In particular, we design a monitoring pipeline for GLM 5.3 using the data we originally developed for Kimi K3, finding we get an approximately equally capable GLM monitor when evaluated on Kimi rollouts, and only a marginally worse monitor for on-policy evaluation dataset designed using GLM. See the appendix for plots.

A useful monitor needs to block harmful activity while allowing legitimate work to continue. We ran full-turn agent and chat sessions, comparing Kimi K3 and GLM 5.3 with and without our monitors against several frontier model systems.

Adding our monitor raises Kimi K3’s harmful-session blocking rate from roughly 29% to 96%, while its harmless-session interruption rate increases from about 5% to 9%. For GLM 5.3, harmful-session blocking rises from roughly 36% to 91%, while harmless-session interruption increases from about 10% to 15%. Both monitored models approach the highest har