Most people read the Moonshot headline as a safety win. Wrong. It is a press release about a service term.
The story reached me through a Crypto Briefing brief with no author, no timestamp, and no URL. Kimi K3.1 Pro, it says, "restricts hacking ability." Four data points. Two of them are the same sentence restated. No quotes. No model card. No benchmark. No red-team disclosure.
I have been instrumenting autonomous wallets since early 2026 — the ones that execute on-chain without a human pressing confirm. I built a small open-source auditor for that workflow, and it flags the same four things on almost every agent I point it at: a hot private key in an environment variable, no per-epoch spend cap, no simulation gate before broadcast, and a link to a model provider's safety page presented as the security model. That last one is the tell. A refusal policy is not a threat model. It never was.
Let me put the pieces where they belong. Moonshot AI is the Beijing lab behind the Kimi line. K2 shipped in July 2025 — a 1T-parameter mixture-of-experts with 32B active, open weights, Modified MIT license. That license matters more than any safety paragraph published alongside it.
The name "K3.1 Pro" does not fit the sequence. Kimi went K1.5, then K2, then K2 Thinking. There is no "Pro" suffix anywhere in that lineage. Three explanations survive. The model is new and the naming convention changed. The model is real and the media truncated a longer designation. Or the designation is simply wrong. If it is the third, the factual claim collapses, because "restricts hacking ability" is a statement about a specific artifact. Analyze the wrong artifact and you are analyzing a ghost.
Then the phrase itself. "Hacking ability" carries at least three technical meanings that have nothing to do with each other. Refusal: the model declines to author exploit code. Autonomous cyber capability: the model, wired to a shell and a browser, finds and exploits a target on its own. Self-exfiltration: the model talks its way past its own alignment. Only the second one should frighten anyone holding a private key. The brief does not say which.
And the driver. China's Interim Measures for Generative AI Services, in force since August 2023, Article 4, prohibits content that endangers network security. TC260's AI Safety Governance Framework lists network-attack assistance as a controlled risk class. Any base model serving the Chinese public market must curb it. It is a filing requirement. The brief frames the action as a considered balance between innovation and safety. That framing is doing a lot of unpaid work.
Now the part that matters to capital.
A refusal is a behavior layer, not a capability layer. The model still knows how to pivot, how to spray, how to craft a payload. It has been trained not to cooperate. Knowledge persists in the weights. Cooperation is a thin preference learned on top. Behavior layers are probabilistic. Capability removal is structural. Every jailbreak in the literature is an attack on the former.
I have run that test on my own harness. Multi-turn framing. Base64 encoding. Translation into a low-resource language. Code-switching mid-prompt. Refusal rate at turn one is high on a well-aligned model. By turn nine, with a plausible fiction wrapper, it drops. Not to zero. Enough.
So when a lab announces it has "limited" offensive cyber capability, the honest question is: suppressed at training time, or filtered at inference time? Training-time suppression means targeted data removal, capability forgetting, a narrow refusal distribution baked into the base weights. Inference-time filtering means a classifier sits between the user and the model and blocks. The first is expensive, lossy, and partially irreversible. The second is a config file.
The brief does not say which. That silence is the story.
Machine unlearning is a blunt instrument. The empirical record is consistent across labs: you cannot surgically excise one capability without dragging neighbors. Remove network-attack knowledge and you take a bite out of systems programming, reverse engineering, protocol parsing, sometimes low-level debugging. The bill arrives as an alignment tax on legitimate work. A model that refuses to explain a buffer overflow is also a model that is worse at auditing a Solidity contract for reentrancy.
I have watched that tax land in my own review queue. I lean on models for the boring parts — diffing access control across a proxy upgrade, tracing storage slot collisions, walking a delegatecall chain. When a model gets squeamish about the word "exploit," the review slows down. Not because I need an exploit. Because vulnerability analysis and attack construction share a vocabulary, and a classifier cannot read intent.
Which brings me to the weights. K2 shipped open. If K3.1 Pro follows, the curb binds the hosted API and nowhere else. Weights download. Refusal behavior is a LoRA away from gone. A few hundred paired examples — compliant and non-compliant completions — and a consumer GPU fine-tunes the constraint out inside an hour. The removal costs tens of dollars in compute. The curb costs a compliance filing. The asymmetry is the entire point. A safety property that costs fifty dollars to delete is not a property. It is a preference.
Liquidity doesn't read model cards. Neither does an attacker.
This is not an argument against open weights. It is an argument against confusing a licensing posture with an engineering guarantee. If the artifact ships, the vendor's safety page states intent. Your security model has to assume that intent is not binding on whoever holds the file.
A genuine dangerous-capability review is a documented, quantified process. Public frameworks from the major labs — Preparedness, Responsible Scaling, the Frontier Safety Framework — all set a capability domain, a benchmark, a threshold, and a deployment condition. They publish the threshold. They name the evaluators. They say what happens when a model crosses it. The measurement set for cyber is well known by now: automated CTF environments, autonomous penetration-testing ranges, exploit-completion benchmarks, third-party red teams with a defined scope and a disclosed pass rate.
The brief contains none of this. No benchmark score. No refusal rate. No false-refusal rate. No statement of whether a threshold exists, let alone where it sits. No word on independent evaluation. Without a baseline, "restricts" is not a claim you can test. It is a mood.
The real attack surface is not the text. It is the key.
Here is what an on-chain agent actually is. A loop. Read state, decide, sign, broadcast. The dangerous step is the third. Once a model can call a signing tool, the threat model stops being "will it say something bad" and becomes "what is the blast radius of one bad signature."
I built the auditor because I kept seeing the same failure, in production, in funded systems. A private key in a .env file. No allowlist on target contracts. No simulation gate — the agent broadcasts without a dry run against current state. No per-epoch ceiling. The operator's entire safety argument is that the model provider published a refusal policy. That is not a control. That is a vibe.
The correct stack is boring, and none of it is the model's job. Key in a hardware module or a threshold signer. Contract allowlist. Value cap per transaction and per epoch. Mandatory simulation against the latest block, with a revert check and a balance-delta check, before broadcast. Human confirmation above a threshold. A kill switch the operator can pull without a governance vote. None of these depend on Moonshot, on OpenAI, or on anyone's alignment team.
Tool use changes the risk class, and the brief does not mention it. A chat model that writes malicious text is a content problem. An agent with a shell, a browser, and a funded wallet is an execution problem. Output filtering is structurally useless against a model that can call a function instead of describing it. The defense relocates to the sandbox, the permission boundary, the audit log. The announcement says nothing about any of those. Which suggests the curbs are aimed at the chat surface — the cheap, visible, press-friendly surface — and not at the agentic one.
Now the market layer, because this is a trading problem too.
Agents chase yield. Yield is a number someone drew on a curve. I have said for years that Aave and Compound rate models are arbitrary constructs — a kink, a slope, a utilization target, chosen by governance, not discovered by a market. They are administrative prices dressed as equilibria. An agent optimizing against them is optimizing against a policy, not a market.
That is fine until the policy moves. Reparameterize a borrow curve and an agent holding a stale parameter set keeps executing against the old shape. I have watched size get pushed into a pool whose slope had been changed hours earlier. The model was not hacked. It was wrong, fast, and automated. No curb on earth prevents that. Simulation does.
Then the settlement layer. Layer2 sequencers are single centralized nodes. That has been true for two years, and "decentralized sequencing" has been a slide for most of it. Your agent's transaction enters a queue it does not control, gets ordered by an operator it cannot audit, and lands in a block it did not see coming. Slippage, MEV, and censorship are all decided by a party outside the model's context window. The model signs happily. It has no view of the queue.
The cost side is measurable, and almost nobody measures it. A simulation gate adds one eth_call and a debug_traceCall per decision. On an L2 that is fractions of a cent. On mainnet, at 30 gwei, tracing a multi-hop swap can cost more than the swap's expected edge. So the gate gets skipped "for performance." Then one bad broadcast costs more than a year of simulation. I have run that arithmetic for clients. The gate always pays. The argument against it is never economic. It is always impatience.
I keep coming back to the oracle. In March 2020 I spent 72 hours deploying test instances against Compound's price feed to measure latency under volatility. A fifteen-second delay was enough to open the door to roughly $50 million in undercollateralized loans. The lesson was not that the oracle was malicious. It was that the failure lived in the seam between two systems, and neither system's own safety documentation described that seam. Model curbs are the same shape. The model's safety page describes the model. Your loss happens in the gap between the model and the signer.
Terra taught the same thing at larger scale. The stability module looked coherent right up until the oracle stalled and the feedback loop turned one-way. The code did what it said. The design was wrong. I hedged with shorts on PAXG and BTC perpetuals and kept most of my capital, not because I understood the sentiment, but because on-chain liquidity was visibly thinning while the forum was still arguing about governance. Read the flow, not the thread.
The restaking work taught me to look for coordinated failure. In 2024 I walked EigenLayer's slashing conditions line by line and found the obvious hole: a coordinated set of operators can slash honest restakers, and the honest restaker's defense is diversification, not detection. Agents have the same topology. A single model provider is a single operator. If every agent in your stack routes through one API, one classifier, one refusal distribution, you have concentrated execution risk in a counterparty you cannot audit and cannot replace at short notice. Diversify the inference layer the way you diversify the signing layer. Not for ideology. For uptime.
There is a market forming around this confusion. Auditors who will certify an agent's "alignment posture." Dashboards that score a model's refusal rate and call it a security rating. None of it touches custody. All of it is billable. I don't begrudge anyone the invoice. I begrudge the substitution of a score for a control.
Here is the consensus read. A major lab curbing offensive cyber is good for everyone, and it means agents are getting safer.
Backwards, in two directions.
First, it mistakes a vendor posture for a system property. The security of an autonomous agent is set by its key custody, its spend limits, and its simulation gate. Not by the refusal distribution of the model inside it. A perfectly aligned model behind a hot key with no ceiling is an unsecured system. A feral open-weight model behind a threshold signer, an allowlist, and a hard value cap is a contained one. The boundary is the signing ceremony. Not the system prompt.
Second, over-refusal is a cost with a counter-effect. Defensive security — fuzzing, CTF, audit tooling, purple-team work — runs on the same primitives as offense. Crude curbs degrade the defense. And they push the practitioners who need those primitives toward local, uncensored weights. Every tightening of a hosted API is a demand signal for an open model with the guardrails sanded off. The curb manufactures the thing it claims to prevent. I don't think that is a paradox. I think it is a straight line.
The same logic hits identity. Soulbound tokens have been three years from adoption for three years, because nobody wants their credit history welded to a wallet they might lose the key to. Agents will hit that wall faster than people will. An agent needs a reputation to be trusted with size. A permanent on-chain reputation is a permanent liability the moment a key leaks. So the market routes around it — ephemeral signers, bonded intermediaries, off-chain attestations. The curb conversation never touches this. It is all model, no custody.
Before you let an agent near your vault, ask four questions. Where does the key live. What is the per-epoch spend ceiling. Is there a simulation gate against the latest block. Who can pause it.
If any answer is "the model provider says it's safe," you do not have an agent. You have a liability with a chat interface.
The next twelve months will produce the first on-chain incident traced cleanly to an autonomous signer. Not to a jailbreak. To a key. When the post-mortem lands, it will not mention alignment once. The only question is whether you already knew that.
