They often assume the pull request is the first meaningful checkpoint, but an AI assistant or coding agent may already have chosen and installed the package earlier in the workflow. That means policy enforcement needs to start at selection time, not only at merge time. Otherwise the organisation reviews the record of a decision rather than the decision itself.
Where compliance review starts too late
The main mistake is treating the pull request as the first point at which a dependency becomes real. In AI-assisted workflows, selection, installation, and even version choice may already have happened in the coding environment, so the organisation is reviewing a record of the decision rather than the decision itself. That shifts the control point from merge review to the earlier stage where package choice is made.
This matters because dependency choice is not just a documentation issue. The package selected by an assistant can introduce supply-chain exposure, lock in transitive dependencies, and shape what lands in the software bill of materials. If policy only inspects the PR, it can miss the package that was already pulled into the build path.
What selection-time control actually means
Selection-time control means policy has to influence the toolchain before a package is installed or trusted, not only after code is proposed. In practical terms, the policy needs to gate allowed registries, approved package names, version ranges, and install paths at the point where the assistant or developer asks for a dependency recommendation. That is where the risky choice is made, even if the PR later shows a clean-looking diff.
For this reason, dependency governance has to be wired into the workflow that produces the choice, not just the workflow that records it. Controls that only inspect source after the fact are useful, but they are downstream of the real decision. That is why supply-chain guidance from OpenSSF is relevant here: the security objective is to shape selection, provenance, and consumption before untrusted software enters the build.
Where AI assistance is involved, the same point applies even more strongly. If an assistant can suggest, install, or update a dependency autonomously, then the review process needs to validate the assistant’s allowance boundary, not just the final dependency list. That is the practical difference between governing output and governing the action that created it.
Why downstream review gives a false sense of control
Post-merge approval is often comfortable because it produces an auditable record, but records are not controls. If the assistant has already chosen the library, accepted the version, or fetched the package from a registry, then the organisation may only be validating what has already occurred. That can leave an approval trail that looks compliant while the actual trust decision happened outside the monitored checkpoint.
Compliance teams also miss how fast dependency risk compounds. One package can bring in transitive packages, build-time scripts, and runtime behaviour that were never explicitly named in the original request. Once the dependency is installed, the organisation has already expanded its attack surface, so later approval is mainly evidence that the change was noticed, not prevented.
Risk and Threat Considerations
When selection happens before review, the main risk is silent introduction of unapproved software into the development path. That can create supply-chain exposure, unexpected privilege in build systems, and a larger blast radius if the chosen dependency is malicious, compromised, or simply inappropriate for the environment.
Failure mechanism: The assistant or coding agent makes the trust decision at selection time, then the pull request and merge workflow become a retrospective audit trail instead of a preventive control. Threat actors benefit when that earlier step is ungoverned, because malicious or typosquatted packages can be introduced before reviewers ever see the final change.
Impact: Organisations can approve code that appears compliant while still inheriting compromised packages, hidden transitive dependencies, or unreviewed install behaviour. The result is weaker supply-chain assurance, poorer attribution for who approved the dependency, and a higher chance that incidents start in a place the compliance process did not actually control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, SLSA, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | AI-selected dependencies must be inventoried before they enter the build path. |
| Recommendation — Enforce dependency inventory controls before installation and block unapproved package introductions. | ||
| SLSA | Supply chain integrity | The question is about shifting trust decisions earlier in the software supply chain. |
| Recommendation — Require provenance and approved-source checks before dependency installation or promotion. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Controls over third-party code and libraries are central to AI-assisted dependency selection. |
| Recommendation — Review and govern third-party library intake before code reaches merge review. | ||
| ISO/IEC 27001:2022 | A.5.21 — Managing information security in the ICT supply chain | Dependency selection is a software supply-chain control problem with vendor and package trust implications. |
| Recommendation — Apply supply-chain acceptance criteria before allowing dependencies into the development workflow. | ||
| NIST CSF 2.0 | GV.SC-04 — Supply Chain Risk Management | The answer concerns when supply-chain controls must act to be effective. |
| Recommendation — Move supplier and component risk checks to the earliest dependency selection point. | ||
Practitioner Guidance
What to verify: Confirm whether dependency policy is enforced at package discovery, recommendation, or install time, not only at pull request or merge time. If the assistant can install from a general-purpose registry without an allowlist or approval checkpoint, the control is too late.
Decision rule: If the tool can choose the dependency, treat that selection step as the control boundary. If the human only reviews the outcome, add a gate that blocks unapproved registries, packages, or versions before the package enters the workspace or build.
Common mistake: Treating the PR as the primary compliance artifact when the real trust decision was made by an automated assistant earlier in the workflow. That approach measures review activity, not dependency governance.
Practitioner takeaway: The control objective is to govern the moment of selection, because once the dependency is already installed, compliance has moved from prevention to after-the-fact evidence collection.