AI Agents in Vulnerability Management Guide: Safe Autonomy from Triage to Verified Fix

AI agents are being given the vulnerability management workflow itself, enriching findings, deciding priority, opening tickets and proposing patches, and each of those steps needs credentials that reach the scanner, the asset inventory, the ticketing system and the code repositories. The pressure is real: the NVD has stopped enriching most CVEs, scanners produce more findings than teams can read, and remediation targets are measured in days. This guide covers how to use agents across the vulnerability management lifecycle without letting them close findings that are still open, bury exploited vulnerabilities or push untested changes. It is for vulnerability management leads, security engineers and platform teams. For AI that finds new bugs in code, see the AI for Vulnerability Discovery and Triage Guide; for change safety in general, see the Automated Remediation Safety Guide.

Key takeaways

• Agents should compute priority from authoritative data, not opinion. KEV status, EPSS, SSVC decision points and asset context are inputs the agent fetches and records; the model explains and routes, it does not invent severity.
• Closing a finding is the riskiest action an agent can take. Dismissal, risk acceptance and "fixed" status must need a rescan or a human, because a wrongly closed finding disappears from every report.
• Advisory text and scanner output are untrusted input. CVE descriptions, package metadata, issue comments and error reports can carry prompt injection aimed at the agent that reads them.
• Each agent gets its own narrow identity per step. Read on the scanner, write on tickets, draft pull requests only on repositories: never one admin token across the toolchain.
• Measure the agent against the programme metrics you already report. Time to remediate KEV items, reopen rate after agent closure and override rate show whether autonomy is earning its place.

Why teams are handing the workflow to agents

Three pressures are pushing vulnerability management towards agents rather than simple automation rules.

• Enrichment has moved to the consumer: NIST reports that the NVD built up a significant backlog of unenriched CVEs from early 2024. From 15 April 2026 NIST enriches only CVEs that are in CISA's KEV catalogue (with a goal of one business day), software used in the federal government and critical software under Executive Order 14028; other CVEs are labelled lowest priority and are not scheduled for immediate enrichment. Many records now arrive without CVSS, CWE or CPE data, and someone has to fill the gap.
• Prioritisation needs several sources: CISA's KEV catalogue, FIRST's EPSS (a daily probability that a published CVE will be exploited in the wild in the next 30 days) and SSVC decision points from CISA's Vulnrichment programme each answer part of the question. Joining them to your own asset inventory is repetitive work that agents do well.
• Remediation targets are tight: CIS Controls v8.1 Safeguard 7.2 asks for a risk-based remediation process reviewed monthly or more often, and 7.7 for remediation of detected vulnerabilities monthly or more often. Ticket routing, owner lookup and status chasing fill the time in between.

The risk changes too. A rules engine that dismisses development-only findings does exactly what its rule says. An agent that reads an advisory and decides a finding "does not apply" can be wrong, can be manipulated, and leaves a plausible explanation behind either way.

Agent roles across the lifecycle

Split the workflow into roles with different authority. The table is the starting design most teams can adopt; move a role up a column only with evidence from the metrics below.

The SSVC outcomes come from CISA's guidance: Track needs no action beyond standard timelines; Track* warrants closer monitoring; Attend needs supervisory attention and faster remediation; Act needs supervisory and leadership attention and remediation as soon as possible. Attend and Act involve people by definition, which is why the agent stops there. See the SSVC Guide and the EPSS Guide.

Choosing how much autonomy

• Small teams (one or two analysts): the biggest gain is intake, enrichment and ticketing. Keep fix proposal on platform features with human review, and keep closure rescan-driven. Do not build custom agents with repository write access.
• Large programmes: separate agents per role with separate identities, a shared decision tree under change control, and second-line review of the agent's prioritisation on a sample each month.
• Regulated or safety environments: agents stay advisory for anything touching production change. In OT, follow the ICS Advisory Triage and OT Vulnerability Management Guide; agent-drafted patches never go to control systems without the site's change process.
• Deterministic rule or agent? If the decision can be written as a rule (development-scoped dependency, severity below a threshold, asset tag), use a rule. Dependabot auto-triage rules, for example, can dismiss, snooze or open pull requests by severity, package name and CWE, and auto-dismissed alerts reopen if their metadata changes. Use an agent only where reading unstructured text adds value: vendor advisories, mitigation notes, reachability evidence.

Prioritisation that stays explainable

The agent's prioritisation must be reproducible by a human with the same inputs. Build it as a pipeline with the model at the edges, not in the middle.

1. Fetch facts deterministically: KEV membership from the CISA feed, EPSS score and percentile from the FIRST API, SSVC Exploitation, Automatable and Technical Impact values from the CISA ADP container, asset criticality and exposure from your CMDB or attack surface tool.
2. Record provenance: each field carries its source and retrieval time. Agent-drafted values (a CVSS v4.0 vector where none exists, a guessed CPE) are tagged as such and labelled with the CVSS nomenclature for the groups used (CVSS-B, CVSS-BT, CVSS-BE or CVSS-BTE).
3. Apply the decision tree in code: the documented tree from your remediation process produces the outcome. The model may suggest values for decision points that need judgement, such as Mission Prevalence, but the suggestion is visible and overridable.
4. Floor rules the agent cannot cross: a KEV-listed vulnerability on an internet-facing asset is never below your top tier; CISA says KEV entries need a CVE ID, reliable evidence of active exploitation and a clear remediation action, so treat them as confirmed risk.
5. Let the model explain: the agent writes the ticket summary, affected assets, fix and rationale in plain language for the owner.

See the Vulnerability Prioritisation Guide and the Risk-Based Vulnerability Management Guide for the decision models themselves.

Threats to the agent itself

A vulnerability management agent reads a great deal of text written by outsiders: advisories, package READMEs, changelogs, issue threads, bug bounty submissions and error reports. That makes it a prime target for indirect prompt injection (MITRE ATLAS AML.T0051.001, OWASP LLM01:2025 Prompt Injection).

The pattern is not theoretical. In the Sentry MCP agentjacking case, fake error reports submitted through a public DSN were used to hijack AI coding agents that read them: exactly the kind of feed a remediation agent consumes. See the Prompt Injection Guide.

Fix proposals and patch automation

Platform features already draft fixes. GitHub's documentation for Copilot Autofix for code scanning states that suggestions are built from the alert, surrounding code and query help, are non-deterministic, may change program semantics, may fail to fix the vulnerability or introduce new ones, and may suggest insecure or fabricated dependencies. Treat every agent-drafted fix the same way, whatever the vendor.

• Draft, never merge: agents open draft pull requests or change requests; branch protection, required reviews and CI stay in force. The agent's identity is not in any bypass list.
• Tests are part of the fix: the agent runs the existing test suite and, where a reproducer exists, adds it as a regression test.
• Dependency bumps prefer the minimum fixed version named in the advisory, from an approved registry, rather than whatever the model believes is latest.
• Infrastructure and endpoint patching goes through your patch tool's rings, not the agent's own scripts. NIST SP 800-40 Rev. 4 frames patching as preventive maintenance with identify, prioritise, acquire, install and verify steps; the agent feeds the first two and the last, the patch platform does the middle. See the Patch Rings and Update Orchestration Guide.

Where identity fits

A vulnerability management agent is a non-human identity with unusually sensitive reach: it knows every unpatched weakness and often holds tokens for the scanner, the CMDB, the ticketing system and source control. An attacker who takes it over gets a map of the estate and a path to change code.

• One identity per agent role: registered with an owner, purpose and expiry, authenticated with workload identity federation or short-lived tokens rather than static API keys (NIST SP 800-53 IA-9, AC-6).
• Separation of duties: the identity that proposes a fix cannot approve it; the identity that drafts an exception cannot accept it (AC-5).
• Scanner credentials stay in the scanner: authenticated scan credentials are never exposed to the agent's context. See Securing the vulnerability scanner itself and the Vulnerability Scanner Integration Security Guide.
• Secrets injected at runtime: tokens never appear in prompts or logs. See Runtime Secrets Injection for AI Agents Without Prompt Exposure.
• Action log tied to identity: every ticket edit, status change and pull request records the agent identity, inputs used and the approving human where one was needed (AU-12).

See the Agent Identity and Access Guide.

Implementing in phases

1. Baseline: record current metrics for four weeks: median time to remediate by tier, KEV items past due, findings without an owner, reopen rate.
2. Shadow mode: the agent enriches and prioritises in parallel, writing to a side table. Analysts compare its outcome with theirs on every item; disagreements are reviewed weekly.
3. Intake, enrichment and ticketing live: once agreement on Attend and Act items is high and no KEV item has been misclassified, let the agent create and route tickets. Humans still confirm Attend and Act.
4. Fix proposals on a pilot ring: a handful of repositories with good test coverage and willing owners. Track merge rate, rework and any regressions.
5. Rescan-driven closure: allow the agent to close only where an authenticated rescan confirms the fix; everything else goes to a human queue.
6. Expand or stop: widen scope only if the metrics hold. Rollback is simple and should be rehearsed: revoke the agent's tokens, disable its integrations and reopen anything it closed in the last cycle for human review. Wire the steps to a kill switch. See the AI Agent Kill Switch and Containment Guide.

Detection and measurement

Log every agent action as a security event: tool called, record changed, before and after values, inputs referenced, identity and approver. Alert on these signals:

• Any downgrade or closure of a KEV-listed or Act item.
• Closure volumes outside the normal band, or closures without a linked rescan.
• Agent tool calls outside its declared set, such as policy changes on the scanner.
• Pull requests from the agent identity to repositories outside the pilot set.
• Untrusted content containing instruction-like text reaching the agent (flagged by input filters).

Framework mapping

Common failure patterns

• Letting the agent decide "not applicable": reasoning about reachability or mitigation without evidence produces silent risk acceptance. Require a rescan or a human.
• One super-token: a single service account with admin on the scanner, ticketing and source control turns a prompt injection into a code change.
• Agent scores presented as official: drafted CVSS vectors flow into reports and SLAs as if the vendor had published them. Tag provenance on every field.
• Reading attacker-controlled feeds with tools enabled: bug bounty submissions, issue comments and error reports processed by an agent that can also act on them, as in the Sentry MCP agentjacking case above.
• Forgetting the attacker has agents too: the Anthropic GTG-1002 campaign showed agent-orchestrated intrusion work at speed; exposure windows measured in weeks are now harder to defend. See Autonomous AI Attack Agents.

Practitioner checklist

• Write down which lifecycle steps the agent may perform alone, propose or never touch.
• Fetch KEV, EPSS and SSVC values deterministically and record source and time for every field.
• Encode the prioritisation decision tree in code with KEV floor rules the agent cannot override.
• Give each agent role its own short-lived identity with least privilege and no branch protection bypass.
• Process untrusted advisory, issue and report text in a step with no tool access.
• Allow closure only on a clean authenticated rescan or named human approval.
• Run in shadow mode before going live and compare against analysts on every Attend and Act item.
• Track reopen rate, override rate and KEV time to remediate monthly.
• Rehearse rollback: revoke tokens, disable integrations, reopen recent agent closures.

Standards and references

• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• CISA: Vulnrichment
• FIRST: Exploit Prediction Scoring System (EPSS)
• NIST: National Vulnerability Database
• NIST: SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning
• OWASP: Top 10 for LLM Applications 2025
• GitHub Docs: Responsible use of Copilot Autofix for code scanning

Related NHI Mgmt Group resources: Vulnerability Management Guide · AI for Vulnerability Discovery and Triage Guide · Automated Remediation Safety Guide · AI Agent Action Approvals and Spending Limits Guide · AI Agents in DevOps and SRE