Model dependency

Expanded Definition

Model dependency describes how tightly a product’s runtime behaviour is tied to an external AI model, especially when the model is not locally controlled by the product owner. In practice, this means core features may stop working, degrade, or change unexpectedly if the model provider alters access terms, output behaviour, rate limits, or service availability. For security and identity teams, the key issue is not simply that an AI model is used, but that the product’s essential function cannot be validated or recovered independently when that model changes.

Usage in the industry is still evolving, and definitions vary across vendors. Some products frame model dependency as a resilience concern, while others treat it as a procurement or architecture issue. NHI Management Group treats it as a governance issue because it affects control over availability, integrity, and operational continuity. A product with high model dependency may inherit hidden risk from the model layer, including undocumented output shifts and weak fallback behaviour. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to manage external dependencies as part of broader risk governance.

The most common misapplication is assuming a product is resilient because it has an AI feature, when the real condition is that the feature fails if the external model becomes unavailable.

Examples and Use Cases

Implementing model dependency rigorously often introduces a design constraint, requiring organisations to weigh rapid AI capability delivery against long-term control over product behaviour and availability.

• A security chatbot routes every query to a third-party model, so a provider outage removes analyst assistance during an incident.
• A phishing detection tool depends on a hosted model for classification, and a silent model update changes alert volume and false positive patterns.
• An identity verification workflow uses a remote model to compare documents, creating a point of failure if latency or access controls change unexpectedly.
• An autonomous agent for SOC triage relies on a single model endpoint for reasoning and tool selection, making fallback design essential when provider limits are reached.
• A vendor claims “AI-native” functionality but cannot explain how the product behaves when model access is revoked, which is a sign of strong dependency and weak operational independence.

For AI-related products, practitioners should also review model governance expectations in NIST Cybersecurity Framework 2.0 alongside the product’s own recovery and continuity claims. The question is not just whether a model is present, but whether the product can still perform safely when the model is changed, degraded, or removed.

Why It Matters for Security Teams

Model dependency matters because it turns a third-party model into a hidden trust anchor. If security teams do not understand that dependency, they may approve tools that cannot sustain detection, response, verification, or automation when provider behaviour shifts. That creates operational fragility, audit difficulty, and a gap between what the product appears to do in testing and what it can actually guarantee in production.

For identity and agentic AI use cases, the risk becomes sharper. A model-dependent agent may rely on the provider for tool selection, policy interpretation, or action planning, which means changes in the model can alter execution authority in ways that are hard to detect. In NHI-heavy environments, this also affects non-human workflows that expect consistent machine-to-machine behaviour. Security teams should therefore ask whether the product has documented fallbacks, version controls, and validation checks that reduce reliance on a single model path.

Practitioners typically encounter the seriousness of model dependency only after the model is rate-limited, replaced, or decommissioned, at which point continuity, assurance, and vendor exit planning become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the Model Context Protocol (MCP) and why does it matter for security?
• What does AI model abuse reveal about the current NHI threat surface?
• Why do attackers often check model availability before trying to generate content?
• How does automated secret rotation change the operational model?