Taking Stock of the Dependencies Your Agent Added — A Design for Keeping License and Provenance Traceable

Implementation 1: Extract the dependencies the agent added

First, mechanically pull out when and what was added. The approach: chase the commits that added lines to the dependencies block of package.json with git log -p. If you keep your setup so agent commits are identifiable by author or committer email, the filtering stays accurate.

The script below lists each line added with + to the dependency sections, alongside the introducing commit's date, author, and subject.

#!/usr/bin/env bash
# scan-added-deps.sh — extract dependencies added to package.json from history
set -euo pipefail
 
PKG="package.json"
 
# Pick only lines added to dependencies / devDependencies, with commit context
git log --diff-filter=AM -p --date=short \
  --pretty=format:'@@COMMIT@@%h|%ad|%an|%s' -- "$PKG" \
| awk '
  /^@@COMMIT@@/ {
    sub(/^@@COMMIT@@/, "");
    split($0, m, "|");
    sha=m[1]; date=m[2]; author=m[3]; subject=m[4];
    next;
  }
  # Target only added lines of the form "  \"pkg\": \"^x.y.z\","
  /^\+[[:space:]]+"[^"]+":[[:space:]]*"[~^]?[0-9]/ {
    line=$0;
    sub(/^\+[[:space:]]+"/, "", line);
    sub(/".*/, "", line);
    printf "%-28s | %s | %-18s | %s\n", line, date, author, subject;
  }
' | sort -u

Running it gives you rows like these.

date-fns-tz                  | 2026-05-31 | antigravity-agent  | fix: make timezone conversion test pass
zod                          | 2026-06-04 | antigravity-agent  | feat: add input validation
p-retry                      | 2026-06-09 | masaki             | chore: centralize retry logic

The author column tells you at a glance which ones came from the agent. The ones you added yourself, like p-retry, you'll remember. The problem children are the quiet agent additions like date-fns-tz. Those are the stars of the audit.

Worth noting: devDependencies come through the same mechanism. Build tools and type definitions are numerous and easy for an agent to grow, so viewing them separately from runtime dependencies lightens the load.

Implementation 2: Collect licenses and check them against a policy

Once you know "what" and "when," the next question is whether the license is acceptable. This part fully automates. Collect licenses from the installed dependencies and color-code them against your policy.

License data lives in each package.json under node_modules. You can tally it with stock Node, no dedicated tool required.

// audit-licenses.mjs — check installed dependency licenses against a policy
import { readFile, readdir } from "node:fs/promises";
import { join } from "node:path";
 
// Your own policy. Tune it to the nature of the project.
const POLICY = {
  allow: ["MIT", "ISC", "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "0BSD"],
  review: ["MPL-2.0", "LGPL-3.0", "CC0-1.0", "Unlicense"],
  // Everything else (GPL family, unknown licenses) is treated as deny.
};
 
async function collect(dir) {
  const out = [];
  for (const name of await readdir(dir)) {
    if (name.startsWith(".")) continue;
    const base = join(dir, name);
    if (name.startsWith("@")) {
      for (const scoped of await readdir(base)) {
        out.push(...(await readOne(join(base, scoped), `${name}/${scoped}`)));
      }
    } else {
      out.push(...(await readOne(base, name)));
    }
  }
  return out;
}
 
async function readOne(base, name) {
  try {
    const pkg = JSON.parse(await readFile(join(base, "package.json"), "utf8"));
    const license = typeof pkg.license === "string" ? pkg.license : "UNKNOWN";
    return [{ name, version: pkg.version ?? "?", license }];
  } catch {
    return [];
  }
}
 
function classify(license) {
  if (POLICY.allow.includes(license)) return "allow";
  if (POLICY.review.includes(license)) return "review";
  return "deny";
}
 
const deps = await collect("node_modules");
const flagged = deps
  .map((d) => ({ ...d, tier: classify(d.license) }))
  .filter((d) => d.tier !== "allow")
  .sort((a, b) => a.tier.localeCompare(b.tier));
 
for (const d of flagged) {
  console.log(`[${d.tier.toUpperCase()}] ${d.name}@${d.version} — ${d.license}`);
}
 
const denied = flagged.filter((d) => d.tier === "deny");
if (denied.length > 0) {
  console.error(`\n⚠️ Action needed: ${denied.length} package(s) hit the deny policy`);
  process.exit(1);
}

Anything in allow is not printed — the only things a person should look at are review and deny. Wire it into CI and the build stops the moment a deny slips in. A pull request where the agent added a new dependency fails this check — that is the moment an audit shifts from a periodic chore to a mechanism that stops contamination before it lands.

License strings vary by package. Some put an object in license instead of a string, or use the old licenses array form. You'll see a flood of UNKNOWN at first, so the realistic move is to handle the most frequent ones first. Prioritize never dropping a deny over perfect classification.

In my own work, the allow policy runs roughly in three tiers.

These tiers shift with the project. A closed commercial app and an OSS project you plan to publish will, of course, draw the deny line differently. What matters is writing it down somewhere and applying the same standard to agents and humans alike.

Record the "why" the moment you add it

We mechanized "what, when, and which license." What remains is "why," and that alone cannot be recovered automatically later. So you need a mechanism that records it — however thinly — at the moment of adding.

What I settled on is appending a provenance trailer to the commit. Git trailers are key: value lines you can pull back out mechanically with git log.

feat: add input validation with zod
 
Consolidate schema definitions in one place and validate at the API boundary.
 
Dep-Added: zod@^3.23
Dep-Reason: hand-written type guards were multiplying; replace them declaratively
Dep-Reviewed-By: masaki

Add one line to your agent instructions (a rule file such as AGENTS.md) — "whenever you add a dependency, always write a Dep-Added and Dep-Reason trailer" — and provenance starts accumulating as a record. You don't need perfection. A single line of reasoning dramatically changes how an audit feels six months out.

When you want to tally the trailers, pull them like this.

git log --pretty='%H %s%n%b' \
  | grep -E '^Dep-(Added|Reason|Reviewed-By):' \
  | sort | uniq -c | sort -rn

Drawing the line in long-term operation

You don't need to run all of this by hand every day. Deciding how it runs is the real substance of the design. Here is how I split it.

The part that stops contamination lives permanently in CI. The license check runs on every pull request and always fails on a deny. No human will is inserted here; the machine owns it.

The audit itself is plenty at once a month. Run scan-added-deps.sh, look over the dependencies the agent added that month, fill in a reason only for the ones missing a Dep-Reason, and drop what isn't used. Half an hour covers it.

And the review cases that genuinely need judgment, I look at myself, each time. Try to automate that and the policy ends up hollow. Keeping the human's scope narrow is, I think, the trick to sustaining this for the long run.

Agents work remarkably conscientiously within a standard you make explicit. The trouble is leaving them to "just handle it" without ever handing over the standard. Auditing dependencies is, in part, the practice of putting that standard into words and splitting the work between machine and human.

As a first step, run scan-added-deps.sh once against your own repository. How many dependencies from the past month do you not remember? That number is the tangible case for turning the audit into a mechanism. I hope it helps anyone juggling several projects the same way.