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.
Expanded Definition
An AI dependency is more than a model choice or a product feature. It is any external or internal AI service, hosted model, retrieval layer, agent runtime, or API-connected capability that a business process depends on to produce a result. In NHI Management Group usage, the key security question is not whether the system is “AI-enabled”, but whether the organisation can govern the dependency as a service with ownership, access boundaries, logging, and a tested fallback.
Definitions vary across vendors because some teams use the term to mean a purchased AI platform, while others include embedded copilots, orchestration layers, and model endpoints called through workflow automation. For security teams, that distinction matters because AI dependencies can expand the trusted computing base without being obvious in procurement or architecture reviews. Guidance in the NIST Cybersecurity Framework 2.0 is useful here because it frames governance, risk management, and resilience as ongoing disciplines rather than one-time approvals.
The most common misapplication is treating an AI dependency as a disposable vendor feature, which occurs when teams embed it into workflows without defining owners, data handling rules, or a recovery path if the service becomes unavailable or untrustworthy.
Examples and Use Cases
Implementing AI dependency governance rigorously often introduces review and integration overhead, requiring organisations to weigh faster automation against the cost of tighter oversight, fallback design, and continuous assurance.
- A support workflow calls a hosted LLM to draft customer responses, but the process is paused if the model provider changes data retention terms or cannot be reached.
- A fraud detection pipeline depends on an AI scoring service, with alert routing and manual review triggered when model confidence drops below an agreed threshold.
- A software engineering team uses an AI code assistant, but repository access, prompt handling, and output review are governed as part of secure development practice.
- An internal knowledge assistant uses retrieval-augmented generation, where the search index and source documents are treated as security-relevant dependencies alongside the model itself.
- An agentic workflow depends on an external tool-calling service, and the organisation limits tool scope, credentials, and allowed actions so the dependency cannot exceed its intended role.
For AI-specific risk framing, the NIST AI Risk Management Framework helps teams assess how dependency choices affect validity, reliability, and accountability. Where the dependency is connected to personal data or identity assertions, the boundary can also resemble a governed trust relationship rather than a simple technical integration.
Why It Matters for Security Teams
AI dependencies become security issues when organisations assume the service is dependable because it worked during testing. In practice, the risk surface includes prompt injection, model drift, data exposure, API abuse, silent capability changes, and business interruption if the dependency fails or is withdrawn. That is especially important when an AI dependency touches identity workflows, privileged actions, secrets handling, or agentic automation, because the AI component may indirectly influence access decisions or tool execution.
Security teams need to classify AI dependencies as part of the application and identity architecture, not as invisible productivity add-ons. That means defining ownership, reviewing vendor and model changes, constraining data flows, monitoring outputs, and preparing alternative paths for degraded or offline operation. The NIST Cybersecurity Framework 2.0 supports this approach by anchoring governance, protect, detect, respond, and recover activities around the dependency itself.
Organisations typically encounter the operational impact only after an AI service changes behaviour, limits access, or fails during a live process, at which point AI dependency management becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.1 | CSF 2.0 frames governance for external services that create business risk. |
| NIST AI RMF | GOVERN | AIRMF addresses AI accountability, oversight, and lifecycle governance. |
| NIST AI 600-1 | The GenAI profile emphasizes managing GenAI risks across deployment and use. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance highlights tool and service dependencies as attack and failure points. | |
| OWASP Non-Human Identity Top 10 | NHI guidance is relevant when AI dependencies use service identities or secrets. |
Inventory credentials and service identities used by AI dependencies and rotate them safely.
