Anthropic's GLM-5.3 Study: Near-Frontier Exploit Skills Now Download Without Safeguards

Anthropic's September 29, 2026 paper on GLM-5.3 is an unusual piece of research: a frontier lab testing a competitor's open-weight model, publishing the numbers, and arguing that something has changed. The claim is that advanced cyber capability, until now confined to restricted or safeguarded models, can now be freely downloaded, and that the remaining protections can be removed for the price of a used car.

Most commentary will focus on what this means for attackers. That matters, and we come to it. But there is a second consequence closer to home for most security teams, and it concerns the models already running inside their own fleets.

What Anthropic measured

Two qualitative results sharpen the picture. A researcher working with the model developed novel zero-day exploits in a popular browser's JavaScript engine within one day. And GLM-5.3-Flash produced a working N-day exploit chain for CVE-2026-11645, an out-of-bounds read and write in Chrome's V8 engine, with 20 minutes of human attention, 8 hours of model runtime and $20.40 in compute.

The safeguards come off

Anthropic then tested how readily GLM-5.3 would engage with explicitly malicious cyber-attack orders under increasing pressure, and ran the same tests against Claude models.

Abliteration removes refusal behavior by editing the weights themselves. It is only possible when you hold the weights. Anthropic estimates it cost about $4,400 in GPU time for GLM-5.3, or roughly $1,200 for an experienced team. Refusal rates fell from 95% to 3% on JailbreakBench and HarmBench and to 12% on StrongREJECT. Capability barely moved: GPQA-Diamond scores were identical and CyberGym slightly lower.

A safeguard that ships inside open weights is a default setting. Anyone with the weights and a modest GPU budget can change it.

Consequence one: patch windows get shorter

A $20 exploit chain for a known browser bug changes the economics of N-day exploitation. It aligns with Google's threat intelligence data showing an AI-discovered vulnerability exploited within four days of disclosure, and with the broader argument in autonomous hackbots and agent-layer visibility. The practical response is the unglamorous one: know your assets, including AI software, so the patch you need to push is a list rather than a search.

Consequence two: the models inside your fleet have no vendor safeguards

Consider what hosted frontier models now ship with. OpenAI Astra has refusal training, chain-of-thought monitoring and restricted responses for higher-risk accounts. Claude models stayed at 0% in every condition Anthropic tested above. Both vendors log usage, assess accounts and gate advanced cyber capability behind verification programs such as the Cyber Verification Program.

Now consider the same capability class running through a local runtime on a workstation or an internal server. There is no vendor in the loop. The refusal training can be absent or removed. There is no monitoring on the other end, no account risk score, no usage log you did not build yourself. If a coding agent or CLI is pointed at that runtime, it inherits none of the protections the hosted model would have provided.

This is not an argument against local models. They solve real problems around data residency, cost and offline work, and most local use is ordinary. It is an argument that local runtimes belong in the inventory and in policy as a distinct category. The vulnerabilities in those runtimes are a separate problem again, covered in advisories such as Ollama's Bleeding Llama memory leak and the Ollama model-pull SSRF.

What to put in policy

• Name local LLM runtimes explicitly in the AI acceptable use policy, rather than leaving them under a general software clause. Our AI acceptable use policy template has a section for it.
• Decide where local models may run. Approved workstations and servers, not every laptop by default.
• Know which agents are pointed at local models, because an agent's tool access matters more than the model's refusals once safeguards can be removed.
• Enforce at the agent, not at the model. Controls that live in the agent's execution path apply whichever model is behind it.
• Give defenders capable tools through sanctioned channels, as Anthropic recommends, so the path of least resistance is not a downloaded model with its refusals stripped.

How Anomity governs model-agnostic risk

The Endpoint Sensor inventories local LLM runtimes on every managed endpoint, alongside the agents, CLIs, MCP servers, plugins and skills that call them. That answers where models run outside any vendor's safeguards, and which agents are wired to them.

Enforcement is deliberately model-agnostic. On agents that expose a pre-execution hook, such as Claude Code's PreToolUse, Anomity returns allow, deny or log before a tool call runs, across 180 rules and nine guards. A rule blocking a credential read or an outbound connection holds whether the agent is talking to a hosted frontier model or a local one with its refusals removed. Every decision lands in a 90-day audit trail that routes to SIEM, Slack, email or Jira.

Anthropic's paper argues that the frontier of cyber capability is no longer gated by who controls the weights. For enterprises, the matching conclusion is that the controls that matter most cannot live only in the model. For background on governing unsanctioned AI generally, see what is shadow AI. To see the local model runtimes and agents across your fleet, book a 30-minute demo.