Security Review for Open-Weight Models Before You Deploy

Running an open-weight model is usually framed as a privacy improvement: the data never leaves your network. That is true, and it substitutes one risk for another. You are now downloading a multi-hundred-gigabyte binary artefact from the internet and executing a serving stack around it.

Almost none of the standard software supply-chain hygiene gets applied to model weights, largely because they do not look like code. They are still an untrusted input to a privileged process, and the review should look like one.

Provenance and integrity

Start with where the file came from. Pull weights from the vendor's official repository or an organisation account you can verify, not from a mirror with a convenient name or a re-upload with slightly better quantisation.

Verify checksums against the published values. This is basic and routinely skipped because the downloads are large and the tooling makes it easy to skip. A mismatched hash on a 1.6TB artefact — roughly the size of Kimi K3's weights — is not something you want to discover after deployment.

Pin an exact revision. Repositories are mutable, and pulling a branch name gets you whatever is there today. The same argument that applies to pinning model versions through an API applies with more force when you are executing the artefact yourself.

Prefer serialisation formats that do not execute code on load. Some historical formats deserialise arbitrary objects, which turns loading weights into running whatever the file author wanted. Modern tensor formats avoid this by design, and there is no good reason to accept one that does not.

The licence is a security question too

Licence review gets delegated to legal and then nobody reads the answer. It belongs in the deployment decision because it constrains what you are permitted to build.

GLM-5.2 ships under MIT. Both DeepSeek V4 variants ship under MIT. Those are unambiguous and impose essentially no restriction on commercial use. Qwen is permissive on most tiers.

Kimi K3 and Kimi K2.6 are not MIT. K3 ships under Moonshot's own custom licence with a revenue threshold that triggers additional terms for model-as-a-service offerings. If you are reselling inference, that threshold is the clause that matters, and it needs reading rather than assuming.

Open weights are not the same as open source in any case. Published weights without published training data or code is a distribution licence, not a licence to reproduce. Open weights versus open source covers the distinction and why it matters for auditability.

The serving stack is the larger attack surface

The weights are inert data. The inference server around them is a network service parsing untrusted input, and it is where the exploitable bugs live.

Treat it as you would any exposed service. Keep it patched, run it as an unprivileged user, and do not put it on a network interface that does not need it. Inference servers frequently ship with permissive defaults because they are developed for single-user experimentation.

Watch the auxiliary endpoints. Many serving frameworks expose metrics, admin or model-management routes alongside the inference API, and those routes often assume a trusted network. An admin endpoint that can load arbitrary weights from a path is a remote code execution primitive in most deployments.

Isolate the process from anything sensitive. The serving host should not hold production database credentials, cloud keys with broad scope, or a path to internal services it does not need. Agent sandboxing covers the same containment argument for tool execution.

Model behaviour as a threat surface

Self-hosting removes provider-side filtering. Whatever guardrails the hosted API applied are now yours to build, and their absence is often the first surprise.

Prompt injection is unchanged by self-hosting and sometimes worse, because self-hosted deployments tend to be wired directly into internal systems. A model reading a document that contains instructions will follow them if your architecture lets it. Prompt injection and agent security covers the mitigations, none of which are model-side.

Do not treat model output as trusted input to anything else. Generated SQL, shell commands, file paths and URLs all need the same validation you would apply to user input, because functionally that is what they are. Generating SQL safely covers one common case.

Assume any data you put in the context window can come back out. That is a property of the mechanism, not a bug, and it means multi-tenant deployments need isolation at the request level rather than trust in the model.

Data flow and residency

Write down where inference physically happens, because this is usually the reason self-hosting was proposed and it is easy to undermine accidentally.

A rented GPU in another jurisdiction is not the same as on-premise for most compliance regimes. Check the region of every host in the path, including anything doing load balancing or logging. Running frontier models on rented GPUs covers what a rented deployment actually gives you.

Then check what your own stack logs. Prompt and completion logging is on by default in a lot of tooling, and a self-hosted deployment that writes full prompts to a centralised log has recreated the data exposure it was built to avoid, only with worse access controls.

A pre-deployment checklist

Weights pulled from a verified official source, at a pinned revision, with checksums verified and in a non-executing serialisation format. Licence read in full, with any revenue or service thresholds noted against your actual business model.

Serving stack patched, unprivileged, network-restricted, with admin and metrics endpoints closed. No broad credentials on the inference host. Output treated as untrusted everywhere it is consumed.

Inference region documented, prompt logging reviewed and restricted, and a named owner for tracking upstream security advisories on the serving framework. None of this is exotic; it is ordinary supply-chain practice applied to an artefact that usually escapes it.