How to Lock Down Your Supply Chain When AI Writes Your Code

The Problem Nobody’s Talking About

Here’s a scenario that’s becoming uncomfortably common. You’re building a feature, your AI coding assistant suggests a package import. It looks reasonable. You accept it. The code compiles, the tests pass, you merge to main.

What just happened? You pulled a dependency into your supply chain that nobody — not you, not your team, not your security scanner — evaluated. The AI suggested it because it looked semantically correct, not because it was safe.

For years, supply chain security meant asking one question: what’s in my dependencies? SolarWinds, Log4Shell, and XZ Utils all hammered home the same lesson — the risk lives less in the code you write and more in everything that produces it.

Now AI is part of “everything that produces it.” And most security programs weren’t designed with that in mind.

Why Scanning AI-Generated Code Isn’t Enough

The instinct is to run AI-written code through the same SAST scanner you use for human-written code and call it done. That’s table stakes — and it’s not enough.

Here’s why. Traditional supply chain security assumes a human chose every dependency, reviewed every configuration change, and understood the threat model behind every design decision. AI agents break all three assumptions. An agent might pull in a package because a prompt told it to. It might configure an MCP server with permissions nobody reviewed. It might generate a thousand lines of plausible code before lunch that nobody has time to read line by line.

This is exactly what I covered when I wrote about the DuneSlide incident — a case where a malicious actor poisoned AI coding agent workflows to inject vulnerabilities at scale. The provenance question — “where did this come from and can I trust it?” — needs to extend beyond your artifact to your model, your agent, and your tooling. Let me show you how.

Step 1: Scan AI-Generated Code Before It Touches Main

The first line of defense is catching problems before they enter your repo. Here’s a practical workflow you can set up in about ten minutes.

Secret Detection with Gitleaks

AI models occasionally hallucinate API keys, tokens, and credentials — strings that look like real secrets. Gitleaks catches phantom credentials — and actual ones — before they become a breach.

# Install gitleaks
brew install gitleaks      # macOS
# or: go install github.com/gitleaks/gitleaks/v8@latest

# Scan staged changes in a pre-commit hook
gitleaks detect --source . --verbose

# Add to .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

Set this as a pre-commit hook and it runs automatically. AI-generated code that accidentally includes hardcoded credentials never makes it past your local machine.

Static Analysis with Semgrep

Semgrep goes beyond secrets — it catches insecure patterns like SQL injection, hardcoded passwords in config files, and dangerous function calls that AI assistants are prone to generating.

# Install semgrep
pip install semgrep

# Run a quick scan with community rules
semgrep --config=auto .

# Run CI-grade ruleset on AI-generated files only
semgrep --config=p/owasp-top-ten --include='*_ai_generated.*' .

# Add to your CI pipeline (GitHub Actions example)
- name: Semgrep scan
  run: |
    pip install semgrep
    semgrep --config=auto --sarif --output=semgrep.sarif .
  continue-on-error: true

The key insight: don’t just scan everything and drown in alerts. Target AI-generated files specifically, and fail the build only on high-confidence findings. Otherwise you’ll burn out your team chasing false positives from code nobody even wrote.

Step 2: Lock Down What Your AI Agents Can Reach

This is the part most teams skip entirely. Your AI coding agent doesn’t need access to every tool on your system — and if you’re not restricting it, you’re running with scissors.

When Alibaba banned Claude Code over backdoor concerns earlier this year, it wasn’t an overreaction. It was the kind of access control that most teams should be applying — but aren’t.

Restrict MCP Server Access

If you’re using Claude Code, Cursor, or any agent that connects via the Model Context Protocol, lock down which MCP servers it can call. An agent that can reach your package manager, your deployment pipeline, and your production database is a supply chain incident waiting to happen.

// .mcp.json — explicit allowlist for MCP servers
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"],
      "env": {
        "READ_ONLY": "true"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}",
        "ALLOWED_ACTIONS": "read_issues,create_pull_request"
      }
    }
  }
}

Notice what’s not in that config: no terminal server with shell access, no database connector, no deployment tool. Give your agent exactly what it needs and nothing more. This is the principle of least privilege, applied to AI.

Scan Dependencies AI Pulls In

When your agent suggests adding a package, you need automated verification. Here’s a quick script that checks npm packages for known vulnerabilities before they’re installed:

# Add to your CI or pre-commit flow
# Check a specific package before merging
npm audit --only=prod | grep -E "(high|critical)" && echo "BLOCKED: Vulnerable dependency" && exit 1

# For Python projects
pip-audit --requirement requirements.txt

# Generate an SBOM for visibility
cyclonedx-py requirements requirements.txt -o sbom.json

The SBOM step is worth emphasizing. An AI agent might pull in a transitive dependency three layers deep that nobody on your team knows about. Generating a Software Bill of Materials gives you a manifest of everything in your build — including the things AI added without asking. It’s also exactly what my guide to blocking AI crawlers was getting at: you need visibility into what’s in your stack before you can secure it.

Step 3: Build CI Gates That Actually Catch AI-Introduced Risk

Your CI pipeline needs to treat AI-generated code differently from human-written code — not because it’s inherently worse, but because it arrives through a different path with different risks.

A Practical CI Gate for AI-Generated PRs

# .github/workflows/ai-code-gate.yml
name: AI Code Security Gate
on:
  pull_request:
    paths:
      - '**.ts'
      - '**.js'
      - '**.py'

jobs:
  ai-code-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Secret scan
        uses: gitleaks/gitleaks-action@v2

      - name: SAST scan
        run: |
          pip install semgrep
          semgrep --config=auto --error --strict .

      - name: Dependency audit
        run: npm audit --audit-level=high

      - name: SBOM diff
        run: |
          # Compare SBOM before and after PR to flag new dependencies
          git diff origin/main -- requirements.txt | grep "^+" | grep -v "^+++"
          echo "Review any new dependencies above manually"

Three things happen here. The secret scan catches leaked credentials. The SAST scan catches dangerous patterns. The dependency audit catches packages with known vulnerabilities. And the SBOM diff forces a human to acknowledge every new dependency before it merges.

That last part is crucial. The whole point of supply chain security is making sure someone knows what’s in the chain. If AI added it and nobody looked, you don’t have supply chain security — you have supply chain hope.

Step 4: Track Provenance Beyond the Code

Here’s the uncomfortable truth: tracking dependencies isn’t enough anymore. You need to track what model generated the code, what prompt triggered it, and what tools the agent had access to when it wrote it.

For teams using AI coding assistants seriously, consider adding provenance metadata to commits:

# Add an AI-provenance trailer to commits
git commit -m "fix: sanitize user input in login handler
>
> AI-assisted: Claude Sonnet 5
> Prompt: 'Add input sanitization to the login handler'
> MCP tools used: filesystem (read-only), github (read_issues)
> Human reviewer: Felix"

This isn’t about blame. It’s about traceability. When something goes wrong six months later — and something always does — you need to know exactly what was in the pipeline when this code was generated, not just what’s in the code now.

The Practical Checklist

Here’s what you should walk away with. Print this, stick it next to your monitor, run through it before merging any PR that involves AI-generated code.

• Pre-commit: Gitleaks secret scan runs automatically — no hardcoded keys or tokens
• Pre-merge: Semgrep SAST scan passes with zero high-severity findings
• Pre-merge: npm audit (or pip-audit) shows zero high/critical vulnerabilities in new deps
• Pre-merge: MCP configuration is reviewed — agent only has access to tools it actually needs
• Pre-merge: SBOM diff reviewed — every new dependency acknowledged by a human
• Pre-merge: At least one human has read the AI-generated code and understands what it does
• Post-merge: Commit includes AI provenance metadata (model, prompt, tools, reviewer)

None of these steps are complicated. Most of them are free. The hard part isn’t the tooling — it’s the discipline. It’s resisting the temptation to trust AI output because it looks right. It’s building the muscle of treating AI-generated code not as a threat, but as a contributor whose work needs the same review everyone else’s gets.

This connects to something I wrote about recently — how smarter AI models can actually break existing workflows if you don’t adapt your processes alongside the tools.

Bottom Line

I’ve been using AI coding assistants daily for over a year now — Claude Code, Copilot, Cursor, you name it. They’re incredible tools. They’ve made me faster, caught bugs I would have missed, and helped me explore approaches I wouldn’t have considered on my own.

But they’ve also suggested packages I’ve never heard of, generated config files with permissions I wouldn’t have set, and written code that looked correct but contained patterns I’d never let past code review from a human teammate.

The question isn’t whether AI should be in your build pipeline. It already is. The question is whether you’re treating it like any other supply chain risk — with the same rigor, the same gates, and the same healthy skepticism.

Because here’s the thing about supply chain security: you’re only as strong as your weakest link. And right now, for a lot of teams, that weakest link is code nobody read, written by a model nobody evaluated, pulling in dependencies nobody chose.

Fix that this week. The checklist above takes thirty minutes to set up and a lifetime of discipline to maintain. Start now.