A Model Can Be Aligned and Uncensored at the Same Time

A lot of model verification leans on one idea: fingerprint the weights. Hash the base checkpoint, compare it to the card, and you know what shipped. Behavioral evals go further — but they usually probe one served configuration. For a routed-adapter model, both leave a gap, and we’re seeing more of these models.

The design: a frozen base, several small LoRA “specialist” adapters (chat, agent, coding, UI), and a lightweight router that picks the specialist per request. It’s reasonable engineering. But it has a property that matters for anyone who has to trust the model: which model you get is decided at request time by the router — not fixed in the base weights you’d scan. A base can be perfectly aligned while an adapter — selected for the right request, or the right caller — is not.

We didn’t want to argue this from theory, so we built the verification and ran it. Everything below is bounded to the specific models we tested — we’re not generalizing to all routed models.

Probing each specialist in isolation

One practical enabler: a single inference server (vLLM’s native multi-LoRA) loads a base plus all its adapters at once, and the API’s model= field selects which adapter applies per request — so you can pin each specialist and probe it alone, no merging. That makes this protocol cheap to run on any routed-adapter release.

Running the protocol on a real routed model

We took one shipping routed-LoRA model (frozen base + four specialists + a content router) and ran three checks:

• Enumerate the adapters. Four specialists, structurally identical (same rank, same target modules) — so any of them could carry a behavior change; only probing tells you.
• Audit the router. We read its routing code and prompt: the logic we inspected selects on task content (coding → coding specialist, identity questions → chat), with no reference to any API key, header, or caller identity. Reading the code proves the logic isn’t authorization-gated; a definitive answer needs the cross-caller behavioral test below, which we recommend but did not run here.
• Refusal-probe every specialist in isolation. 40 harmful-intent prompts across 15 categories, each specialist pinned, a separate judge scoring refuse-vs-comply.

Result: base and all four specialists refused all 40 prompts — no unrestricted specialist surfaced, and routing keys on content. On this probe, the model is clean. (Honest caveat: 40 prompts and a single judge is a point estimate with a wide confidence interval — read it as “nothing surfaced,” not a proof of universal safety.) Either way, it’s a conclusion a base-weight scan cannot reach — it never looks at the adapters or the router.

Then we planted the threat, to prove the check catches it

A clean result only means something if the check has teeth. So we built the exact object the check targets. We took an abliterated model of ours — abliteration being the edit that surgically removes a model’s learned “I shouldn’t answer” refusal direction from its weights (see our earlier post) — and recovered it as a LoRA adapter: the abliteration edit is near rank-1 per layer, so it decomposes into a small adapter cleanly. Then we served the stock base with that adapter attached and re-ran the probe.

On a dense base:

Refusal fell from 100% to 47.5% — the adapter got the model to comply with 20 of 40 harmful requests it had just refused (cyber, weapons, drugs, bio, violence, and more), on the same server, selected by nothing but the model= field. That is “aligned and uncensored at the same time,” made concrete — and the probe caught it, while a scan of the (untouched, aligned) base would have seen nothing. Same small-sample caveat applies: n=40, one judge; the direction — 0/40 vs 20/40 — is unambiguous even if the exact rate isn’t.

The twist: it’s architecture-dependent

When we tried the same trick on a mixture-of-experts base, the pure-LoRA adapter failed to decensor it — refusal stayed at 100%. The reason is mechanical: a full abliteration of that model also edited the fused expert weights, and standard LoRA (which attaches to individual linear layers) can’t attach to fused experts — so our LoRA carried only the attention/dense part of the edit, and missed the rest. We confirmed with the model’s author that the full edit needed a direct-weight “pass 2” on the experts.

We’re not generalizing from one negative result — but the mechanism points somewhere useful:

• Dense base: an uncensored specialist is a clean drop-in LoRA → enumerate and probe the adapters.
• MoE base (this case): a pure-LoRA uncensored specialist under-delivers; to actually ship one, the uncensoring has to live in the shared/fused experts of the base itself — which a weight scan would flag, if it diffed the experts against a clean reference.

Update (Aug 25): we since ran this on a third model — a different lab’s MoE, with a different expert layout — and it sharpened the rule. The blocker isn’t “MoE” as an architecture class; it’s whether the experts are stored fused or unfused. Where experts are fused into one tensor, LoRA can’t attach to them at all. Where they’re stored separately, LoRA can attach — we recovered an adapter touching 2,328 modules including per-expert weights — but the recovery was uneven: near-exact on attention (99.9% of the edit captured) and lossy on the experts (~75%). So a recovered adapter can look complete and still be a partial copy. Both cases land on the same verification rule for a different mechanical reason: inspect the experts.

What verification has to become

For a routed-adapter model the unit you verify is not the base — it’s (base + every adapter + router policy), probed together:

• Enumerate and refusal-probe every adapter in isolation.
• Audit the router — what routes where, on what signals — and note that a learned router can correlate with caller metadata in ways source-reading won’t reveal.
• Probe across caller identities — same prompt, different API key / header. If refusal changes with who’s asking, that’s routing-as-authorization. (We prescribe this; we have not yet run it — it’s the next hardening step, alongside a larger prompt set and multiple judges.)
• For MoE, diff the experts against a clean reference — that’s where an MoE’s hidden uncensoring would have to sit.

The honest tension

This same mechanism is how you’d do the responsible version of “unfiltered access”: give an authorized red-team, safety-research, or defense user the raw model while everyone else gets the guarded one. Routing-as-authorization is a legitimate design. The trouble is that the legitimate use and the plausible-deniability use — ship a compliant base, quietly route privileged callers to an unrestricted adapter — are the same architecture. You can’t tell them apart from the base weights; only by verifying the whole system and watching it behave across adapters, experts, and identities.

The artifact is what you deploy, so verify the artifact — not the story about it, and not a convenient slice of it. For a routed-adapter model the artifact is bigger than the base — and, on the models we tested, we could work it in both directions: we cleared a real one on our probe, and we caught a planted one.