How to Control the Dependencies AI Coding Assistants Add to Your Code

You control the dependencies AI coding assistants add by writing one vulnerability and license policy, then checking it in three places: inside the assistant's own tools before it proposes a package, in the editor as the manifest changes, and at the pull request, where the check can actually block a merge. Only the pull request check is enforcement; the first two are fast feedback. Every dependency change, whoever or whatever wrote it, should reach review with a record a human can verify in minutes.

This post is for an AppSec or platform lead whose teams adopted AI coding assistants in the last year. Most of it uses open standards and tools you already have; Safeguard comes near the end.

Key takeaways

• AI coding assistants change dependency risk in three ways: more manifest and lockfile changes per week, version choices that can lag behind current releases, and package names that may not exist at all. A peer reviewed study of 576,000 generated code samples found hallucinated package names in at least 5.2% of packages from commercial models and 21.7% from open source models.
• OWASP's LLM03:2025 Supply Chain entry lists vulnerable third party packages and licensing risk as named risks and points to SBOMs, license inventories and patching policy as mitigations.
• NIST SP 800-218A says its practices do not distinguish between human written and AI generated code. The SSDF 1.1 tasks for third party components (PW.4.1 and PW.4.4) apply to assistant authored changes exactly as written.
• Put the check in the assistant, the editor and the pull request, but treat the pull request gate as the only enforcement point. Instruction files such as CLAUDE.md and AGENTS.md are context to the model, not enforced configuration, according to the vendors' own docs.
• Safeguard capabilities in this flow: the MCP server (GA), IDE extensions for VS Code, Cursor and JetBrains (GA), the CLI (GA), software composition analysis (GA), policies, gates and guardrails (GA), license compliance (GA), Gold Open Source free lookups (GA), and autonomous remediation (GA, ships switched off with every category set to Manual). Policy outcomes are turned on per workspace and are off by default.
• Safeguard does not decide which assistant your developers use, and nothing in this post is a claim about detecting malicious, hallucinated or typosquatted packages.

How do AI coding assistants change the rate and kind of dependency changes?

Before assistants, adding a dependency took a deliberate step: search, read the README, install, commit. The friction was small, but it meant most new packages had a human decision behind them.

An assistant with tool access removes that step. Asked to "add CSV export" or "parse this date format", it can edit package.json or requirements.txt, run the installer, regenerate the lockfile and write the code that calls the new library, all in one turn. The developer sees a working feature. The reviewer sees a diff where the interesting part, a new package and its transitive tree, is buried in a lockfile that nobody reads line by line.

There is no reliable public figure for how much faster dependency churn runs with assistants. Measure your own: count manifest and lockfile changes per week, split by whether the commit carries an assistant co-author trailer. Tracked over a quarter, that is your honest baseline.

The kind of change matters as much as the rate. Four patterns show up repeatedly.

Convenience packages

Assistants solve the task in front of them. A small utility package may be added even when the standard library or an existing dependency already covers the need, and each one brings its own maintainers, licence and transitive tree. The OpenSSF guidance discussed below asks assistants to avoid obscure dependencies when a standard library or well known package can do the job.

Versions from training data

A model's knowledge of package versions stops at its training cutoff. When it pins a version, it may pick one that has since had a security release. When it leaves the version open, the installer resolves one that nobody actually chose.

Lockfile regeneration

An agent that hits an install error may try deleting the lockfile and installing fresh. That can move many transitive packages at once behind a one line manifest change, and the reviewer has no practical way to tell which moved versions matter.

Package names that do not exist

This is the pattern with the strongest primary research behind it. In "We Have a Package for You!", a paper accepted at the 2025 USENIX Security Symposium, Spracklen and colleagues generated 576,000 code samples in two programming languages with 16 code generating models. They report that the average share of hallucinated packages was at least 5.2% for commercial models and 21.7% for open source models, with 205,474 unique hallucinated package names. The risk is that someone registers one of those names in a public registry, and the next developer who accepts the suggestion installs whatever they published.

The research also reports that mitigation strategies reduced hallucinations while keeping code quality. For a governance program, the practical point is simpler: a package name proposed by an assistant is a claim, not a fact, and something in your process has to check that the name resolves to the project you meant before it lands in a lockfile.

What do OWASP's LLM Top 10 and NIST's SSDF profile for generative AI say?

Two primary documents frame this problem, and both are worth reading for what they actually say rather than what summaries claim.

OWASP Top 10 for LLM Applications 2025, LLM03 Supply Chain

LLM03:2025 is written mainly for teams building LLM applications, so much of it covers models, LoRA adapters and training data. Two of its listed risks apply directly to assistant authored code. The first is traditional third party package vulnerabilities, such as outdated or deprecated components, which the entry ties back to the OWASP Top 10 category A06:2021 Vulnerable and Outdated Components. The second is licensing risk, because different open source and proprietary licences impose different legal requirements.

The mitigations the entry lists are ones a dependency program can adopt today:

• Apply the A06:2021 mitigations, which it summarises as vulnerability scanning, management and patching of components.
• Keep an up to date, accurate and signed inventory of components in an SBOM.
• Inventory all licence types with BOMs, audit software and tools regularly, and use automated licence management tools for real time monitoring.
• Implement a patching policy for vulnerable or outdated components.

None of this is new advice. What LLM03 adds is confirmation that the supply chain controls you already run still apply when the code comes from a model.

NIST SP 800-218A

NIST published SP 800-218A, "Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile", in final form on 26 July 2024. It augments SSDF version 1.1 (SP 800-218) with AI specific recommendations, and its scope is AI model development and the integration of models into other software.

The sentence that matters most for this topic is in the scope section. NIST says the profile's practices and tasks do not distinguish between human written and AI generated source code, because all source code should be evaluated for vulnerabilities and other issues before use. In other words, NIST did not write a separate rulebook for assistant authored code. The existing SSDF tasks apply.

For dependencies, those tasks are in practice PW.4, "Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality":

• PW.4.1 asks you to acquire and maintain well secured components from commercial, open source and other third party developers. Its examples include reviewing components in the context of their expected use, obtaining provenance information such as an SBOM or software composition analysis for each component, hosting sanctioned and vetted components in your own repositories, and maintaining a list of approved components and versions with their provenance data.
• PW.4.4 asks you to verify that acquired components comply with your organisation's requirements throughout their life cycles. Its examples include regularly checking for publicly known vulnerabilities, building automatic detection of known vulnerabilities into the toolchain, making sure each component is still actively maintained, planning for components that are no longer maintained, and confirming integrity through digital signatures or other mechanisms.

The 800-218A profile marks PW.4.4 as high priority and adds a recommendation to verify the integrity, provenance and security of acquired AI components before use. Two other SSDF tasks matter for an assistant rollout. PO.3.2 asks you to follow recommended security practices to deploy, operate and maintain tools and toolchains, and an assistant allowed to run installers is part of your toolchain. PS.3.2 asks you to collect, safeguard, maintain and share provenance data for all components of each release, with the SBOM as the example.

The OpenSSF guide for AI code assistant instructions

The OpenSSF Best Practices and AI/ML Working Groups published the "Security-Focused Guide for AI Code Assistant Instructions" on 1 August 2025. It is guidance, not a standard, and it says its recommendations rest on expert opinion and the literature. Its starting point is that the developer remains in control and responsible for the code, and that assistant output is not a shortcut around review, testing or version control discipline.

On dependencies, its sample instructions tell the assistant to use popular, community trusted libraries, to avoid adding dependencies that may be malicious or hallucinated, to install through the official package manager, to specify version ranges or exact versions, and to generate an SBOM in a standard format such as SPDX or CycloneDX. It also says instructions should be concise, specific and actionable, which matters when you decide how much policy to put in an instruction file.

Where should the check run: in the assistant, in the editor, at the pull request, or all three?

All three, with different jobs. The mistake is to treat them as interchangeable or to assume that a check early in the flow removes the need for one later.

The assistant check is the cheapest place to prevent a problem, because nothing has been written yet. The editor check catches what the assistant missed and what humans add by hand. The pull request check is where policy becomes a rule, because a required status check does not depend on anyone's settings.

The design rule that makes this work is one policy source. If the assistant's instructions say "no AGPL" while the gate blocks the whole GPL family, developers learn that the early checks are noise. All three checkpoints should return the same verdict for the same package and version.

What should an assistant be told about approved and denied packages, and how do you keep that list current?

Most assistants read a project instruction file at the start of a session. The two documented formats used in this post are CLAUDE.md for Claude Code and AGENTS.md for OpenAI's Codex.

According to Anthropic's Claude Code documentation, CLAUDE.md files can live at project, user or organisation level, and an organisation can deploy a centrally managed CLAUDE.md at a managed policy location on each machine that developers cannot exclude. The same documentation is clear about the limit: Claude treats these files as context, not enforced configuration, and it says to use the managed file for guidance and to enforce rules with managed settings such as permissions.deny.

OpenAI's Codex documentation describes AGENTS.md discovery as a chain. Codex reads a global file from the Codex home directory, then walks from the project root to the current directory, taking at most one file per directory and concatenating them so that files closer to the working directory appear later. It stops adding files at a size limit set by project_doc_max_bytes, 32 KiB by default.

Two consequences follow. First, instruction files are a good place for the rule and the method, and a poor place for a long list. A list of hundreds of approved packages eats the instruction budget and is out of date the week after you write it. Second, if a rule must hold, enforce it somewhere the model cannot talk its way around: a tool permission, a CI check or a gate.

What to put in the instruction file

Keep it short. Tell the assistant how to decide, and where to look, rather than what the answer is for every package. A workable section looks like this:

## Dependencies

- Do not add a new direct dependency without saying so in your reply,
  with the package name, version, licence and why the standard library
  or an existing dependency is not enough.
- Before proposing a package or version, look it up with the dependency
  lookup tool. Do not propose a version with a known critical or high
  vulnerability when a fixed version exists.
- Allowed licences: MIT, BSD-2-Clause, BSD-3-Clause, Apache-2.0, ISC.
  Anything else needs a human decision; stop and ask.
- Install only through the project's package manager. Never edit the
  lockfile by hand and never delete it to fix an install error.
- Pin the exact version you chose in the manifest.

The licence line is the only list, and it is short enough to stay accurate. Everything else is a procedure.

Back it with tool permissions

Instruction files ask. Permissions decide. Claude Code's settings support allow, ask and deny rules for tool use, and managed settings deployed by the organisation take the highest precedence. The docs show rules in the form Bash(npm run test *). Following that pattern, a team can let the assistant run tests freely while requiring a human confirmation before any install:

{
  "permissions": {
    "allow": ["Bash(npm run lint)", "Bash(npm run test *)"],
    "ask": ["Bash(npm install *)", "Bash(pip install *)"]
  }
}

Check the exact rule syntax for your assistant and version against its documentation before rolling this out; the pattern above follows the examples in Claude Code's settings docs.

Keep the list current by not keeping a list

The way to keep approved and denied packages current is to make the policy engine the list. Your vulnerability and licence policy already decides what passes. If the assistant can query that same policy through a lookup tool, the answer it gets is current by construction. The instruction file then only needs to say "ask the tool", and the gate enforces the same answer at merge time.

Review the instruction file itself on a schedule, quarterly is reasonable, and whenever you change the licence policy. Put it under code owners so that a change to the dependency section needs AppSec approval. An assistant that can edit its own instructions in the same pull request as a new dependency is an obvious gap.

How does a reviewer verify a dependency change made by an assistant?

A reviewer should be able to verify a dependency change in a few minutes without reading a lockfile. That means the pull request has to carry the evidence, and the reviewer needs a short, fixed checklist.

The five questions for every new direct dependency

1. Is it the package we meant? Open the registry page. Check that the name, publisher and source repository match the project the assistant described. A name that resolves to a near empty package with a recent first publish deserves a second look before anything else.
2. Is the version current and free of known critical or high vulnerabilities? Compare the pinned version with the latest release and look it up against a vulnerability database.
3. What licence does it carry, and does the declared licence match the LICENSE file? A mismatch is worth stopping for.
4. Is it maintained? Look at release history and open security issues. NIST PW.4.4 explicitly asks you to confirm components are still actively maintained.
5. What came with it? Count the transitive packages the lockfile added. One manifest line that pulls in forty packages is a different decision from one that pulls in none.

Commands that answer them quickly

For npm, the package manager itself answers most of these:

# What changed in the manifests on this branch
git diff --stat origin/main -- package.json package-lock.json

# Registry metadata for the new package
npm view <package> name version license repository.url

# Why a package is in the tree, and which version resolved
npm ls <package>

# Known advisories for the resolved tree
npm audit --omit=dev

For Python, pip index versions <package> shows published versions, and pip show <package> shows the installed version, licence field and requirements. For any ecosystem, a free web lookup of the package and version against a public vulnerability database answers question 2 without an account.

Make the pull request carry the record

Ask for a short block in the pull request description whenever a manifest changes. Assistants can fill it in reliably if the instruction file asks for it:

### Dependency change
- Added: <name>@<version> (licence: <SPDX id>)
- Why: <one sentence; what existing option was considered>
- Transitive packages added: <count>
- Known vulnerabilities at this version: <none / list>
- Lookup used: <tool or link>

The reviewer then checks the claims against the required status check rather than redoing the research. If the block is missing or wrong, send the pull request back, whoever wrote it.

How do you stop license problems slipping in with a convenient package?

Licence risk is easy to miss in assistant authored code because the convenient package usually works perfectly. The problem shows up later, in due diligence, a customer's procurement review or a distribution decision.

Three practices cover most of it.

Decide by obligation category, not by name. Group licences into permissive (MIT, BSD, Apache-2.0, ISC), weak copyleft (MPL-2.0, LGPL, EPL-2.0), strong copyleft (GPL family) and network copyleft (AGPL-3.0 and similar). For a SaaS company, network copyleft is the category that most often conflicts with how the product is delivered. For a company that ships an SDK or on premises software, strong copyleft in a linked library is the bigger question. Write the allow, deny and review lists by category, then by SPDX identifier.

Read SPDX expressions, not just licence names. Many packages are dual licensed (MIT OR Apache-2.0) or carry an exception (GPL-2.0-only WITH Classpath-exception-2.0). A policy that matches strings will get these wrong in both directions. Use a tool that evaluates SPDX expressions.

Treat a declared licence that disagrees with the LICENSE file as a finding. If the manifest says MIT and the repository's LICENSE file is AGPL, something has gone wrong in packaging or relicensing. That is exactly the case an assistant will not notice, because it reads the manifest.

Scope matters too: a licence that is fine for a backend service may not be fine for a library you distribute. Make the instruction file's short allowed list match the strictest context the repository ships into.

OWASP LLM03 asks for exactly this: a licence inventory kept in BOMs, regular audits and automated monitoring, rather than a one time legal review.

What evidence does an auditor want for AI-authored dependency changes?

There is no separate audit standard for assistant authored dependencies, and NIST's 800-218A position that it does not distinguish human written from AI generated code is the strongest signal of where auditors will land. They will ask whether your normal third party component controls operated for these changes too.

In practice, an auditor sampling a release will want to see:

An assistant co-author trailer on commits helps an auditor filter the sample, but what matters more is that the same control operated regardless of author.

The weak spot in most programs is the link between the check and the merge. A green check that nobody required, or a gate result that is not kept, cannot be shown later. Make the check required on protected branches, and keep its evaluation history for at least your audit period.

How Safeguard does this job

Everything above works with open tools and your own process. Here is how Safeguard runs the same model, using only flows its documentation describes. Software composition analysis (GA) builds the inventory and findings. Policies, gates and guardrails (GA) and license compliance (GA) decide what passes. The MCP server (GA), the IDE extensions (GA) and the CLI (GA) put the same answers where developers and their assistants work. Gold Open Source (GA) gives free lookups without an account. Autonomous remediation (GA) turns findings into fix pull requests and ships switched off, with every category set to Manual.

Step 1: Write the vulnerability and licence policy once

Safeguard's docs describe policies as rules that evaluate your SBOMs and generate findings, and gates as the checkpoints that enforce them. To create a policy:

1. Go to Settings › Policies.
2. Click Create Policy.
3. Define conditions with the visual builder or YAML.
4. Set severity and the action.
5. Save and enable.

Conditions in the docs include vulnerability severity, CVSS score, EPSS score, licence, component age, maintenance status and SLSA level. Templates include No Critical Vulnerabilities, License Compliance and No Abandoned Packages, which map closely to the five reviewer questions above.

Each policy has one Action. Block makes the gate fail. Warn lets the gate pass with a warning that names the policy. Notify lets the gate pass and sends a notification to the workspace's configured channels. Per the docs, Notify fires when a policy starts failing and again when it finds new matches, not on every evaluation.

For licences, the license compliance docs show a YAML policy with allow, deny and require review lists and per context overrides:

apiVersion: safeguard.sh/v1
kind: LicensePolicy
metadata:
  name: default
spec:
  allow:
    - MIT
    - BSD-2-Clause
    - BSD-3-Clause
    - Apache-2.0
    - ISC
    - MPL-2.0
  deny:
    - GPL-3.0-or-later
    - AGPL-3.0-or-later
    - SSPL-1.0
  require_review:
    - GPL-2.0-only
    - LGPL-3.0-or-later
    - "Custom/*"
  context_overrides:
    - apply_to: { env: sdk }
      deny:
        - LGPL-3.0-or-later
    - apply_to: { env: server }
      allow:
        - LGPL-3.0-or-later

The docs say Safeguard detects licences from package metadata, SPDX identifiers, full text matching of LICENSE, COPYING and NOTICE files, source headers and container layers, and raises a license discrepancy finding when those signals disagree. It evaluates full SPDX expressions; for an OR expression it picks the most permissive option that matches your policy. There is no CLI command for licence policy evaluation yet; safeguard scan writes a license.json with the licences it found alongside its other results.

Step 2: Enforce it at the pull request

Link the policies to a gate, then fail CI on that gate. The docs show this GitHub Actions workflow. Create a secret key under Settings › Developer with the scopes scans:trigger and scans:read, add it to GitHub as SAFEGUARD_API_KEY, and save:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The docs say no checkout step is needed because Safeguard clones the repository, and that on a pull request the head branch is scanned. To fail on your policy rather than a raw severity, add --fail-on-gate all, or name a specific gate. Per the policy outcomes docs, the command exits 0 when the gate is Passed or Warning and non zero when it is Failed, Error or Not evaluated, printing the Block policies that failed.

One caveat matters for planning. Policy outcomes are turned on per workspace by Safeguard and are off by default. If your Gates and Policies tables show no Outcome column, ask your Safeguard contact to turn it on before you rely on --fail-on-gate. The docs also warn that GitHub gives pull requests from forks no secrets, so fork pull requests need a different approach.

Make the job a required status check on protected branches. That is what turns the gate into enforcement for every author, assistant or human.

Step 3: Give every block an exit with an expiry

Convenience packages will sometimes be the right call. The docs describe an exception flow:

1. The developer clicks Request Exception.
2. They select the policy and finding.
3. They give a business justification.
4. They set an expiration date.
5. They submit for approval; approvers are notified, decide, and an audit trail is recorded.

The license compliance docs say licence exceptions use the same workflow, with a named approver, an expiry date, a documented justification, and automatic re-evaluation at expiry. The gate actions themselves are Block, Warn and Notify; approval happens through exceptions, not through a separate gate action.

Step 4: Put the same policy in the editor

The IDE docs list an extension for VS Code and Cursor and a separate plugin for JetBrains IDEs. Both scan dependency manifests as you work, show vulnerabilities inline and offer AI assisted fixes. Cursor installs through the Open VSX Registry rather than the VS Code Marketplace. Install with:

code --install-extension Safeguard-sh-Inc.SafeguardshIdeExtension
cursor --install-extension Safeguard-sh-Inc.SafeguardshIdeExtension

For JetBrains, open Settings › Plugins, search for Safeguard and install. Sign in with Safeguard: Login, which runs an OAuth device flow; the docs say device codes expire after about ten minutes.

The docs list manifest support for npm, Yarn and pnpm; pip, Poetry and Pipenv; Maven and Gradle; Go modules; Cargo; and Bundler. In VS Code and Cursor, the extension activates automatically when one of those manifests is in the workspace, and scan on save is on by default. The scan follows the manifest file, not who typed the change, which is what you want when an assistant is editing in the same workspace.

Fix suggestions use one of three strategies: Safe (minor version updates only), Balanced (the default; minor and patch updates) and Aggressive (latest version). Safe keeps fix diffs small enough to review.

Step 5: Connect the assistant to the same data with the MCP server

Safeguard ships a hosted remote MCP server. The docs describe the Claude route as the shortest: Safeguard is listed in Claude's connector directory as a community connector. Open the directory entry, select Safeguard, connect, sign in, check the app name and the host the authorisation code goes to, and click Authorize access.

If the directory is not available on your Claude plan, the docs give manual steps:

1. In Claude, open Customize › Connectors, click + Add, then Add custom connector.
2. Enter the name Safeguard Security and the URL https://mcp.safeguard.sh/mcp/anthropic, then click Continue.
3. Choose Sign in now or Sign in when needed, and Register automatically for the OAuth client.
4. Click Add, sign in to Safeguard when redirected, and click Authorize access.

On Team or Enterprise plans, the docs say an Owner or Primary Owner adds the connector first under Organization settings › Connectors, and members then connect it. For Cursor, the docs show an entry in ~/.cursor/mcp.json or a project's .cursor/mcp.json:

{
  "mcpServers": {
    "safeguard": {
      "url": "https://mcp.safeguard.sh/mcp"
    }
  }
}

The docs also say Safeguard publishes no npm package or local bridge for its MCP server, so treat any package that claims to be one as untrusted. That is a good rule to put in your own instruction file, since an assistant asked to "set up the Safeguard MCP server" might otherwise go looking for one.

According to the docs, the server offers hundreds of tools, and a new workspace starts with a small read only set; an administrator turns on the rest per tool. For this flow, keep developer and assistant access read only. The example prompts in the docs fit the dependency job directly: "Find critical vulnerabilities" and "Which packages violate my license policy?". When policy outcomes are on and your MCP access settings allow them, the server also has read only tools for gate outcomes, policy outcomes and evaluation history, so a developer can ask the assistant why the gate failed on their pull request and get the same answer CI got.

The MCP specification puts consent on the host: hosts must obtain explicit user consent before invoking any tool, and tool descriptions should be treated as untrusted unless they come from a trusted server. Its authorization section makes authorization optional for implementations, and where used, a protected server acts as an OAuth 2.1 resource server; Safeguard's server signs in with OAuth. Claude Code's docs add that servers which fetch external content can expose you to prompt injection risk. All of this argues for read only assistant tools, with enforcement left at the gate.

Step 6: Give everyone a free lookup, including people without accounts

Gold Open Source (GA) at gold.safeguard.sh is free and needs no login. The docs say each CVE page has an "Am I affected?" check that compares the version you run against the advisory's affected and fixed versions, and each package page with known vulnerabilities shows a recommended safe version with a copy ready upgrade command. That answers reviewer question 2 for anyone, including contractors and open source contributors who do not have a Safeguard seat.

The Gold docs also describe a command line scan published on Safeguard's own registry, which runs in pre commit hooks or any CI and needs no account or token:

# .npmrc
@safeguard-sh:registry=https://registry.safeguard.sh/npm/

npx @safeguard-sh/gold-scan                  # scan the current directory (fail-on=kev)
npx @safeguard-sh/gold-scan . --fail-on vuln

Per the docs, it flags dependencies that are known exploited (CISA KEV) or known vulnerable, sends only dependency names to the public read API, and fails open if the API is unreachable. The docs warn to install it only from the @safeguard-sh scope on Safeguard's registry, because a similarly named scope on the public npm registry belongs to someone else. The docs also say the safeguard-sh/gold-scan-action GitHub Action is not on the GitHub Marketplace yet, so use the command line form for now.

Step 7: Turn findings into fix pull requests, deliberately

When a dependency the assistant added later turns out to be vulnerable, autonomous remediation (GA) can open a pull request that moves it to a fixed version. It ships switched off, with every category set to Manual, and nothing is applied until you enable it. For assistant heavy repositories, start with single fixes reviewed by a human, then widen. The fix pull request goes through the same gate as everything else.

Requirement versus what Safeguard does versus what you still own

What Safeguard does not do

• It does not control which assistant your developers use, or how it is configured. Instruction files, tool permissions and managed settings live in each assistant and are yours to deploy. Safeguard supplies data to the assistant through MCP; it does not govern the assistant.
• The Claude directory connector cannot change your policies or open pull requests. It is read only for the tools it exposes. Policy changes and fix pull requests happen in the Safeguard app and through the gate, not from the chat.
• Nothing in this post is a claim about detecting malicious, hallucinated or typosquatted packages. This flow covers vulnerability and licence policy. Confirming that a package name resolves to the project you meant stays in your reviewer checklist.
• The editor check is advisory. A developer can dismiss an inline warning, and the extension only helps on machines where it is installed and signed in. Only the required pull request check enforces.
• Gate failures in CI depend on policy outcomes, which are off by default. Until Safeguard turns them on for your workspace, use --fail-on with a severity threshold instead of --fail-on-gate.
• There is no CLI command for licence policy evaluation or licence reports yet. Licence policy runs in the platform and at the gate; the CLI writes the licences it found to license.json.
• AI-BOM and MCP Guardrail are early access and are not part of this flow. If you need an inventory of models or controls on agent tool calls, treat those as separate evaluations.
• Safeguard does not make the merge decision. A passing gate means the policy you wrote passed. Whether the package was the right design choice is still a human call.

Common mistakes

Putting the whole policy in the instruction file. A long allowlist in CLAUDE.md or AGENTS.md goes stale, uses the instruction budget, and is still only context to the model. Keep the file short and point it at a lookup.

Treating the assistant check as the control. If the assistant skips the lookup tool, nothing stops the change except the gate. Write the program so that the gate would catch everything even if the assistant and editor checks did not exist.

Letting lockfile regeneration through without comment. A one line manifest change with a regenerated lockfile can move dozens of transitive versions. Ask assistants never to delete the lockfile, and ask reviewers to treat a regenerated lockfile as its own change.

Different policies at each checkpoint. If the editor warns on one set of licences and the gate blocks on another, developers learn to ignore the editor. One policy, three readers.

Blocking everything on day one. Start new policies as Warn, watch what they would have blocked for a few weeks, then move the ones that matter to Block. A gate that fails every assistant pull request in its first week will be bypassed by the second.

Exceptions without expiry. An exception that never expires is a policy change nobody reviewed. Every exception gets a date.

Giving the assistant write tools "to save time". Read only access answers every question in this post. Write access to a security platform from a chat session adds a path you then have to govern.

FAQ

Can AI coding assistants add vulnerable dependencies?

Yes. An assistant can pin an old version it learned during training, pull in a convenience package with a known vulnerability, or regenerate a lockfile that moves transitive versions. OWASP LLM03:2025 lists vulnerable third party packages as a named supply chain risk. The control is the same as for human changes: check known vulnerabilities in the editor and block at the pull request.

What are hallucinated packages in AI-generated code?

They are package names a code generating model suggests that do not exist in the registry. A study accepted at USENIX Security 2025 found hallucinated packages averaged at least 5.2% for commercial models and 21.7% for open source models across 576,000 samples. The risk is that someone registers the name and publishes code under it.

How do I make Claude Code or Codex follow our dependency policy?

Put a short dependency section in CLAUDE.md or AGENTS.md that describes the procedure and points to a lookup tool. Then back it with enforcement: Anthropic's docs say CLAUDE.md is context, not enforced configuration, and recommend managed settings such as permission rules for anything that must hold. The pull request gate is the final control.

Does NIST require anything specific for AI-generated code?

NIST SP 800-218A says its practices do not distinguish between human written and AI generated source code, because all code should be evaluated before use. The SSDF 1.1 tasks for third party components, PW.4.1 and PW.4.4, apply to assistant authored dependency changes as written.

How do I review a pull request where an AI assistant added a dependency?

Check five things for each new direct dependency: that the package is the project you meant, that the version has no known critical or high vulnerabilities, that the licence is allowed and matches the LICENSE file, that it is maintained, and how many transitive packages it added. Ask the pull request description to carry that record so you verify claims instead of researching from scratch.

How do I stop GPL or AGPL packages from being added by AI tools?

Write a licence policy by obligation category with allow, deny and review lists, evaluate it against SPDX expressions, and enforce it at the pull request. Put a short allowed list in the assistant's instruction file and tell it to stop and ask for anything else.

Can an MCP server enforce dependency policy inside the assistant?

No. An MCP server gives the assistant tools and data; the host decides whether to call them, and the MCP specification puts user consent with the host. Use MCP lookups to improve suggestions and keep enforcement at the gate.

What evidence do auditors want for AI-written dependency changes?

The same evidence as for any third party component change: the written policy, the reviewed pull request, the required check result, any exception with approver and expiry, the release SBOM and the toolchain configuration in force. Commit trailers that mark assistant authorship help filter samples but do not replace the control.

Where the fix comes from

When the gate blocks an assistant's pull request, the next question is how the fix gets made. The block below covers how Safeguard turns vulnerable dependency findings into reviewed pull requests or ready made safe components, and what happens when upstream has not shipped a fix.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo walks through connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. That tool choice is the control this post recommends: give the assistant read only lookups against the same policy your gate enforces, so it can check a package before proposing it.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session. After installing, safeguard opens the interactive terminal and the user asks it to fix the lodash CVE in the repository. It reads the finding and the advisory, edits package.json to lodash 4.17.21, and runs npm install and npm test with approval, because the CLI asks before any command that changes something. It prints a summary and pushes nothing, then shows /permissions, /model and /scan .. It is a small example of the pattern this post argues for: an assistant changing a dependency with a human approving the install and a visible record of what changed.

Click through it at your own pace, or open it full screen.

To try the CLI, the IDE extensions or the MCP server, start at safeguard.sh/download and read the setup guides at docs.safeguard.sh.

For related reading, see questions to ask about AI coding assistants adding dependencies, what to approve on an AI coding assistant allowlist, how a pull request can prove a new dependency was vetted, AI coding assistants and SOC 2 dependency changes, and from this series, stopping vulnerable dependencies at five checkpoints and proving every production release passed a security gate.

Quick check

Sources

• OWASP Gen AI Security Project: LLM03:2025 Supply Chain
• NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models
• NIST SP 800-218A full text (PDF)
• NIST SP 800-218, SSDF Version 1.1 full text (PDF)
• OpenSSF: Security-Focused Guide for AI Code Assistant Instructions
• Spracklen et al., We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (arXiv 2406.10279)
• Model Context Protocol specification, version 2025-06-18
• Model Context Protocol: Authorization
• Claude Code docs: How Claude remembers your project
• Claude Code docs: Settings
• Claude Code docs: Connect Claude Code to tools via MCP
• OpenAI Codex docs: Custom instructions with AGENTS.md
• Safeguard docs: Claude MCP integration
• Safeguard docs: Cursor MCP integration
• Safeguard docs: IDE Support
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: License Compliance
• Safeguard docs: Gold Open Source
• Safeguard docs: GitHub Actions

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.