Skip to content
Flows
Agent QA & Security Intermediate · 60-90 minutes

Dependency and Supply-Chain Scanning for Agents

Guard against the dependencies your agent adds: vulnerability scanning, hallucinated-package detection, and gated installs.

Start Route · 4 steps

The route

4 steps to Done

  1. 01

    Intercept dependency additions

    Every new dependency is a trust decision - catch it at the source.

    Preview prompt + verify gate ▾

    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
  2. 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 ▾

    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
  3. 03

    Scan for vulnerabilities

    Real packages can still carry known holes.

    Preview prompt + verify gate ▾

    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
  4. 04

    Gate review and enforce lockfile discipline

    Reviewed set in, reviewed set installed - recorded.

    Preview prompt + verify gate ▾

    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

Sources behind this flow