Foundation Model Dependency

What Foundation Model Dependency Means

Foundation model dependency is not just “using an AI model.” It is a structural reliance on an external provider for core inference, model updates, or generation behaviour, which means the consuming organisation inherits upstream decisions it does not fully control.

This matters because the dependency sits in the operational path of important workflows. If the provider changes the model, alters policy, throttles access, or removes a capability, the consumer may see immediate impact even when its own systems have not changed.

Why This Creates Concentration Risk

The central risk is concentration: many organisations can end up dependent on the same model family, API, or hosting chain for similar business functions. That creates correlated failure, correlated policy shifts, and a shared exposure to outages, content-filter changes, and service terms that are outside the consumer’s control.

Concentration risk is especially important when the model shapes customer-facing decisions, internal knowledge work, or public-interest outputs. In those settings, a single upstream change can affect quality, availability, legal posture, and trust at the same time.

What Actually Becomes Dependent

Dependency can extend beyond the model weights themselves. Organisations may rely on the provider’s moderation layer, safety tuning, retrieval settings, logging behaviour, billing controls, or update cadence, all of which can alter the effective system without a local code change.

That is why foundation model dependency is partly a governance problem, not only a technical integration problem. The real question is what the business can still guarantee if the provider changes behaviour, access conditions, or retention rules.

Operational Consequences and Control Expectations

When a workflow depends on an external foundation model, resilience planning should assume provider-side change as a normal condition rather than an edge case. Organisations need clear fallbacks for degraded service, model substitution, human review, or restricted mode operation when the upstream dependency becomes unstable.

Documentation should also distinguish between what the organisation controls and what it merely consumes. For example, it should be clear whether the provider handles updates, whether outputs are stored or reused, and which business processes would be disrupted if the model changed behaviour overnight. For vendor scoping and contract questions around this kind of dependency, the Third-Party AI Risk Guide is the most relevant internal reference.

Risk and Threat Considerations

Foundation model dependency creates exposure to provider concentration, sudden model drift, service interruption, and policy changes that can break downstream workflows without warning. It also increases the blast radius of a single supplier compromise, since many customers may consume the same model or update channel.

Failure mechanism: The consumer’s business process inherits upstream changes in inference behaviour, data handling, or availability, while local controls may not detect the shift until outputs, logs, or service quality deteriorate.

Impact: Decisions can become inconsistent, regulated workflows can fail, recovery can slow, and the organisation may lose the ability to reproduce or explain model-driven outcomes. In supply-chain cases, dependency also broadens the trust boundary, as shown by incidents such as the LiteLLM PyPI package breach and by the broader open-source dependency posture described by OpenSSF.

Practitioner Guidance

Governance implication: Treat the model provider as a material dependency, not just a feature supplier. Ownership should extend to vendor risk review, service continuity assumptions, data-handling terms, and the conditions under which the organisation can switch models or revert to a safer operating mode.

What to watch for: A dependency becomes more material as more workflows, teams, or customers rely on a single model API, especially when the same provider also controls updates, moderation, or retention settings. That is the point at which resilience planning and contractual scope should be reviewed together.

Related resources from NHI Mgmt Group

• Shared Responsibility Model
• How should security teams govern custom foundation model training on proprietary data?
• 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?