_Post 19 of the AI in cyber series._
The open-weight reasoning model era arrived in earnest in 2024 with Llama 3, Mistral's open releases, and the post-DeepSeek wave. By 2026, the operational reality is that a UK security team can run a frontier-capable reasoning model on a single server they own, with no dependency on a hyperscaler, at a marginal cost approaching zero per query. The economics are now as I predicted in the post 5 open-source piece.
What I did not write enough about at the time, and what this post is for, is the provenance question. Where does this model come from, who trained it, what licensing and what data-handling regime governs it, and what does that mean for the cyber security workload that runs on top of it? This is the supply-chain-of-intelligence question and it is increasingly the procurement question.
What is different in 2026
Three structural shifts.
Open-weight frontier-class models exist. DeepSeek-R3, the open-weight reasoning variants from several Chinese labs, the Mistral-derived European releases, the various Llama-4 derivatives. The performance gap between hosted incumbent models (Claude, GPT, Gemini) and the open-weight frontier on most enterprise security tasks is small enough to be operationally uninteresting. The customer who downloads an open-weight model in 2026 is downloading frontier capability.
Provenance is not always clear. A model that ships under an open-weight licence does not necessarily come with documented training data, documented training compute, documented safety evaluations, or documented integrity guarantees. Some do. Many do not. The licence is permissive; the provenance is opaque.
Deployment is now operationally trivial. The tooling (vLLM, SGLang, TensorRT-LLM, Ollama) has matured to the point where deploying a frontier-capable open-weight model on a single GPU server is a Saturday afternoon's work. The barrier is no longer technical.
The combination — frontier capability, opaque provenance, trivial deployment — is the supply-chain question.
What the supply-chain risks actually are
Three categories worth distinguishing.
Training-data risk. A model trained on data the customer would not have wanted in scope — copyrighted material the customer cannot license, personal data that should not have been processed, proprietary data from competitors. The model output may, in some cases, reproduce training-set content. The customer's downstream use of that output carries the risk.
Provenance risk. A model whose training process is not documented could, in principle, have been trained to behave in ways that are not aligned with the user's interests. The most-discussed version is backdoor risk — the model behaves correctly on benchmark tasks and produces compromised output on specific triggers. The technical literature on whether and how this can be reliably detected is still developing. The honest position in 2026 is that for high-stakes deployments, we cannot fully verify what a third-party model is doing is a real concern that has to be managed by other means.
Licensing risk. Some open-weight model licences have terms that bite in unexpected ways — restrictions on commercial use above thresholds, restrictions on training derivative models, retroactive terms changes. The vendor's general counsel needs to read each license carefully. Open weights is not the same as no restrictions.
These risks apply equally to security AI deployments and to AI deployments generally. They are sharper for security AI because the consequences of a compromised model in security operations include direct compromise of the customer's environment.
What good practice looks like in 2026
Four practical pieces of work for any organisation running open-weight models in security operations.
Pin the model artefact. Treat the model as you would treat any software dependency. Specific version. Cryptographic hash. Stored in your own model registry. Re-downloaded from the upstream only when you have decided to update. The hosted-LLM-style the version updates on us problem is, in the open-weight world, optional. Most organisations have, in 2026, not yet exercised the option.
Document the provenance. Where did the model come from? Who trained it? What training data was used? Has the model been independently evaluated? The answers are sometimes available and sometimes not. Where they are not, the customer's risk register should record the gap explicitly rather than assume good provenance.
Run the model in a constrained environment. The open-weight model has, by construction, the same risks as any large LLM. Constrain its action vocabulary. Apply the constrained-agency pattern from post 8. The fact that the model is on your own hardware does not reduce the need for the operational discipline around it.
Have a fallback model. If the model you are using turns out to have a problem — a backdoor is discovered, a licence issue arises, the provenance turns out to be different from what was claimed — what is your switching path? The fallback model is the operational-resilience answer. We will switch to a different open-weight model is a workable answer; we depend on this one specifically is less workable.
How EmilyAI handles this
A specific note on how the EmilyAI architecture has accommodated the open-weight model wave.
EmilyAI's analyst core is not a large language model. It is a purpose-built classifier pipeline running deterministic INT8 inference, trained on labelled security-domain data, with the cross-tenant feedback loop. The supply-chain question of where did this model come from is answerable because we built it: the training process, the training data, the evaluation regime are all under our own control.
What does sit upstream of us is the augmentation layer — the open-weight or hosted reasoning models that our human analysts use when investigating the cases EmilyAI escalates. We have moved this layer to open-weight reasoning models running on the customer's own hardware (or ours, for the SaaS topology) through 2025-26, and the provenance disciplines above are how we govern the layer. The analyst tier is provenance-clean by construction; the augmentation tier is provenance-governed by procedural discipline. The boundary between the two is the operational firewall.
This is, I think, the right architectural shape for organisations running AI in cyber security in 2026. The verdict-making layer should be controlled by the organisation; the augmentation layer should be governed but can be open-weight; the boundary between them should be clean.
What I think happens in 2026-27
Three short predictions.
Open-weight model provenance becomes a procurement criterion. The wave of which model are you using and where did it come from questions is, in 2026, just starting to land in regulated-firm procurement. By 2027 it is standard. Vendors who can document provenance will win deals against vendors who cannot.
Model evaluation tooling for backdoors matures. The current state of the art on detecting subtle model backdoors is limited. Several research groups are working on it. By 2027 there will be commercial evaluation services that produce defensible provenance reports for open-weight models. This will significantly improve the picture.
A high-profile open-weight-model incident lands. I expect, before the end of 2026 or early 2027, a major case where a widely-deployed open-weight model is found to have been compromised or to have provenance problems that affect downstream users. The shape will not be the catastrophic backdoor scenario the most alarmed commentary anticipates; it will be a more mundane case of the training data turned out to include X and the licensing implications are Y. The case will set procedural expectations for the rest of the field.
What this month looks like
Two short pieces of work.
One: if your organisation is running open-weight models in security or operational contexts, write down the supply-chain inventory for each. Provider, licence, provenance, deployment topology, fallback plan.
Two: read the AI provider section of the Cyber Security and Resilience Bill secondary legislation once it publishes. The provenance question will, on the trajectory the drafting suggests, become a regulated obligation.
What is next
In six weeks: a longer reflective piece. Six years of EmilyAI. What we kept, what we changed, what we should have done sooner. The architectural retrospective the series has been building toward.