Why Hand a Security Mission to an Agent?
A volume of CVEs that outpaces human scale
A modern .NET project easily carries several hundred dependencies, direct and transitive. Every week, new CVEs (Common Vulnerabilities and Exposures) are published affecting some part of that ecosystem. Triaging that by hand — reading every advisory, checking whether it actually concerns the project, judging severity — simply doesn't scale for a team that also has to ship features.
That's the kind of repetitive, high-volume, low-variance task that suits an AI agent well: search, list, cross-reference against the project's real dependencies, propose a first pass at prioritization.
What agentic methods change here — and what they don't
An agent can scan an entire lockfile in seconds, cross-reference every package against an advisory database, and produce a structured list. What it doesn't do correctly on its own: judge whether a CVE is actually exploitable in the project's context, decide whether the proposed fix is the right one, or know what it's allowed to touch without approval.
In other words: the search can be delegated, the final judgment cannot. That's the thread running through this entire course.
This course's running example
Over the following modules, we'll follow a concrete mission handed to an agent, step by step: find the CVEs in a .NET project's dependencies, verify whether the code is actually exposed, and propose a fix — with, at every step, the same question: what did the agent get right, what did it miss, and what stays strictly ours to decide.
Check your understanding
What is the main problem posed by the volume of CVEs in a modern project?
Under what condition does an AI agent become genuinely useful on a security mission?