Security teams lose visibility into a dependency class that can change behaviour, expose data, or invoke tools without appearing in a normal SBOM or vulnerability scan. That means clean SAST and SCA results can coexist with ungoverned AI services, agent frameworks, and runtime prompts. The result is a false sense of control, not real assurance.
Why This Matters for Security Teams
When AI dependencies are omitted from application security reviews, the control gap is not theoretical. Traditional review gates are designed to spot libraries, packages, and known vulnerabilities, but AI services can also reshape application behaviour through prompts, tool calls, retrieval pipelines, and model outputs. That means the review may certify the code while leaving the most dynamic part of the system outside governance. The NIST Cybersecurity Framework 2.0 is useful here because it frames risk as an enterprise-wide responsibility, not just a code-scanning exercise.
The practical issue is that AI dependencies often arrive through product experimentation, embedded SDKs, hosted APIs, or internal agent platforms, then become business-critical before anyone classifies them as security-relevant. If those components are missing from review, the team can miss data exposure paths, model behaviour drift, unsafe tool invocation, or hidden external dependency chains. In regulated environments, that also weakens accountability for data handling and change control. In practice, many security teams encounter AI risk only after a production incident or privacy concern has already exposed the blind spot, rather than through intentional review coverage.
How It Works in Practice
Effective application security review needs to expand the dependency inventory beyond conventional software components. For AI-enabled systems, that means capturing hosted models, local inference runtimes, agent frameworks, orchestration layers, prompt templates, retrieval connectors, and any tool or API a model can invoke. These elements should be treated as part of the application attack surface, even when they are not compiled into the binary or visible in a standard Software Composition Analysis report.
A practical review process usually includes three checks. First, confirm whether the application uses an external model, internal model, or hybrid pattern. Second, map what data can enter the model, what can leave it, and what actions it can trigger. Third, identify the controls that govern updates, permissions, logging, and fallback behaviour. NIST guidance on AI governance and risk management, including the NIST Cybersecurity Framework 2.0, supports this kind of control mapping because it ties technical review to risk ownership and response.
- Inventory AI services alongside APIs, packages, and infrastructure dependencies.
- Classify prompt sources, retrieval sources, and tool connectors as reviewable inputs.
- Require approval for model changes, prompt changes, and connector changes.
- Log model outputs and tool actions where privacy and policy allow.
- Test for prompt injection, unsafe data exposure, and unauthorized action paths.
Security teams should also define who can introduce an AI dependency, who can modify it, and who validates its behaviour after change. Current guidance suggests this belongs in change management as much as in application security, because behaviour changes are often introduced through configuration rather than code. These controls tend to break down in fast-moving SaaS integrations and agentic workflows because the application team may not control the full runtime chain.
Common Variations and Edge Cases
Tighter AI dependency review often increases friction for product teams, requiring organisations to balance speed of delivery against the need for behavioural assurance. That tradeoff is especially visible when the AI component is purchased as a managed service or embedded through a low-code platform, where the control boundary is less obvious than a normal library dependency.
There is no universal standard for this yet, but best practice is evolving toward risk-based classification. A read-only summarisation feature does not present the same profile as an autonomous agent that can open tickets, query systems, or send messages on behalf of users. Similarly, a local model used for internal text classification may deserve a lighter review than a retrieval-augmented workflow that processes sensitive data and external knowledge sources. The right answer depends on data sensitivity, action authority, and whether the AI component can influence system state.
Edge cases also matter for shared platform teams. An AI service may sit outside a single application but still affect multiple products through a common orchestration layer, shared prompt store, or central agent framework. In those cases, security reviews should move upward to the platform layer and not rely on each application team to rediscover the same dependency. For operational teams, the key question is whether the AI component can change what the application does, not whether it appears in the build manifest.
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 MITRE ATLAS 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.OC-01 | AI dependencies must be included in enterprise risk and asset visibility. |
| NIST AI RMF | GOVERN | AI review gaps are governance failures when model behaviour changes are unmanaged. |
| OWASP Agentic AI Top 10 | Agentic systems add tool use and prompt abuse risks outside normal SCA review. | |
| MITRE ATLAS | AML.TA0001 | AI dependencies can be attacked through prompt injection and model manipulation. |
| NIST AI 600-1 | GenAI systems need profile-based controls for data, output, and tool use. |
Classify AI services as in-scope assets and assign ownership before approval.
