Anthropic Says One Open Model Is a Cyber Risk. Read That

By Lazar Milicevic · Published October 14, 2026 · 8 min read

If you run a small business and you're choosing between paying per token for a closed API or running an open model yourself, a top lab just handed you a headline that makes the choice harder. Anthropic published a report arguing that GLM-5.3, an openly downloadable model, is a serious cyberattack risk. Here's exactly what the report claims, what it means for a team of 1-10 people, and a short test you can run on Monday.

What Anthropic's report actually claims

Anthropic's Frontier Red Team published "GLM-5.3 and the spread of advanced cyber capabilities" on September 29, 2026. Its core claim: GLM-5.3 can autonomously build end-to-end cyber exploits, and it was released without meaningful safeguards against misuse. The full report is on Anthropic's site.

The strongest numbers are about safeguards, not raw capability. In Anthropic's simulated tests, attackers bypassed GLM-5.3's safeguards 64% to 100% of the time using simple techniques. The same attacks did not succeed against safeguarded Claude models in Anthropic's testing. The breakdown:

Claude Opus 5 stayed at 0% across the same tests, per the report.

Two details matter for how you read this. First, the "100%" row involves abliteration, which means editing the model to strip its refusal behavior. A secondary summary of the report (CellCog's write-up) says Anthropic's team did this in roughly 2,200 GPU hours, around $4,400, taking the refusal rate from above 90% to as low as 2% with capability largely intact. I haven't verified that passage in the primary source, so treat it as Anthropic's reported figure via a secondary summary, not a floor on what an attacker would pay.

Second, this is a downloadable-weights problem. Once weights are public, anyone can run the model, and nobody can recall it. As MIT Technology Review's explainer puts it, this is the latest round of a long-running fight over whether open frontier models' benefits outweigh their risks, and it also notes that safety remains a hard problem for closed models too (MIT Technology Review).

How to read it: capability numbers and conflict of interest

The company raising the alarm sells closed models. That doesn't make the claim wrong. It means you read it the way you'd read a car dealer's report on bike safety: take the data seriously, question the framing.

Start with the capability numbers, because they're less dramatic than the headline. On ExploitBench (V8 JavaScript engine exploits), per a GIGAZINE summary of the report, GLM-5.3 built a working exploit in 50 of 410 attempts, about 12%. Claude Mythos Preview managed 56 of 410. On Anthropic's OSS-Fuzz-based control-flow-hijacking benchmark (100 challenges), GLM-5.3 succeeded 4% of the time versus 6% for Mythos Preview. Those are close.

Now add an independent check. NIST's Center for AI Standards and Innovation (CAISI) published its own assessment on September 17, 2026. It found GLM-5.3 to be the most cyber-capable open-weight model released to date, and also found its cyber capabilities significantly lower than current U.S. frontier models, lagging by about four months on an aggregate of CAISI's cyber benchmarks (NIST CAISI).

One caution on benchmarks: Z.ai, NIST and Anthropic report different ExploitBench figures, which reflect different setups or versions. Don't mix them or treat any single number as the score.

The honest summary: the model is the strongest open-weight cyber model so far, it's behind the closed frontier, and its safeguards are thin. All three are true at once.

What open weights actually give a small business

Open weights give a small team three concrete things: predictable cost, data that stays on your machine, and independence from a provider's roadmap. I've watched all three matter in real client work. A closed API can change under you on a Tuesday, and your automation breaks while you're asleep.

• Cost control. A workflow processing thousands of emails or invoices a week has a flat cost when you self-host, instead of a per-token meter.
• Privacy. Client financials, contracts and health details can stay on hardware you control instead of traveling to a third party.
• Independence. Nobody can deprecate your model, change its behavior overnight, or raise prices on you.

Before you get excited, check the hardware math. The GLM-5.3 flagship is a roughly 744B-parameter mixture-of-experts model with about 40B active parameters, and its smallest usable quantization (2-bit GGUF) is about 239GB (RunAIHome's hardware guide). That is not a laptop or a typical home server. The smaller GLM-5.3-Flash (320B total, 18B active parameters) is MIT-licensed and came out on August 26, 2026 (TechJack Solutions), which is a more realistic target, though still serious hardware.

On licensing: per one license analysis, the flagship uses a custom GLM-5.3 License rather than MIT. Its one substantive difference is that a Model-as-a-Service operator with more than $10B in revenue over any consecutive 12 months must pass Z.ai's security review before commercial use. The exact clause wording differs between sources and I haven't read the raw license file, so read it yourself before you build on it. A solo shop is nowhere near that threshold either way.

Also, "open" isn't automatically "cheaper than API." Z.ai's own API lists GLM-5.3 at $1.40 per million input tokens and $4.40 per million output tokens (VentureBeat). VentureBeat's blended comparison (1M input + 1M output tokens) puts that at $5.80, versus $30 for Claude Opus 5 and $35 for GPT-5.6 Sol. Prices move and I haven't checked the closed vendors' own pricing pages, so verify there before you decide. The point stands: for light volume, a cheap hosted open model may beat buying GPUs.

Where your real risk is (it isn't the model)

Your risk is smaller and more boring than a state-level attack. You are not going to be targeted through your invoicing bot. But if you self-host, you own the security: updates, access control, who can reach that server, and where the logs go.

Here's the failure pattern I'd bet on for small teams. Someone wires an open model into email and a CRM, exposes the endpoint to make remote access easy, and gives the agent credentials with broad scope. That is the exact thing attackers love: a capable system with credentials and no supervision. The model isn't the danger. The unguarded integration around it is.

A minimal hardening checklist for a self-hosted model endpoint:

# Bind the model server to localhost only, never 0.0.0.0
# (example for an OpenAI-compatible local server)
--host 127.0.0.1 --port 8000

# Reach it remotely through a private network, not the open internet
# e.g. a WireGuard/Tailscale tunnel, then firewall everything else
sudo ufw default deny incoming
sudo ufw allow from <your-vpn-subnet> to any port 8000
sudo ufw enable

And one rule for the agent layer: it gets a service account with the narrowest scope that works (read-only mailbox access for triage, say), never your admin credentials.

Notice that none of this changes whether the model is open or closed. A closed API with an over-permissioned agent behind it fails the same way.

The three-question test for every workflow

Run these three questions on each workflow before you pick a model. They take about five minutes per workflow, and the answers usually decide the question for you.

1. Does it touch data I'd be embarrassed or fined to leak? Client financials, health details, contracts. If yes, self-hosting (or at minimum a provider with terms you've read) starts looking attractive, because the data never leaves your machine.

2. Can it act, not just read? Send email, move money, change records. If yes, it needs a human approval step and a narrow scope, no matter which model sits underneath.

3. If my model provider vanished or changed behavior tomorrow, how fast could I swap it? If the honest answer is "never," you're locked in.

The fix for question 3 is a thin layer between your workflow and the model, so changing models is a config change, not a rebuild. Here's the shape of it:

# models.yaml decides the provider; workflow code never names a vendor
import os, yaml
from openai import OpenAI  # works with any OpenAI-compatible endpoint

cfg = yaml.safe_load(open("models.yaml"))[os.environ.get("MODEL_PROFILE", "default")]

client = OpenAI(base_url=cfg["base_url"], api_key=os.environ[cfg["key_env"]])

def ask(prompt: str) -> str:
    resp = client.chat.completions.create(
        model=cfg["model"],
        messages=[{"role": "user", "content": prompt}],
        temperature=0,
    )
    return resp.choices[0].message.content

# models.yaml
default:
  base_url: your-closed-provider.example
  model: your-closed-model
  key_env: CLOSED_API_KEY
local:
  base_url: 127.0.0.1
  model: your-local-open-model
  key_env: LOCAL_API_KEY

Switching from default to local is one environment variable. That single design choice protects you whether open models get restricted or closed ones get pricier. It's the difference between a workflow you control and one you rent.

And for anything irreversible, put the approval gate in code, not in a prompt:

ACTIONS_REQUIRING_APPROVAL = {"send_email", "create_payment", "update_crm_record"}

def execute(action: str, payload: dict, approved_by: str | None = None):
    if action in ACTIONS_REQUIRING_APPROVAL and not approved_by:
        queue_for_human_review(action, payload)   # e.g. a Telegram button
        return {"status": "pending_approval"}
    return run_action(action, payload)

A prompt that says "ask before sending" is a suggestion. A function that refuses to send without an approver is a control.

Where I land on the open-vs-closed debate

The loudest part of this debate is a distraction for a business your size. Whether a model is open or closed matters far less than whether you've scoped its permissions and put a person in front of anything irreversible. I'd take a mediocre model with tight guardrails over a brilliant one with the keys to everything.

Two ways to get this wrong:

• Panic and drop open models entirely. You lose the cost and privacy benefits to avoid a risk that is mostly not yours.
• Shrug because you're small. Small shops with exposed endpoints and broad credentials are the easy targets.

The sane position is boring: pick the model on cost and data sensitivity, then lock down the integration. Anthropic's report is worth reading for what it says about the trajectory of open-weight capability and the weakness of GLM-5.3's safeguards. It doesn't change the Monday-morning checklist above.

Where I fit in

I'm a senior engineer who builds AI automations for solopreneurs and small teams, with a focus on systems that work in practice rather than demos. If you want a second pair of eyes on how your own workflows handle model choice, permissions and approvals, you can find me at bizflowai.io.

Want more like this?

I publish practical AI automation and GenAI engineering content for small teams.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milićević, senior engineer building AI automations.

Visit bizflowai.io for services and case studies.