The guardrail was never in the model

I have six GPUs in a box in my basement, and a few weeks ago I tripped a 15-amp breaker finding out that 6×300W plus overhead is more than a residential circuit wants to give you. I mention this because it’s the cheap version of the point I want to make: the hardware that runs a genuinely capable model is now ordinary. It’s a room in a house. It’s a gaming desktop. It is not a data center, and it has not been a data center for a while.

On August 14th Alibaba released Qwen3.8-27B under Apache 2.0. Quantized to 4-bit it’s about 17GB of weights, which means it fits on a single 24GB consumer card. The generation before it, Qwen3.6-27B, scores 77.2% on SWE-bench Verified and 59.3% on Terminal-Bench 2.0 — the latter tying Claude 4.5 Opus. You can argue about how much benchmark numbers mean, and you should, but you cannot argue that this is a toy. That is a competent software engineer’s worth of code reasoning running on a card you can buy at Micro Center, with no API key, no terms of service, and no log of what you asked it.

And that’s before anyone removes the safety training, which is the part everybody wants to talk about.

What abliteration actually is

The technique that gets called “abliteration” is more interesting than the name suggests, and it’s worth understanding precisely, because the imprecise version of it drives some genuinely bad predictions.

When a model refuses, that refusal isn’t stored as a rule somewhere. It shows up as a direction in the model’s activation space — a consistent vector that lights up across many different kinds of refusal. You can find that direction by comparing activations on prompts the model refuses against prompts it accepts, and then you can suppress the model’s ability to move along it. The knowledge doesn’t go anywhere. The reasoning doesn’t degrade much. The model simply stops having the reflex to decline.

The important consequence, and the one that reframes the whole conversation:

This is not a flaw someone can patch. It follows directly from what open weights are. If you can run the model, you can inspect its activations; if you can inspect its activations, you can find that direction. Every open-weights release ships with this property, and no amount of safety tuning before release changes it. That’s not an argument against open weights — I’ll get to why I think the ledger is more balanced than it looks — but it does mean that “we’ll align the open models better” is not a plan.

So the guardrail that actually did something was never the one in the weights. It was the one in front of them: the API that could refuse, rate-limit, log the session, and ban the account. The wall was in the API the whole time, and open weights route around the API by definition.

2026 gave us the experiment

Here’s where I want to be careful, because this topic attracts a lot of confident nonsense in both directions. We now have two well-documented real-world campaigns, and they’re worth reading closely rather than by headline.

The Unit 42 campaign

On July 30th, Palo Alto’s Unit 42 published a teardown of a Chinese-speaking threat actor who wired DeepSeek into the open-source Hermes Agent framework and pointed it at the internet. Researchers recovered a full session from May 2026 in which, after the initial tasking, they found no further operator input. The model enumerated targets, picked vulnerabilities, pulled public exploit code off GitHub, ran the attacks, and changed approach on its own when things failed.

Now the numbers everyone skips. The actor attempted more than 460 targets. Confirmed compromises: 14 — three Citrix NetScaler instances where memory was exfiltrated via CVE-2026-3055 (they went looking for session cookies in the dump), and eleven Marimo notebook instances with command execution.

Fourteen out of four hundred and sixty.

And the reason for that ratio is the single most useful sentence in the entire report: the failures came from target-side configuration — authentication that was actually required, auto-login that was actually disabled — and not from limitations of the tooling. The agent was tireless and it was fast. It was not magic. It ran into correctly configured systems and bounced.

Two more details deserve mention because they cut against the doom framing. First, the actor tested Western platforms too, and OpenAI’s systems refused the policy-violating requests and disabled the linked account — which is the first solid field evidence I’ve seen that provider-side controls have measurable operational value rather than just being friction for the rest of us. That’s presumably why the operator settled on a model with a thin safety layer. Second, this whole operation was unmasked because the agent accidentally started a file server in its home directory and published the crew’s own configs and logs to the internet.

The Taiwan campaign

Then, two weeks ago, the harder data point. Taiwan’s Ministry of Digital Affairs confirmed on August 13th that open-source agent frameworks — Hermes and OpenClaw, driving roughly eight open models — mapped 21 government systems in four days, breached 85 accounts, and took more than 2,500 personnel records. It reached the country’s nuclear safety regulator and at least seven energy companies.

This one matters more than the first, for three reasons:

• It was end-to-end and it worked. Not 14 hits out of 460. A sustained, adaptive campaign that chained vulnerabilities and switched tactics when blocked.
• It was entirely free software. No frontier API, no budget, no vendor to appeal to.
• The frameworks in question had safety features, and the operators got past them with a framing trick — presenting the whole operation as an authorized penetration test. That’s a design-class weakness, not a bug. A safety layer that can be talked out of its position by asserting a context it cannot verify is a speed bump.

What actually changed, stated carefully

If I strip out the parts that are atmosphere, here’s what I think genuinely moved.

Time-to-exploit collapsed. This is the big one and it barely gets discussed next to the scary agent stories. Average time from disclosure to exploitation is running around 24 hours in 2026, against roughly 53 days in 2024. Better than a quarter of critical CVEs in CISA’s KEV catalog are weaponized inside a day. Whatever you believe about AI, the operational consequence is concrete: the patch window you designed your process around no longer exists. A monthly patch cycle is now a policy of being exploitable for four weeks.

Marginal cost went to zero. Attacks that were previously not worth a human’s time against a target your size are now worth an agent’s time, because the agent’s time is free. This doesn’t make attackers smarter. It makes the floor of who gets attacked drop to include everybody. Small businesses already face automated attack traffic on the order of every 11 seconds; there are 24 billion-plus stolen credential pairs in circulation and something like 26 billion stuffing attempts a month. Agents don’t invent that. They extend its reach and its patience.

Personalization got cheap. The most credible near-term risk isn’t autonomous exploitation, it’s social engineering tuned to you specifically — your writing style, your org chart, your vendors, your last three public commits. That’s a task local models are already good enough for, and it runs offline.

And here’s what I don’t think changed, said just as plainly:

The breaches that are actually hurting people remain minimally AI-aided. Losses have not spiked in proportion to the fear. And there’s a structural reason to expect the “AI does everything” scenario to underdeliver for a while: good intrusion minimizes observable actions, and volume is exactly what detection is built to catch. An agent that tries 460 things is loud. The tradecraft that actually gets people hurt is quiet, patient, and context-aware in ways that current models are not reliably good at. LLM execution is still non-deterministic and brittle in long chains.

There’s even a defensive dividend that’s easy to miss: of 1,061 vulnerabilities attributed to AI-assisted discovery, only about 1.3% have been confirmed exploited in the wild. The same capability finding bugs for attackers is finding them for maintainers, mostly first.

What to actually do

This is written for the person who has just started paying attention and is trying to work out whether to panic. Don’t. But do go fix things in this order, because the order matters more than the list.

The organizing principle, and the reason I’m confident about it: 446 of those 460 targets survived a tireless autonomous attacker because of configuration. Not because of a product. Not because they detected anything. Because the thing was already set up correctly when the agent showed up.

1. Get phishing-resistant on your identity path first

Credential attacks are the number one breach vector, and every AI development makes them cheaper, not harder. SMS codes and authenticator apps are meaningfully better than nothing and meaningfully worse than what you want.

• Passkeys / FIDO2 for everything that supports it. Synced passkeys are the right default for normal accounts — adoption friction is low and the adversary-in-the-middle bypass rate is functionally zero.
• Hardware keys or device-bound passkeys for your admin accounts. Your cloud root, your domain registrar, your GitHub, your password manager. These are the accounts where losing one loses everything else.
• Understand that passwordless and phishing-resistant are not synonyms. Passkeys resist remote phishing; they don’t help if malware is sitting on the endpoint.

Your registrar and your email are Tier 0 whether or not you’ve ever called them that. Everything else is recoverable through them.

2. Delete the attack surface instead of defending it

Nothing on this list is new advice. All of it got more valuable, because the scanning is now constant and the exploitation is now same-day.

• Kill port forwarding. All of it, then add back only what genuinely must be public. Exposed buckets and services get found within hours of existing — that’s automation that predates the AI conversation entirely.
• Anything administrative goes behind a VPN or a tunnel. WireGuard, Tailscale, Cloudflare Tunnel — pick one. Your Proxmox UI, your router, your dashboards, your SSH, your container hosts. Not on the internet. Not behind a “good password.”
• Default-deny at the firewall, key-only SSH, and no password auth anywhere.
• If a service genuinely must be public — a website, media for family — it goes through a reverse proxy, in its own segment, with nothing else reachable from it.

I run a fleet dashboard at home that can read and write real system state. It is emphatically not on the internet, and the reason isn’t that I distrust my own code — it’s that the cost of being wrong about that is total, and the cost of a VPN is a five-minute install.

3. Fix the patch queue that assumes you have weeks

If exploitation now lands in about a day, monthly patching is a decision to be exposed. You don’t need to patch everything in 24 hours — you need to split the queue so that the things on the exploitation path aren’t waiting behind office software.

Look hard at that middle row. Both 2026 campaigns went after exactly that class of software — Langflow, n8n, Marimo notebooks, Tomcat. Automation and AI tooling with a web interface is now a primary target, and it’s precisely the category that people stand up quickly, expose “just for a minute,” and forget. If you have been enthusiastically self-hosting AI tools this year, that sentence is about you. It’s about me too; it’s why I went and looked.

4. Assume compromise for the things that would end you

• 3-2-1 backups, with at least one copy that a compromised credential cannot reach or delete. Test a restore. An untested backup is a belief, not a backup.
• Know what your blast radius is. If someone has your laptop session right now, what do they own? That answer should be short, and if it isn’t, that’s the project.

5. Don’t fight the volume by hand

You will not out-attention an agent. Spend your effort on things that fail closed: rate limiting on authentication endpoints, alerts on impossible-travel and new-device logins, and checking whether your credentials are in public dumps. These are cheap, they’re mostly free, and they work while you’re asleep — which is the only shift that matters here.

The part I’m still uneasy about

I don’t think the right conclusion is that open weights were a mistake. The same 27B model on that gaming GPU is the reason a person can audit a model, run one without shipping their data to anyone, and build defenses without asking permission or paying rent — and provider controls, which demonstrably do work, are also a single point of policy for everyone who depends on them. I would rather live in the world where the capability is distributed and the defenses are too.

But I want to be honest that I hold that position while the ledger is still open. What genuinely worries me isn’t the abliterated model. It’s the second campaign — the one where the safety layer existed, and lost to a sentence asserting a context it had no way to verify. We keep building agent frameworks whose guardrails are made of trust in the prompt. That’s the same architectural mistake as an appliance whose database is the source of truth instead of the system: it’s maintaining a fiction, and the fiction is one confident assertion away from collapsing.

The thing I’d actually like to see, and the reason I wrote this down: fewer arguments about which models should be allowed to exist, and more attention to the fact that 446 targets held. They held because someone required authentication, disabled auto-login, and didn’t put the admin panel on a public IP. That’s not a sophisticated defense. That’s Tuesday. It’s just that nobody writes headlines about the configuration that worked.