Model dependency

How model dependency changes product resilience

Model dependency describes how much a product’s core behavior depends on an external AI model at runtime. The more central that dependency is, the more the product inherits the model provider’s availability, latency, versioning, policy changes, and behaviour shifts as part of its own operating profile.

This matters because the product is no longer just using AI as a feature, it is relying on the model as a live dependency. If the model is unavailable, rate-limited, degraded, or changed in a way the product was not built to absorb, core functions can fail or become inconsistent.

Where model dependency shows up in security tools

In security products, model dependency becomes especially visible when validation, triage, summarisation, or decision support is embedded in the core workflow. A tool may still start, but its practical value can collapse if the external model is unreachable or no longer behaves the way the product expects.

That creates a governance problem as well as a reliability problem. If operators cannot explain what the product does when the model changes, they may be assuming a level of determinism, continuity, or control that does not actually exist.

Model dependency is therefore not just about whether the model works today. It is also about whether the product has a defensible fallback when the upstream model service is altered, constrained, or withdrawn.

Why external model reliance is fragile

External model reliance introduces a trust boundary the product owner does not fully control. The model provider can change access rules, pricing, output behaviour, safety filters, or service quality, and those changes can affect the product even when the product code itself has not changed.

Dependency also creates concentration risk. If one model underpins many features, a provider outage or policy shift can cascade across detection, review, automation, and user-facing outcomes at once. That is why resilience planning has to treat the model as an operational dependency, not just a component.

When organisations depend on hosted AI services, it is useful to understand the surrounding supply-chain and control context. For broader open source dependency risk and ecosystem hardening, OpenSSF is a relevant reference point for security-minded dependency management, even though the exact risk here is model availability rather than software package integrity.

Governance and continuity implications

Model dependency should be treated as a design and governance question, not only an engineering one. Teams need to know what happens when the model is unavailable, downgraded, or replaced, and whether the product can still validate results, continue operating safely, or recover cleanly.

That governance lens is strongest when the product performs security-sensitive work. If users or downstream systems rely on the output, the organisation needs clarity on fallback modes, acceptable degradation, and who approves continued use after the upstream model changes.

For control-oriented thinking, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful control vocabulary for integrity, configuration, and contingency thinking, while NIST Cybersecurity Framework 2.0 is helpful when the issue is framed as governance, recovery, and resilience across the product lifecycle.

Practitioner Guidance

What to watch for: Model dependency is highest risk when a product cannot explain its degraded mode, cannot operate without live inference, or silently changes behaviour after an upstream model update. That is the point where the dependency becomes a business and security control issue, not just a technical integration detail.

Governance implication: Practitioners should assign an owner for model continuity, define what acceptable fallback looks like, and require explicit review before a dependency on a provider-controlled model is treated as stable. Where the product depends on model output for security decisions, that review should also cover validation and recovery expectations.

For adjacent assurance and threat-modeling perspectives, NIST AI Risk Management Framework helps frame AI-related risk decisions, and NIST Privacy Framework can be relevant where model dependence affects data handling, monitoring, or trust in automated outputs.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised dependency exposes model traffic and internal services?
• What should teams do when a model or plugin dependency is compromised?
• What breaks when a pre-trained model or dependency is hijacked in an ML environment?
• What do security teams get wrong about AI model dependency?