Dependency audit

The Dependency Auditor is an AI agent that checks a project's dependencies. It looks for packages with known vulnerabilities (CVEs), license problems and packages that look unmaintained, and suggests an upgrade path for each. Its report then feeds the review that decides whether the change can ship.

Where it runs

The agent is a step in two built-in workflows:

In Dependency Refresh the audit goes first. The Migration Specialist plans the upgrade from its list, the Tester plans how to prove nothing broke, and the Security Auditor checks the result. In Release Readiness the audit sees the three checks before it, and the Architect's go/no-go reads all of them.

Run a dependency audit

1. Open Develop → AI Sessions and choose New session.
2. Describe the task, for example "Audit and upgrade our dependencies before the Q4 release."
3. Choose the Dependency Refresh workflow and your project.
4. Choose Start session.

To run it regularly, schedule the same workflow under Release → Schedules.

What the agent reads

The agent works from a read-only snapshot of your repository, picked for the task:

• Two places are reserved for orientation files: the README and a manifest (package.json, pyproject.toml, go.mod, Cargo.toml or pom.xml).
• Other files are chosen by how well they match the task, up to 16 files and about 32 KB in total.
• Files larger than 48 KB are skipped, and each file is cut at 12 KB.
• Lockfiles such as yarn.lock, Cargo.lock, poetry.lock and go.sum are not included, and a large package-lock.json is skipped by size.

So the agent sees your direct dependencies, not the full transitive tree.

It can also call tools from remote MCP servers you connect, if your workspace policy allows them. It has no other tools: it doesn't run a package manager or query an advisory database.

What it reports

The step writes an audit grouped by problem:

• packages with known vulnerabilities, the affected versions and the first fixed version;
• licenses that may conflict with how the project is distributed;
• packages that look abandoned, with maintained alternatives;
• for each, an upgrade path and how risky it is, such as a patch release versus a new major version.

You can read the full step output on the session's run page.

How findings reach the gate

The agent doesn't file findings directly. At the end of every session, an AI review reads the change's diff, with the output of the review, security, audit and test steps as context. That includes the dependency audit. The review records each concrete issue as a finding with:

• a severity: critical, high, medium, low or info;
• a category, such as dependency, security or compliance;
• a title, a description and a recommendation.

Because both workflows include the Security Auditor, these findings show the Security Auditor as their source.

Open findings of severity high or critical block the pull request until someone triages them. The statuses that still block are open, acknowledged and in progress. See Quality gates for the full rules and how to triage.

Dependency findings appear in the Findings panel of the session's run page. The workspace-wide Secure → Security list shows only the security category, so dependency findings don't appear there.

Limits

• The agent's vulnerability knowledge comes from the model and can be out of date. Confirm critical items with your scanner.
• It sees only the files in the snapshot. Transitive dependencies are mostly invisible to it.
• Its license notes are not legal advice.
• SBOMs are tracked separately; AI CodeOps doesn't generate them. See Security and SBOM.

Next steps

• Quality gates
• Policy rules reference
• DevSecOps and SBOMs