RUSI’s September 18 commentary focuses on the UK’s investigatory powers and the difficulties law enforcement will face as capable models move into private, hosted, and fully local deployments. But its most immediate lesson for Windows administrators, security teams, and developers is closer to home: an internal AI deployment may be private and compliant with data-residency requirements while still becoming harder to govern, audit, and contain than a vendor-operated API.
The think tank’s central argument is sound. Open weights are durable artifacts. A lab can issue a safer revision, but it cannot recall copies already on servers, workstations, cloud tenants, or third-party inference platforms. For organizations adopting local models to keep prompts out of public AI services, that shifts more responsibility to the operator—not merely for access control, but for proving what model is running and what it is permitted to do.
Model refusals are not a reliable control
RUSI cites Palisade Research’s work on removing safety fine-tuning from Meta’s Llama 3 models. The underlying Palisade report actually gives even faster figures than RUSI’s summary: it said researchers stripped safety training from Llama 3 8B in one minute and Llama 3 70B in 30 minutes on a single GPU. RUSI described the result as around five minutes for the 8B model and well under an hour for the 70B version.
The timing discrepancy does not change the security conclusion. In both accounts, the cost and effort required to alter the behavior of an open-weight model are small compared with the cost of training or even deploying one. An enterprise that approves a model because its official instruct release refuses dangerous requests has therefore approved a starting point, not a permanent control.
This distinction is often obscured in AI procurement. A model’s safety alignment is generally evaluated as behavior: ask for a disallowed task and see whether it refuses. That is useful testing, but it says little about whether the same behavior survives a modified checkpoint, a fine-tune, a different system prompt, a quantized build, a custom inference stack, or an agent framework that chains the model to tools.
A 2026 research paper from Carnegie Mellon researchers Kevin Kuo, Chhavi Yadav, and Virginia Smith reached a similarly uncomfortable conclusion. Their testing found that low-cost approaches including abliteration and prefilling could raise attack success rates against safeguarded open-weight models from below 10% to between 16% and 96%, depending on the model and benchmark. The researchers’ proposed mitigation, abliteration-resistant tuning, reduced those attack rates by 10% to 20%; it did not make the problem disappear.
That is the operational reality administrators should plan around. Model-level refusals can reduce ordinary misuse, but they cannot be the sole enforcement point when the organization or its contractors can change the model artifact itself.
“Abliterated” does not mean unchanged
RUSI says abliteration can remove refusal behavior while retaining most general capability. That wording needs a material qualification. Independent analysis from the Combating Terrorism Center at West Point notes that refusal removal can create measurable performance degradation and behavior that differs significantly from the safeguarded original. The process is not a clean removal of one harmless switch.
That matters for defenders as much as for safety researchers. A modified model may fail more than a misuse benchmark. It can become less predictable in ordinary business workflows, produce lower-quality decisions, or interact differently with code execution, search, email, document repositories, and other connected tools.
For a helpdesk chatbot, that may mean a higher rate of strange answers. For an internal coding assistant with repository access, a Windows automation agent with PowerShell permissions, or a model able to invoke cloud-management APIs, unpredictability is a more serious problem. A model that is willing to perform a task and a model that is competent enough to perform it safely are not the same system.
The CTC analysis also makes an important counterpoint to simplistic narratives around open models: open weights bring legitimate advantages in privacy, cost, local control, and digital sovereignty. RUSI makes the same point when discussing confidential computing and private inference. The policy and security question is not whether every organization should use only closed models. It is whether local control is accompanied by controls that are actually local, enforceable, and independently testable.
A refusal trained into a model is an application behavior. Tool permissions, identity controls, network segmentation, audit trails, and data-loss protections are system controls. They should be treated accordingly.
RUSI’s hosted-provider finding has limits
RUSI reviewed publicly available documentation for Together AI, Fireworks AI, Groq, DeepInfra, and Novita AI and found no public documentation of a universal, mandatory external safety classifier screening every prompt and response. In the report’s wording, available classifiers were configurable, separately invoked, or left to customers to integrate.
That finding should not be overstated. It does not establish that those providers apply no other protections, conduct no abuse monitoring, or never take enforcement action. It establishes a narrower and useful fact: a customer reading public documentation may not be able to assume that a uniform, unavoidable content classifier is present across every open-model endpoint.
For IT departments, the practical implication is straightforward. Do not infer a provider’s safety or monitoring architecture from the mere presence of a model API, a trust-and-safety page, or a hosted version of an official model. Contract terms, technical documentation, tenant configuration, retention policies, and actual test results all matter.
It also means companies should know whether their developers can quietly bypass an approved AI gateway. If a developer can send production data or privileged context directly to a third-party open-weight endpoint using a personal key, the organization’s approved logging, content controls, and data-governance rules may never see the exchange.
That is familiar territory for security teams that have dealt with shadow SaaS. Open-weight inference adds a twist: the alternative service may expose the same base model with different moderation, retention, identity, and jurisdictional characteristics.
Private inference moves the evidence to the endpoint
The most consequential part of RUSI’s paper may be its observation that private inference changes where useful evidence exists. In a conventional hosted AI service, a provider may possess account records, connection metadata, prompts, outputs, and abuse reports. With self-hosting, those artifacts can instead reside—if they are retained at all—on the user’s machine, a local server, an internal model gateway, an orchestration platform, or a tool-running agent.
RUSI argues that UK authorities should clarify how the Investigatory Powers Act 2016 applies to AI inference. It suggests that a hosted API session could fall within communications law, while local model prompts and responses may be private information on a user’s equipment rather than a communication transiting a telecommunications system.
That legal analysis is aimed at UK authorities, not U.S. enterprise policy. Yet the technical conclusion applies broadly: the model provider may no longer be the place to investigate an AI incident. If an internal agent misuses credentials, exfiltrates files through a tool call, or generates malicious scripts, the decisive evidence may be in endpoint telemetry, orchestration histories, local vector stores, service-account logs, and the agent’s generated artifacts.
This is why RUSI’s proposed term, “agentic forensics,” deserves attention. AI incident response cannot stop at preserving chat transcripts. Teams need to reconstruct the model version, system prompt, retrieval sources, tool definitions, user identity, delegated permissions, action history, generated files, API calls, and network destinations.
What enterprise administrators should control
Organizations self-hosting or privately serving open-weight models should build their controls around the full inference stack, rather than trusting the checkpoint’s advertised alignment.
- Maintain an inventory that records the exact model artifact, cryptographic hash, source repository, quantization, tokenizer, inference engine, system prompt, tool configuration, and deployment owner.
- Restrict who can pull, fine-tune, convert, or replace model artifacts, and treat a changed model hash as a production change requiring review rather than a routine model update.
- Separate the model runtime from privileged tools. A local model should not receive unrestricted PowerShell, file-share, Active Directory, cloud-administration, browser, or database permissions simply because it operates inside the corporate network.
- Log identity, model version, tool calls, external connections, and administrative changes while applying data-minimization rules to prompts and outputs. Private inference should not require turning every employee conversation into a permanent surveillance record.
- Test the deployed configuration, including its tools and retrieval pipeline, after each material model or agent update. Testing only the vendor’s original checkpoint is insufficient when the production deployment contains custom prompts, fine-tunes, and connectors.
- Prepare a containment procedure that can revoke agent credentials, isolate the runtime host, preserve relevant logs, and block outbound destinations without waiting for a model vendor to intervene.
RUSI is right to resist a simplistic answer in which providers are compelled to retain every prompt in readable form. Centralized prompt databases would be attractive targets for attackers and could undermine the privacy case that motivates many local AI deployments. The better enterprise answer is narrower: retain the security telemetry necessary to investigate abuse, protect sensitive content by design, and ensure privileged actions remain attributable and reversible.
The first wave of open-weight adoption was sold as a way to bring AI under organizational control. The next phase will test whether companies have actually done that—or merely moved a powerful, mutable model behind the firewall and assumed its built-in refusals would hold.