Dependency and Supply-Chain Scanning for Agents
Guard against the dependencies your agent adds: vulnerability scanning, hallucinated-package detection, and gated installs.
The route
4 steps to Done
- 01
Intercept dependency additions
Every new dependency is a trust decision - catch it at the source.
Preview prompt + verify gate ▾ Hide ▴
Hook the dependency-adding actions. Identify every way the agent can add a dependency: package-manager install commands (pip install, npm/yarn add, etc.), direct edits to manifests (requirements.txt, package.json, pyproject, go.mod), and lockfile edits. Route these through a supply-chain gate before they take effect: parse out the package name(s) and version(s) being added, and pause for the checks (next steps) rather than executing immediately. Distinguish adding a NEW dependency (full gate) from updating an existing reviewed one (lighter path). Ensure no install path bypasses the gate - including the agent writing a manifest and running install as separate steps. Verify by having the agent attempt an install and confirming the gate intercepts it.
- ✓ Installs and manifest/lockfile edits both caught
- ✓ New vs existing dependency distinguished
- ✓ Write-then-install evasion covered
- 02
Verify existence and reputation
The defining AI supply-chain risk: packages that should not be trusted or do not exist.
Preview prompt + verify gate ▾ Hide ▴
Implement existence and reputation checks. EXISTENCE: query the package registry - does this exact name exist? A non-existent package (common with AI hallucination) is blocked outright with 'package X not found on the registry - verify the name'. REPUTATION/TYPOSQUAT: for packages that do exist, check signals - age (brand-new packages matching a popular name are high risk), download/usage volume, and similarity to popular package names (edit distance to top packages flags likely typosquats/slopsquats: 'reqeusts' vs 'requests', 'python-jwt' lookalikes). A low-reputation or lookalike package is flagged for mandatory human review, not auto-installed. Test with a hallucinated name, a known typosquat pattern, and a legitimate popular package.
- ✓ Non-existent packages blocked
- ✓ Typosquat/lookalike detection via name similarity
- ✓ Legitimate popular packages pass cleanly
- 03
Scan for vulnerabilities
Real packages can still carry known holes.
Preview prompt + verify gate ▾ Hide ▴
Add vulnerability scanning. For each proposed dependency (and its transitive dependencies where feasible), check against a vulnerability database/advisory source (an audit tool like the package manager's built-in audit, or an OSS advisory API): known CVEs, severity, and whether a fixed version exists. Blocking policy: high/critical vulnerabilities with no fix block the add; those with a fix prompt the agent to use the patched version; medium/low attach as warnings to the review record. Also scan the EXISTING dependency set on a schedule so newly-disclosed vulnerabilities in already-installed packages surface. Test by proposing a dependency with a known vulnerable version and confirming the block-or-upgrade behavior.
- ✓ Proposed deps scanned including transitives where feasible
- ✓ High/critical-without-fix blocks
- ✓ Existing set scanned on a schedule
- 04
Gate review and enforce lockfile discipline
Reviewed set in, reviewed set installed - recorded.
Preview prompt + verify gate ▾ Hide ▴
Close the loop with review and lockfiles. REVIEW GATE: a NEW dependency passing automated checks still surfaces for a human decision with the evidence (why the agent wants it, existence/reputation/vuln results); approval records {package, version, rationale, approver, date} in a dependency decision log. LOCKFILE DISCIPLINE: approved additions update BOTH the manifest and the lockfile together, pinning exact reviewed versions and hashes where the ecosystem supports them, so what installs is exactly what was reviewed; CI verifies manifest and lockfile agree and blocks drift. VALIDATE end to end: have the agent propose a legitimate new dependency and walk it through checks -> review -> lockfile update; then have it propose a hallucinated and a vulnerable one and confirm both are stopped with clear reasons.
- ✓ New deps recorded with rationale and approver
- ✓ Manifest and lockfile updated together and pinned
- ✓ CI blocks manifest/lockfile drift
Research-backed