Why do shared ML artifacts increase code execution risk?

Why This Matters for Security Teams

Shared ML artifacts are not just storage objects. They are trust carriers, because a model, pickle, notebook cache, or serialized tensor can be reused across projects, users, and automation paths. That reuse is what makes them dangerous. If one pipeline writes an artifact and another pipeline later loads it with broader privileges, the artifact can become an execution path rather than a passive dependency. The risk rises when teams treat “internal” artifacts as safe by default.

This problem shows up in environments where notebooks, CI jobs, and model registries all share the same back-end storage. A file that looks like a harmless performance cache may contain executable serialization logic, and the loader may deserialize it automatically. NHIMG has documented how weak identity and artifact governance widen this blast radius in practice, including the broader patterns described in Ultimate Guide to NHIs — Key Challenges and Risks. The underlying lesson aligns with the NIST Cybersecurity Framework 2.0: trust has to be bounded, monitored, and continuously validated, not inherited from the storage location.

In practice, many security teams encounter code execution through shared artifacts only after a downstream job has already loaded the file under elevated service-account permissions.

How It Works in Practice

The risk emerges when artifact format, loader behavior, and privilege context line up. Some ML ecosystems use serialisation formats that can invoke object constructors or deserialisation hooks during load. If that load happens in a training service, CI runner, or inference pipeline with access to secrets, package registries, or cloud metadata, the artifact can trigger code execution with the loader’s permissions.

That is why the question is less about “files” and more about execution authority. Shared artifacts often move across trust boundaries: a data scientist publishes from a notebook, another team consumes through a registry, and automation rehydrates the object later. Once the object is shared, the creator no longer controls the runtime context. NHIMG’s guidance in OWASP NHI Top 10 and the incident analysis in Gemini CLI Breach — Silent Code Execution both reinforce the same operational point: content that can influence execution must be treated as untrusted until proven otherwise.

• Prefer safe serialization formats that do not execute code on load.
• Run artifact ingestion in isolated, least-privilege environments.
• Sign and verify artifacts before consumption.
• Separate write permissions from load permissions in registries and pipelines.
• Scan shared artifacts as untrusted input, not as internal cache.

Current guidance suggests that policy must be enforced at the point of load, not only at the point of publish. If a loader can automatically deserialize arbitrary objects in a production pipeline, then the shared artifact becomes an execution primitive. These controls tend to break down in notebook-heavy workflows and model registries that allow implicit deserialization because the consumer cannot reliably distinguish safe metadata from executable payloads.

Common Variations and Edge Cases

Tighter artifact controls often increase developer friction, requiring organisations to balance safe reuse against faster collaboration. That tradeoff is real, especially when teams want a single registry for models, feature stores, and experiment outputs.

Best practice is evolving, and there is no universal standard for every ML framework yet. Some environments can safely share immutable, signed artifacts with strict format restrictions. Others need quarantine, conversion, or one-way promotion from training to serving. The safest pattern is to assume that any shared object may be malicious until verified, especially when it crosses from experimentation into production.

Edge cases matter. Internal artifacts are often the riskiest because trust is implicit, not because the storage system is exposed to the internet. A low-privilege contributor can plant a payload that is later loaded by a privileged build agent, service account, or inference worker. That is why NHI governance and access control remain relevant here, as described in Top 10 NHI Issues. For teams mapping this to control language, NIST SP 800-53 Rev 5 Security and Privacy Controls supports the practical need for least privilege, input validation, and system integrity checks across the artifact lifecycle.

Where shared artifacts cross environment boundaries, especially from research to production or from tenant to tenant, the trust model usually breaks first because the loader’s privileges are higher than the creator expected.

Related resources from NHI Mgmt Group

• Why do shared data directories increase supply chain risk in ML pipelines?
• Why do spreadsheet import endpoints increase remote code execution risk?
• Why do copied AI framework patterns increase remote code execution risk?
• Why do unauthenticated management endpoints increase remote code execution risk?