Who is accountable when a model file leads to code execution?

Why This Matters for Security Teams

When a model file can trigger code execution, the risk is not limited to the model format itself. The real issue is that a seemingly passive artefact has crossed into an execution path, often through deserialisation, plugin loading, or an agent runtime that trusts the file too much. That turns model supply chain review, service account scope, and runtime policy into a single accountability problem.

NHIMG research on the Gemini CLI Breach — Silent Code Execution shows how quickly a file-handling assumption can become an execution issue, while Analysis of Claude Code Security highlights the growing need to treat model-adjacent workflows as controlled software paths, not inert data flows. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that accountable ownership must exist for system and information integrity, privilege management, and code execution boundaries.

In practice, many security teams discover the accountability gap only after a model import, connector, or inference service has already executed untrusted code.

How It Works in Practice

Accountability needs to be mapped across three layers: the artefact owner, the runtime owner, and the identity owner. The artefact owner is responsible for proving what the model file contains, where it came from, and whether it is allowed to be loaded. The runtime owner is responsible for preventing the file from becoming executable without inspection. The identity owner is responsible for ensuring the service account or workload identity used at load time cannot do more than the task requires.

For practitioners, the control pattern is straightforward even if implementation varies. Use signed provenance for model artefacts, strict allowlisting for loaders and deserialisers, and short-lived credentials for any process that can touch the file. Where agentic systems are involved, current guidance increasingly favors workload identity and runtime policy checks over static RBAC alone, because the decision point is the request, not the role. That means policy must evaluate what is being loaded, by which service, from which source, and with what execution privileges.

• Assign explicit ownership for model ingestion, validation, and execution paths.
• Require provenance checks before a model file can be consumed by a runtime.
• Separate read access to artefacts from the privilege to execute associated code paths.
• Bind service accounts to the smallest possible loader and inference permissions.
• Log every model load, parser action, and execution transition for forensic traceability.

This aligns with NHI governance in the Ultimate Guide to NHIs, especially where long-lived secrets, excessive privilege, and weak offboarding create the conditions for silent execution. For identity controls, NIST guidance on digital identity and least privilege remains relevant, but it must be applied to non-human workloads rather than human sign-in patterns. These controls tend to break down when model files are loaded inside CI/CD pipelines or agent frameworks that reuse broad service credentials because execution and trust decisions happen too early and too fast.

Common Variations and Edge Cases

Tighter model-file controls often increase operational overhead, requiring organisations to balance faster experimentation against stricter provenance and execution checks. That tradeoff becomes sharper in environments that convert models, unpack archives, or use custom parsers, because the line between data handling and code execution is easier to cross than many teams expect.

There is no universal standard for this yet, but current guidance suggests treating any file format that can trigger execution as a software supply chain asset, not a passive artefact. In notebook-heavy teams, accountability may sit with platform engineering if the notebook runtime auto-loads models. In MLOps pipelines, it may sit jointly with the model registry owner and the pipeline owner. In autonomous agent systems, the service account that retrieved the model may also be accountable if it had permission to chain tool use after load.

One common failure mode is inherited privilege. A deployment robot or orchestration service may have been granted broad rights for convenience, then later reused for model handling without a fresh risk review. Another is ambiguous ownership, where security expects engineering to review the file and engineering expects the vendor format to be safe. NIST control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls support formal accountability, but the organisation still has to assign a named owner for artefact trust, runtime execution, and credential scope.

Related resources from NHI Mgmt Group

• Who is accountable when a workflow platform vulnerability leads to code execution?
• Who is accountable when a public application flaw leads to secret exposure and code execution?
• Who is accountable when a control-plane bypass leads to fabric compromise?
• How does the consumer-secret-entitlement model help with governance at scale?