A package or library that enters a codebase because an AI assistant or coding agent recommended, installed, or incorporated it. The risk is not the package alone, but the fact that the selection may occur outside the usual human approval and licence review process.
Expanded Definition
An AI-selected dependency is not simply any third-party package. It is a dependency introduced into a software project because an assistant, coding agent, or similar AI system suggested it, resolved it, or added it during development. The security issue is the decision path: selection can bypass the normal human checkpoints used for code review, license review, provenance validation, and dependency approval.
In practice, the term sits at the intersection of software supply chain security and emerging AI-assisted engineering workflows. A package may be technically valid and still create risk if its source, maintenance status, transitive tree, or permission scope was never evaluated by a person with accountability. That makes the term different from ordinary third-party dependency risk, which is usually managed through explicit developer choice and established intake controls. Guidance is still evolving, but the current security consensus is that AI-assisted recommendation does not reduce the need for governance, especially where build integrity and approval traceability matter. NIST frames these responsibilities broadly in the NIST Cybersecurity Framework 2.0, particularly around risk management and supply chain oversight.
The most common misapplication is treating an AI-suggested package as pre-approved because it appears syntactically correct or widely used, when the condition that matters is whether humans verified its provenance and policy fit before merge.
Examples and Use Cases
Implementing AI-assisted development rigorously often introduces friction in delivery speed, requiring organisations to weigh faster code generation against stronger review and approval controls.
- An AI coding assistant recommends a logging library that is functionally suitable, but the team later discovers it introduces a copyleft license obligation that was never checked before merge.
- A coding agent adds a package to support file parsing, yet the package is poorly maintained and pulls in risky transitive dependencies that the project’s normal review process would have flagged.
- An internal developer tool accepts AI-generated dependency updates automatically, and the resulting build includes a new package from an unverified source repository.
- A software supply chain team uses policy gates to require human approval for any dependency proposed by an AI tool, aligning intake with OWASP software supply chain guidance and package provenance checks.
- A platform engineering group monitors dependency diffs from AI-assisted pull requests so that security review can distinguish normal refactoring from tool-driven package introduction.
These use cases show that the operational issue is not whether the package is common, but whether its addition was visible to the people responsible for licensing, provenance, and trust decisions.
Why It Matters for Security Teams
AI-selected dependencies create a control gap if teams assume the same safeguards that apply to human-authored code will automatically catch AI-driven package introduction. That gap matters because dependencies expand the attack surface, can introduce hidden transitive risk, and may change legal exposure if licenses are not reviewed before use. For security teams, the important question is not only what was installed, but how it entered the codebase and whether there is an auditable approval trail.
This term is especially relevant where AI agents have tool access, because an agent can move from suggestion to action without the deliberate pause that normally forces review. In NHI and agentic ai contexts, this becomes a governance issue as much as a software engineering issue: the system performing the selection is not a human developer, so policy must account for delegated execution and not just developer intent. The most useful controls are inventory, provenance verification, human approval gates, and exception handling for AI-generated dependency changes, all of which align with the risk-management emphasis of the NIST Cybersecurity Framework 2.0.
Organisations typically encounter the consequences only after an incident review or license dispute, at which point AI-selected dependency governance 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 Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | CSF 2.0 frames supply chain and third-party risk management for software intake decisions. |
| OWASP Non-Human Identity Top 10 | AI-selected dependencies often arise from non-human tool action that needs identity and trust governance. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance addresses tool use, delegated actions, and unintended software changes. | |
| NIST AI RMF | AI RMF supports governance for AI-enabled decisions that affect software and supply chain risk. | |
| NIST SP 800-53 Rev 5 | SA-12 | System and services acquisition controls cover supplier and component trust decisions. |
Document accountability for AI-suggested dependencies and verify those decisions through human oversight.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
