Always, when the model came from outside the organisation or passed through multiple build and deployment formats. Conversion is where hidden logic can persist unnoticed, so it should be treated as a control point for inspection, not a neutral packaging step.
Why model conversion should be treated as a control point
Model conversion is not just packaging, because it can change the trust boundary around the artifact. A model that is imported, translated, quantized, exported, or repackaged may still carry hidden behaviour, embedded logic, or dependency assumptions from the previous stage. That is why the checkpoint belongs at conversion, not only at original ingest or final deployment.
Teams should think of conversion as a place where integrity can be preserved, weakened, or obscured. If the model crossed organisational boundaries, came from a third party, or moved through several tooling formats, conversion is one of the few moments when the team can compare the artifact against what was intended and verify that the same model is still being deployed.
Conversion also matters because operational teams often treat it as a neutral engineering step. In practice, it can hide changes to weights, metadata, tokenizer behaviour, runtime wrappers, safety layers, or attached assets. A model can look “the same” after conversion while still carrying risk that only becomes visible when the artifact is inspected as a security-relevant object.
What should be checked during conversion?
The main objective is to verify that the converted artifact matches the approved source in provenance, structure, and expected behaviour. That means checking whether the source was trusted, whether the conversion tool preserved the right files and dependencies, and whether any unexpected logic, payload, or embedded configuration appeared during the transform.
For teams handling models as deployable assets, conversion should be paired with artifact inspection rather than assumed to be lossless. Useful checks include hash or signature comparison where available, validation of model format contents, review of associated files and manifests, and confirmation that the converted artifact still points to the expected source lineage. The point is not to prove the model is harmless, but to prove the conversion did not introduce an unreviewed change.
When the pipeline involves multiple formats, the checkpoint becomes more important because each translation can change observability. A model may pass through source code export, containerisation, registry storage, and deployment wrapping before it is used in production. Each step is an opportunity for drift, and the conversion step is where that drift is easiest to catch before it becomes operationally normalised.
Where conversion failures become security issues
Conversion failures become security issues when teams assume equivalence without verification. A malicious or compromised upstream artifact can survive repackaging, and a legitimate artifact can be altered by tooling, dependency substitution, or unintended inclusion of extra files. If the checkpoint is skipped, the team may deploy a model that has not been inspected in its final form.
One practical concern is that converted artifacts can carry inherited behaviour that is hard to notice in routine review. Another is that teams may only scan the original source, then trust downstream build products automatically. That creates a blind spot where the security review covered the wrong object.
For teams evaluating model supply chain controls, the most relevant question is whether the conversion step changes the model in ways that affect trust, lineage, or deployability. If the answer is yes, then the conversion step is part of the security boundary and should be governed accordingly. That principle is reflected in AI Supply Chain Security and AI-BOM Guide, which frames models, data, packages, tools, and connected dependencies as a supply-chain integrity problem.
Risk and Threat Considerations
Conversion creates a realistic opportunity for hidden logic, malformed dependencies, or unnoticed drift to survive into production. The risk is highest when the model came from outside the organisation or moved through multiple build formats, because trust is then inherited across more than one toolchain and review boundary.
Failure mechanism: An attacker or compromised upstream process can place malicious behaviour, unsafe configuration, or unreviewed payloads into a model before conversion, then rely on the transform pipeline to preserve it while making the final artifact look routine.
Impact: The organisation may deploy a model that appears validated but still contains untrusted logic, creating exposure to integrity failure, unsafe outputs, downstream compromise, or a later-stage incident that is harder to trace back to the original source.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Build Integrity | Model conversion is a provenance and artifact-integrity checkpoint. |
| Recommendation — Verify conversion outputs against trusted provenance before promotion. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | Conversion can change model configuration, packaging, and deployment state. |
| SA-12 — Supply Chain Protection | External or multi-stage model conversion creates supply-chain trust risk. | |
| Recommendation — Review converted model configuration before deployment. Apply supply-chain controls to third-party or transformed models. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Converted artifacts can inherit or introduce unsafe deployment settings. |
| Recommendation — Inspect transformed artifacts for unsafe configuration before release. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Converted models should be validated as release artifacts, not assumed safe. |
| Recommendation — Validate converted artifacts before they enter production release flows. | ||
Practitioner Guidance
What to prioritise: Treat conversion as a gate only when the artifact crosses a boundary you would otherwise have to trust, such as vendor to internal, research to production, or one build format to another. If provenance is weak, the conversion checkpoint should be stricter than a normal packaging review.
What to verify: Confirm that the converted artifact is traceable to the approved source, that no unexpected files or metadata were introduced, and that the conversion tool itself is approved for the specific format path. If the converted output cannot be compared meaningfully to the input, treat that as a review failure rather than an acceptable limitation.
Practitioner takeaway: The safest posture is to assume conversion can preserve hidden risk, not remove it, so the security decision is whether the converted model is still explainably the same artifact the organisation intended to trust.