Defenses against safety removal
Weight-level defenses (model publisher side)
| Defense | Idea | Status |
|---|---|---|
| Safety pretraining (arXiv 2510.02768) | Put refusal behaviour into pretraining data so no single post-training direction carries it | Research; granular study shows partial resistance |
| Extended-refusal fine-tuning (arXiv 2505.19056) | Make refusals long-form and distributed across many directions | Research |
| Decoy Direction Optimization (arXiv 2609.16204) | Post-hoc: plant decoy refusal directions so ablation tooling removes the decoy and leaves the real one | 2026 research |
| Fool's Gold (arXiv 2608.17202) | Defensive deception against safety-removal attacks on open weights | 2026 research |
| Tamper-resistant training (TAR and successors) | Make fine-tuning away from safety expensive in compute | Broken within months each cycle |
| Not releasing weights | The only defense that fully holds | A policy question, see 03-security-implications.md |
Assessment: every published weight-level defense has been circumvented within months. The working assumption for a defender is that a safety-removed variant of every open-weight model exists the week it ships.
Boundary-level defenses (deployer side)
These are the controls that actually hold, because they do not depend on the model.
| Control | Notes |
|---|---|
| Sandbox: no network, no home directory, scratch filesystem | Our sandboxed coding harness and overnight runner already do this |
| Explicit routing, no fallback chains | A fallback fires on GPU contention, not on intent. Our LiteLLM config enforces this for abliterated routes |
| Never unattended | No cron, no auto-retry into a safety-removed route |
| Tool allow-lists with approval on destructive actions | The model's judgment about destructive actions is exactly what ablation weakens |
| Input classifier for prompt injection | protectai/deberta-v3-base-prompt-injection-v2 is cached locally; useful, not sufficient |
| Output policy engine before side effects | Regex plus a stock-model judge on anything that leaves the sandbox |
| Egress logging | Everything the model sends out is recorded |
Detection: is a served model safety-removed?
Open question worth a project of its own. Signals in the literature and our notes:
- Near-zero over-refusal on XSTest-style benign-borderline prompts (stock models refuse
5 to 25 % of those; ablated ones refuse roughly none).
- Elevated KL from the published base on harmless prompts.
- Verbosity and sycophancy shifts.
- Hash or fingerprint mismatch against the publisher's weights (only works for
self-hosted weights you can inspect).
A fingerprinting harness is a candidate task in tasks/.
Sources
arXiv 2510.02768, 2505.19056, 2609.16204, 2608.17202 · International AI Safety Report 2026 (arXiv 2602.21012) · dev.to mech_app_ai "Abliterated Models in Production" (2026) · a10networks.com model-abliteration-ai-safety