Buying AI models: incoming inspection under ISO/IEC 27090

No manufacturer fits a bought-in part that has not passed incoming inspection. Delivery note against purchase order. Visual check. For critical parts, the inspection certificate. With AI models this step is missing almost everywhere. The model is downloaded, started and judged by whether its answers sound good. Done.

The new ISO/IEC 27090:2026 gives the supply chain a clause of its own (5.5) and a second section in the annex (B.3). Its starting point: beyond code and software components, AI brings further elements that need protecting. Pre-trained models. Training, test and validation datasets. The tools used for development (5.5.1, 5.5.2).

How serious this is shows in three documented cases from the past four years. From them and from the standard follows an inspection that a company without its own AI department can carry out. Or demand from its service provider.

A model file can be a program

The underrated point first. Many models are distributed in formats that can execute code while loading. Python’s widespread pickle format works this way. It stores the model’s numbers plus instructions on how to put the data back together. Whoever loads the file runs those instructions. Here, loading already means executing.

The standard describes this soberly. Backdoors and vulnerabilities can be used to embed malware in model weight files, up to arbitrary code execution (B.4.2). As a remedy it names safe formats such as safetensors, which do not execute code on loading, along with checksums, signatures and trusted repositories (B.4.3).

This is no lab scenario. In February 2024 the security vendor JFrog reported around 100 models with malicious functionality on Hugging Face, the best-known public platform for AI models. One of them opened a connection back to an outside server when loaded with PyTorch, a so-called reverse shell. Through such a connection, commands can be run on the machine where the model was loaded. The platform flagged suspicious files as unsafe. According to JFrog, it did not block the download.

A year later came the next step. In February 2025 ReversingLabs reported two models whose malicious code the platform’s scanner had not detected. The trick was simple. The files were compressed with 7z instead of the usual ZIP, and the malicious code sat right at the start of a deliberately broken file. The scanner reported the error at the broken spot and missed what came before it. On loading, exactly that front part ran first. Hugging Face removed the models in under 24 hours after being notified and improved the scanner.

The lesson is simple. A scanner that looks for known dangerous patterns works like a blocklist. It finds what it knows. You only get real safety once the file cannot carry code at all. That is why, on my checklist, the format comes before the scan.

The tools belong to the supply chain too

The standard explicitly counts the development environment as part of the supply chain: notebook platforms, MLOps tools, training frameworks (5.5.2). They run constantly, see training data and model parameters, and that makes them a rewarding target. Among the attack vectors it lists malicious code in AI libraries that extracts sensitive data or manipulates model behaviour (5.5.4).

The best-known example hit PyTorch, one of the most widespread AI frameworks. Between 25 and 30 December 2022, anyone who installed the Linux nightly build via pip also received a foreign package called torchtriton. Someone had uploaded it under exactly that name to the public package index PyPI. The public index took precedence over PyTorch’s own index. As soon as the package was imported, a program inside it collected system information, SSH keys and up to a thousand files from the home directory and sent them out via DNS queries. The stable release was not affected.

The technical term is dependency confusion. For a mid-sized company the translation matters more. Your service provider installs dozens of libraries for an AI project, and each brings dependencies of its own. If nobody records which version came from which source, you cannot even say in an emergency whether you are affected. PyTorch could tell its users: with a check command and the checksum of the malware.

The standard names the underlying problem in 5.5.3. With conventional software it is usually clear who wrote which part. With AI, contributions from many suppliers flow into one another, in data, in weights, in code. A vulnerability can arise at any point in the chain and show itself so quietly that conventional security testing does not find it.

Fine-tuning cleans nothing

The obvious objection goes: we only use the model as a base and fine-tune it on our own data. The standard has a term for exactly this case. If a supplier delivers a deliberately manipulated model and the customer goes on training or fine-tuning it, the unwanted behaviour remains. The standard calls this a transfer learning attack (6.7.1).

Backdoors in models are treacherous because they sleep during normal operation. The model answers a thousand test questions correctly and flips only on a specific trigger. A word. A pattern in an image. A combination of sensor readings (5.5.4). A quality test on your own data finds something like that only by chance.

On detection, the standard stays honest. If a model is altered in-house, general attack detection can pick it up. If it arrives poisoned from the supplier, the main help is threat intelligence on known malicious sources and models (6.7.3). A method that reliably rules out a backdoor is not something it offers. Whether training data has been poisoned cannot, in its assessment, yet be detected reliably by automated means (6.2.3).

A model from an unknown source does not become more trustworthy through fine-tuning. It just becomes yours.

That leads to an uncomfortable rule. Provenance weighs more than any test. For operations the standard recommends zero trust principles: keep models segmented and encrypted, grant access only for as long and as far as needed, and apply several layers of checks before deployment (6.7.4). Running a model on a machine that cannot see the whole company network limits the damage if something does slip through.

Incoming inspection in seven steps

What does this mean for a company that downloads an open model or receives one from a service provider? I check in this order, following 5.5.5, B.4 and 6.11.4:

• Provenance: who published the model, is the publisher’s account verified, is there a model card with training data, licence and limitations? No model enters the company without a traceable sender.
• Format: weights only in formats that do not execute code on loading, such as safetensors. If only a pickle file is available, it is rejected or converted in an isolated environment without network access.
• Integrity: compare the checksum with the publisher’s value and verify the signature where one exists. The checksum goes into the record.
• Scan: check the file with a tool that looks for dangerous operations in model files (B.4.2). A clean scan is an indication. It is not an acquittal.
• Dependencies: libraries only from one defined source, versions pinned, regular scans against known vulnerabilities (5.5.5).
• Behaviour test: before release, test against a fixed test set, plus targeted attack attempts, including triggers that could flip the model (5.5.5, B.3.3).
• Release and record: who approved it, which version, which checksum, which source, which licence. Stored so that nobody can change the entries unnoticed (6.11.4).

Release does not end the inspection. The standard recommends monitoring the model’s performance continuously for signs of compromise (5.5.5). If accuracy drops for no visible reason, that is a case for information security. A better prompt does not close it.

For the record, clause 6.11.4 is the best template. It describes provenance documentation across the whole life cycle: training and inference data, architecture, software dependencies, configuration, processing pipelines. For training data it includes source, licensing conditions, pre-processing and any third parties involved. The entries should be protected against modification with digital signatures and be available for internal audits and post-incident reviews.

This is the same traceability every automotive supplier knows. Batch + inspection certificate + release. Only here the batch is called a model version. And the inspection certificate is a checksum you can recompute yourself.

What belongs in the contract

Not every company downloads model files itself. Depending on how you buy, the inspection shifts from the file to the contract:

For contracts, Annex B.3.3 lists four points. Supply chain security belongs in the contracts with everyone who supplies training data, pre-trained models, design or development. Suppliers receive security education. The exchange of specifications, such as the model card, deserves particular care. And supplied models are tested sufficiently with targeted attacks before use, known as red teaming.

In contract language I translate this as follows. The supplier names the base model, version and source. They deliver checksums and, where possible, signed files. They describe the training data well enough for you to judge licence and origin. They report every known vulnerability in the components used within a fixed deadline. And they submit a test report that includes attack attempts and not just accuracy.

With a model as a service, one more point applies, and Annex B.6.1 names it explicitly. If you have a model fine-tuned in the cloud with your own documents, you share those documents with the cloud service. That changes the threat environment. It belongs in the risk assessment and the contract beforehand.

For the supply chain, the standard itself refers to controls 5.19 to 5.23 and 8.30 of ISO/IEC 27002 (note to 5.5). If you are certified to ISO/IEC 27001, supplier relationships, supplier agreements and the ICT supply chain are therefore already in your management system (A.5.19 to A.5.21). In ISO/IEC 42001, by my own mapping, the topic attaches to A.10.3 for suppliers, A.7.5 for data provenance and A.6.2.4 for verification before deployment. Incoming inspection is the process that makes these controls auditable for AI.

What I ask first as an auditor

With purchased AI, the first thing I ask for is a single item: the checksum of the model file that is running right now, with version and source. If it comes out of the record, there was an incoming inspection. If someone has to go looking, there was a download.

The good news sits in the same question. None of this needs an AI lab. Comparing checksums, fixing formats, approving sources, keeping a record: this is craft from information security, applied to a new bought-in part. ISO/IEC 27090 supplies the reason why this part deserves the same incoming inspection as every bolt with an inspection certificate.