The faster AI coding agents get, the stranger the bottleneck. It is not code. It is dependencies.

The moment an agent handles "just add lodash for this feature" by itself, package selection happens at machine speed. A structure where humans review every choice cannot keep up. That is the part of the GitLab Dependency Firewall announcement developers should read closely.

What Dependency Firewall is

One-line definition: a structure that blocks packages failing a project's security policy before they are fetched.

Agent or developer requests a package
  → policy evaluation (evaluate)
  → one of allowed / warned / blocked
  → warn mode: warn and pass / enforce mode: block and quarantine

The four evaluation axes are package age, vulnerability severity, malicious-package detection, and license compliance. No matching policy means allowed, a warn-mode match means warned, and an enforce-mode match means blocked. One subtlety matters: a project with the firewall on but no linked policy always returns allowed. That means "no policy matched," not "verified safe."

Reading the API reveals the design

The Dependency Firewall API in GitLab Docs (19.4, experiment tier, Premium and Ultimate) shows the philosophy.

First check the firewall status for a project.

curl --request GET \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/1/dependency_firewall/enablement"

{
  "enabled": true
}

Then evaluate a package, for example lodash 4.17.15 on npm:

curl --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --header "Content-Type: application/json" \
  --url "https://gitlab.example.com/api/v4/projects/1/dependency_firewall/evaluate" \
  --data '{"ecosystem": "npm", "name": "lodash", "version": "4.17.15"}'

{
  "outcome": "blocked",
  "reason": "Package 'lodash' violates 'deny-mit' policy"
}

Several design choices stand out.

  • Broad ecosystem coverage: cargo, composer, conan, gem, golang, maven, npm, nuget, pub, pypi, and swift. It watches the whole front, not one package manager.
  • Pipeline-native auth with CI/CD job tokens. A job token only checks and evaluates its own project; anything else returns 403. Peeking at a neighbor project's firewall state is blocked by design.
  • A session correlation header (X-Gitlab-Dependency-Firewall-Session-Id) groups evaluations from one install command into audit and analytics events, so "who installed what, when" stays traceable.
  • Evaluation needs Reporter role or above and works even with the package registry off, because it evaluates upstream dependencies independently of the registry switch.

Why after-the-fact review fails

Where human-speed review breaks:

An agent opens 5 PRs in 10 minutes
  → each adds 2–3 dependencies
  → reviewers must check code + dependencies + licenses + vulnerabilities
  → "merge now, review later" becomes the default
  → later never comes

Hence the line that upfront policy enforcement matters more than after-the-fact code review as agent autonomy grows. The firewall is not "block because we distrust." It is "filter early so we can trust agents with wider autonomy." Malicious, vulnerable, and non-compliant packages get caught before the build.

This is also one piece of the larger Governed Software Factory picture from the companion post: dependencies must be bound together with context (Orbit), secrets (Secrets Manager), and assembly (Artifact Central) before agents can reach production.

Minimum gates you can set today

The firewall is still an experiment (feature flag dependency_firewall_phase1, off by default), so many teams cannot use it yet. In that case set these four automatic gates. They are the minimum for any repo where AI can add dependencies.

1. Allow and deny policy
   - Document per-ecosystem ranges (e.g. npm requires a lockfile; new packages need 30+ days of age)
   - Start in warn, graduate to enforce (starting with block stalls work)

2. Vulnerability scanning
   - Scan every MR with an explicit severity cutoff
   - Route auto-remediation into a separate review queue

3. Lockfile diffs
   - Review lockfile changes separately from code changes
   - Require one line in the PR body: "why this version"

4. Audit trail
   - Record who installed what, when, and why, per session
   - Weekly review of warned-but-passed items only (no exhaustive review)

One warn-mode tip: blocking everything from day one converges on developers disabling the firewall. Run warn mode for two weeks, measure what would have been caught, then enforce the top patterns first. It pairs well with the review flow in the practical Git post.

CodeBridge Mini Lab: measure your repo risk

1. Take the last 20 merged MRs
2. Count dependencies added by agents and humans in each
3. Flag each dependency:
   - Under 30 days old?
   - Known vulnerability?
   - License conflict with policy?
   - Arrived without a lockfile diff?
4. Anything with one Y is "would-have-been-caught" candidate

Decision:
- Zero candidates: keep the flow, prepare warn mode
- Three or more: draft the allow and deny policy now
- Half missing lockfile diffs: fix review rules first (rules before tools)

Conclusion: dependencies need machine-speed control too

One closing line.

If agents pick packages at machine speed, control must run at the same speed.

This does not remove human review. It moves human eyes to judging policy exceptions while machines handle repeated blocks. Start with warn, graduate to enforce, keep lockfile diffs and an audit trail. Then it is safe to grant agents wider autonomy.

Further reading

References

Go deeper with a course

Policies only help when review and version-control habits already hold. If you want to build the habit of reading lockfile diffs and reviewing them properly, this practical Git flow continues directly from the minimum gates above.