Model Poisoning and the Sealed Corpus: Training on Data You Can Vouch For

Security teams entered 2026 with model poisoning and AI supply-chain attacks near the top of their risk registers, and the frameworks have followed. The OWASP guidance for large language model systems now treats data and model poisoning, and the supply chain around weights, adapters and training sets, as distinct top-tier risks rather than footnotes. A model is only as trustworthy as the data it learned from, and that data arrives through a long chain of third parties nobody has fully inspected.

The regulatory calendar sharpens the point. The EU AI Act's Annex III list of high-risk uses, which brings data-governance and record-keeping obligations into force for the systems that decide things about people, was once due to apply on 2 August 2026. After the Digital Omnibus deferral, those obligations now apply from 2 December 2027, but the proof requirements survive the move unchanged, so the sensible response is to build now rather than wait. DORA has applied to financial entities since January 2025, NIS2 has widened the base of accountable operators, and ISO/IEC 42001 gives boards a management-system standard. Across all of them runs one quiet demand: be able to say what went into your systems, and prove it.

Why fine-tuning is the exposed surface

Model poisoning is the deliberate corruption of what a model learns. An attacker does not need to breach your network at inference time if they can influence the data you train on. A handful of tampered records can teach a model a backdoor that behaves normally until a specific trigger appears, or bend its outputs on a narrow class of inputs in ways an accuracy score never surfaces.

Fine-tuning is where this becomes most acute for the enterprise. Few organisations pre-train a foundation model from scratch. They adapt one, and the adaptation data is drawn from scraped corpora, third-party datasets, contractor annotations and internal documents of uneven origin. Parameter-efficient methods that attach small trained adapters to a base model have made this cheap and fast, which is why they widen the attack surface. You cannot defend a corpus you cannot see, and cleanliness at the point of training is a provenance problem to solve before the first gradient step, not a scanning problem for afterwards.

The sealed corpus as a governance object

A sealed corpus turns the training set from a loose collection of files into a governed object with a known boundary. Every item admitted carries a record of where it came from, who approved it, when it entered, and what it contains. Nothing joins without that record, and the record travels with it.

The seal is cryptographic, not merely procedural. Each ingested item and each version of the corpus is hashed and signed, so any later alteration is detectable rather than deniable. Because the threat model now includes quantum-capable attackers harvesting signed material to forge later, the signatures are drawn from post-quantum algorithms. The result is a corpus whose contents at any moment can be reconstructed and attested, and whose history cannot be quietly rewritten.

“An organisation can only vouch for a model if it can name, verify and sign for every item that shaped it, and that is a property of the pipeline, not of the finished weights.”

Hardware you control changes the question

Provenance records are worth little if the training itself happens somewhere you cannot see. This is where the architecture of a Sovereign Intelligence Operating System matters. A SIOS runs offline on operator-owned hardware, and fine-tuning happens inside that boundary rather than on rented infrastructure. The corpus, the training run and the resulting model stay inside the perimeter unless the operator chooses to release them.

This is a design distinction, not an accusation against any provider. A shared-tenancy cloud model of security asks you to trust the operator, their staff, their subcontractors and the legal regime they sit under. Under instruments such as the US CLOUD Act, data held by certain providers can be reachable by legal process regardless of where the servers sit. For a model whose training data includes regulated or nationally significant material, keeping the pipeline inside a boundary you own is a stronger guarantee. When training runs on hardware with an attested identity, the audit trail can bind a corpus version to a machine and a run, so you are not asserting that a model was trained on approved data but demonstrating it against records a third party can check.

A zero-egress perimeter and inbound gate

The cleanest way to stop poisoned data entering a corpus is to make entry the only controlled event that matters. A zero-egress design means the system does not reach out to the open internet during training or inference, removing an entire class of exfiltration and live-tampering risks. Data crosses the perimeter inbound through a single gate, and everything that passes is inspected, recorded and signed before admission.

This inverts the usual posture. Rather than training on a wide surface and hoping to catch contamination later, the corpus grows only by deliberate, logged admission. The gate is where provenance is established once, so everything downstream inherits it. An item with no acceptable origin does not get in.

Verifying behaviour, not just inputs

Provenance answers what went in. It does not, on its own, answer whether the model now behaves. Some poisoning is designed to survive clean-looking data by exploiting subtle correlations, so a serious pipeline pairs a sealed corpus with checks on the resulting model.

Cross-model consensus is one such check. Rather than trusting a single model output on sensitive tasks, several independently trained models are asked the same question and their answers compared. A backdoor planted in one lineage tends to reveal itself as a divergence the others do not share. This will not catch every manipulation, but it converts a silent point of failure into a measurable disagreement an operator can investigate. These checks belong in the same signed audit chain as the corpus, so the record shows which model, on which data, gave which result.

What an organisation can actually vouch for

Put together, the sealed corpus, the owned hardware, the attested identity, the signed audit chain and the inbound-only perimeter let an organisation make a claim that is narrow, precise and defensible. It can state which items its model was trained on, verify the set has not changed, name the machine the training ran on, and show the behavioural checks that followed. That is stronger than an assurance that a supplier followed good practice.

It also maps onto what the regulations ask for. The data-governance and record-keeping expectations behind the EU AI Act high-risk regime, the operational-resilience demands of DORA, and the auditable management system of ISO/IEC 42001 all reward the same underlying capability: an evidence trail a third party can inspect. Provenance you can prove is not a compliance tax. It is the artefact the regime is trying to elicit. The engineering behind this sits within an estate of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, filed and patent pending and never granted or patented, covering the sealed corpus, the attested runs and the signed chains.

Where this is heading

As high-risk obligations mature and supply-chain attacks grow more patient, the burden of proof will keep shifting from the party that suspects a model to the party that deployed it. A buyer who cannot say what their model learned from will find that gap widening into a liability. Vouching for a model has to be an engineered property, established at ingestion and carried through every step, not confidence added at the end. Fine-tuning on a sealed, provenance-tracked corpus, on hardware an organisation controls, is how that property is built.