Why do unauthorised model pull and push paths create outsized risk in AI infrastructure?

Why This Matters for Security Teams

Unauthorised pull and push paths are not just storage hygiene issues. They define whether an AI platform can be used as a trusted supply chain or turned into a content relay for poisoned models, leaked weights, or malicious artefacts. When access is weakly scoped, an attacker may not need to break the model itself; they only need a path to alter what enters the runtime or what leaves it. That shifts the problem from isolated compromise to platform-wide trust failure.

Security teams often underestimate how quickly these paths become high-value targets because they sit between identity, storage, orchestration, and CI/CD. A single misconfigured token, service account, or bucket policy can let an unauthorised actor influence model provenance or exfiltrate sensitive assets. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it pushes teams toward explicit access control, auditability, and system integrity rather than informal trust in internal networks. In practice, many security teams encounter model tampering only after a release pipeline has already propagated the wrong artefact downstream, rather than through intentional approval gates.

How It Works in Practice

Pull paths determine what the platform can retrieve from registries, object stores, package feeds, or internal repositories. Push paths determine what the platform can publish back into those same trust zones. If either direction is too broad, the AI estate can be used as a bridge between low-trust and high-trust environments. That matters because model files, adapters, prompts, embeddings, and evaluation artefacts are often treated differently even though they can all alter system behaviour.

Operationally, teams should design these paths around identity and policy, not convenience. The minimum good practice is to bind access to authenticated workload identities, separate read and write permissions, and log every transfer with enough context to reconstruct provenance. Where model promotion is involved, approvals should be explicit and versioned, with checksum validation or signed artefacts before a runtime accepts a package. The same logic applies to export paths: if a model, checkpoint, or dataset can be pushed out, the organisation should know who authorised it, where it went, and whether it contained sensitive training content.

• Restrict pull permissions to named registries, buckets, and repositories.
• Separate export roles from operational runtime roles.
• Require signed artefacts or integrity checks before acceptance.
• Record pull and push events in central monitoring with identity context.
• Review service accounts and tokens used by pipelines, jobs, and agents.

Best practice is evolving around agentic AI because autonomous tools can trigger both retrieval and export without direct human action, so policies must cover machine-initiated movement as well as user-initiated change. The same control logic aligns with the NIST Cybersecurity Framework 2.0 emphasis on governed access, resilience, and monitoring. These controls tend to break down when development, training, and production share the same credentials because a single compromise can move laterally across the full model supply path.

Common Variations and Edge Cases

Tighter pull and push controls often increase friction for data science and MLOps teams, requiring organisations to balance release speed against provenance assurance. That tradeoff is real: overly rigid gates can slow experimentation, while loose paths can undermine the integrity of every downstream decision.

There is no universal standard for every AI topology yet. Some environments rely on internal registries with strong network segmentation, while others depend on ephemeral compute, remote model hubs, or agent-driven workflows that call tools on demand. In those cases, the question is not only whether a path is authorised, but whether the identity behind that path is stable, traceable, and limited to one purpose. NHI governance becomes relevant whenever a workload identity, API token, or service principal can retrieve or publish models without direct human interaction.

Another edge case is read-only access that still leaks value. Even if a path cannot push changes, broad pull privileges may expose proprietary weights, internal prompts, evaluation sets, or fine-tuning data. Conversely, a narrow push path can still be dangerous if it accepts unreviewed artefacts that later become trusted by deployment automation. The practical test is whether the platform can prove origin, purpose, and approval for every model movement, not just whether a login succeeded.

Related resources from NHI Mgmt Group

• Why do static credentials create outsized risk for AI agents and automation?
• Why do AI pipelines and model registries create governance risk?
• Why do AI model servers create NHI governance risk even when deployed locally?
• Why do generative and agentic AI create problems for traditional model risk management?