An AI dependency is any hosted model or connected service that a business process relies on to complete work. In security terms, it should be treated like a governed service with defined owners, access scope, fallback behaviour, and monitoring when it touches sensitive data.
What an AI dependency is in practice
An AI dependency is not just “using AI”, it is relying on a hosted model or connected service to finish a business task. That makes the dependency part of the operating environment, because outages, model changes, policy shifts, or access failures can interrupt the process even when the rest of the application is healthy.
For security teams, the important distinction is that the dependency behaves like a governed service with known owners, approved use cases, and a defined trust boundary. If it handles sensitive data, it should be treated as an external processing relationship, not a disposable utility hidden inside a prompt or workflow.
Why AI dependencies become security-relevant
AI dependencies can expand the attack surface because they often sit between users, data, and decisions. They may receive prompts, retrieve internal context, call tools, or return outputs that are trusted downstream, so weaknesses in the dependency can create confidentiality, integrity, and availability exposure.
The risk is amplified when the dependency is embedded in a higher-value workflow such as customer support, code generation, case triage, or document processing. In those cases, the AI service is no longer an optional enhancement, it is a service dependency whose failure or compromise can affect business decisions and data handling.
Supply-chain issues matter here as well. A dependency can be altered by vendor-side model updates, package compromise, connector abuse, or a malicious third-party extension, which means the security boundary extends beyond the business’s own codebase.
How organisations should inventory and govern AI dependencies
Effective governance starts with inventory: what model or service is being used, who owns it, what data it can see, and what it is allowed to do. That inventory should include direct model calls, embedded copilots, orchestration layers, plugins, retrieval systems, and any third-party service that processes business data on the application’s behalf.
The practical control question is whether the dependency has a clear approved purpose, a documented fallback, and a monitored change path. If the service changes behavior, pricing, availability, content rules, or data retention, the business should know before users discover it through a broken workflow.
For supply-chain hygiene, the most useful starting point is to treat the dependency the way you would treat any other externally sourced software or service. OpenSSF is a useful reference point for supply-chain security practices when the AI dependency is delivered through software packages, connectors, or build-time components.
Fallback behaviour, monitoring, and recovery expectations
A dependency is only safe if the process can fail in a controlled way. That means defining what happens when the model is unavailable, when outputs are low-confidence, or when the service returns content that should not be acted on automatically.
Monitoring should focus on service availability, abnormal output patterns, sensitive-data exposure, and unexpected changes in use patterns. Where the AI dependency supports a critical workflow, recovery planning should include a manual fallback, a way to disable the dependency quickly, and a review path for any work completed while the service was degraded.
For broader resilience and governance alignment, frameworks such as NIST Cybersecurity Framework 2.0 help organisations map the dependency into govern, identify, protect, detect, respond, and recover responsibilities.
Security implications for data, access, and trust
Because an AI dependency often touches prompts, retrieved context, or downstream actions, it should be granted the minimum access needed to do its job. Broad access to files, connectors, APIs, or internal systems increases the blast radius if the dependency is misused or compromised.
Special attention should go to prompts and retrieval sources that contain credentials, secrets, regulated data, or privileged instructions. If the service is trusted to summarise, transform, or generate decisions from that material, the organisation must assume that misuse, leakage, or inadvertent disclosure is a real operational possibility.
When the dependency is agentic or tool-enabled, identity and privilege questions become more important because the system may act rather than merely answer. In those cases, organisations should assess whether the workflow is exposing overly broad action scope, unstable trust boundaries, or unreviewed access paths.
Risk and Threat Considerations
AI dependencies create a material exposure when a business process becomes reliant on a service it does not fully control. The main risk is not just downtime, but also untrusted outputs, data leakage, and hidden changes in behavior that can affect decisions or downstream systems.
Failure mechanism: An attacker, faulty update, or compromised integration can alter the service’s output, availability, or access path, causing the business process to fail closed, fail open, or make unsafe decisions based on incorrect content.
Impact: Sensitive data may be exposed, business workflows may stall, and downstream systems may ingest untrusted AI output as if it were reliable input.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-15 — Service Provider Management | AI dependencies are third-party services that need ownership and oversight. |
| Recommendation — Assess provider controls, obligations, and change notice before trusting the AI dependency. | ||
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management Strategy | AI dependencies create supply-chain exposure through hosted models and connectors. |
| GV.RM-01 — Risk Management Strategy | AI dependencies require explicit risk appetite and fallback expectations. | |
| PR.DS-01 — Data-at-rest is protected | AI dependencies often process sensitive data that needs protection in transit and storage. | |
| Recommendation — Include AI services in supply-chain risk decisions and vendor oversight. Define acceptable failure modes, data scope, and recovery assumptions for each AI dependency. Restrict sensitive data exposure to the AI dependency and enforce protection requirements. | ||
Practitioner Guidance
Why practitioners should care: The key governance decision is whether the AI dependency is treated as a monitored service with explicit ownership, access scope, and fallback behaviour, rather than as an invisible feature. That distinction determines whether the organisation can safely tolerate service drift or outage.
What to watch for: Review the dependency whenever a model, connector, or vendor policy changes, or when the workflow starts handling more sensitive data than it did at launch. That is usually when hidden assumptions about trust and access break first.
Practitioner takeaway: If a business process cannot complete safely without the AI service, then the dependency deserves the same operational discipline as any other critical third-party service.
Related resources from NHI Mgmt Group
- Why do AI-generated dependencies create more risk than normal dependency churn?
- How should security teams use AI without turning it into a control dependency?
- How do organisations reduce the impact of AI-driven dependency sprawl?
- Who is accountable when an AI agent or automation system installs a malicious dependency?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org