Framing the Mission

Scope: what to scan, and how deep

A vague brief produces a vague result. Before launching the agent, a few things need deciding:

• Which dependencies — production dependencies only, or development/build ones too? The risk level isn't the same whether a vulnerable package actually runs in production or only serves to compile the project.
• How deep — direct dependencies only, or transitive ones too? Most real-world vulnerabilities hide in transitive dependencies, several levels below what was explicitly added.
• Which repo, which branch — main in production, a dev branch, an entire monorepo?

Explicit success criteria

The brief needs to say precisely what the agent should produce as output: a list of CVEs with severity, a real-exposure verdict for each (module 6), and a proposed fix (module 7) — not just "check if there are any problems".

Explicit prohibitions

This is the part that's most often left out of the brief, and it's the most important:

• No direct commit or push.
• No code changes without human approval.
• No automatic execution of a fix (version upgrade, patch) without review.

A sample brief

Mission: scan the repository's production dependencies (pnpm-lock.yaml).
Expected output: list of open CVEs, sorted by severity, with a real-exposure
verdict for each, plus a proposed fix.
Prohibitions: no commits, no version changes without approval.

That brief fits in four lines. It's enough — and it's already more than what most teams write before launching an agent.