A field guide to agentic vulnerability management (with an actual off switch)

An agent is more than another scanner integration. It can collect evidence, choose tools, form a plan, modify systems, and evaluate the result. Those capabilities can remove enormous amounts of vulnerability-management toil. They can also convert a bad assumption into a production change at machine speed, which is a less charming demo.

The right question is not whether to use agents. It is where an agent’s authority should begin and end.

Start with the management loop

Agentic vulnerability management works best when the workflow has explicit stages and evidence gates.

Inventory

The agent needs a dependable map of assets, owners, software, environments, identities, data, and exposure. Let it reconcile sources and flag contradictions, but preserve provenance. “The CMDB says so” and “a network observation confirmed it” are not interchangeable facts.

Triage

Let agents gather version evidence, reachability, exploit prerequisites, public exploitation status, and compensating controls. Require the output to separate observed facts from inferences and unknowns.

Decision

Use policy to determine when an agent may recommend, when it may prepare a change, and when approval is mandatory. Consequence, reversibility, confidence, and blast radius should influence the boundary.

Remediation

Agents are well suited to repetitive upgrades, configuration changes, test generation, and pull-request preparation. Production execution should begin with low-blast-radius, reversible cases and mature only when verification is reliable.

Verification

Verification must test the original security claim. A package upgrade is not complete because the lockfile changed. Confirm the deployed version, the relevant behavior, and the absence of an obvious regression.

A five-level autonomy model

Level 0 — Observe. The agent reads data and produces a traceable assessment. It cannot create or change records.

Level 1 — Recommend. The agent proposes priority, ownership, and actions with evidence. A person makes the decision.

Level 2 — Prepare. The agent creates tickets, patches, tests, or change plans. A person approves execution.

Level 3 — Execute with approval. The agent performs an approved, bounded action and collects verification evidence.

Level 4 — Execute by policy. The agent acts without per-change approval inside a narrow, pre-approved policy boundary. Exceptions and failed verification stop the workflow.

Teams should assign a level to each action, not to the agent as a whole. The same agent might autonomously enrich an advisory while requiring approval to rotate a credential and being entirely prohibited from accepting risk.

The control plane matters more than the model

Model selection matters, but the surrounding system determines whether an agent is governable.

At minimum, keep:

• a durable record of the inputs, tools, and actions;
• scoped credentials with short lifetimes;
• explicit allowlists for systems and operations;
• separation between proposing and approving high-impact changes;
• deterministic policy checks outside the model;
• time, cost, and action limits;
• a reliable stop mechanism;
• independent verification for consequential remediation.

Do not give an agent a broad credential because its prompt says to be careful. Prompts guide behavior; permissions bound it. “Please do not rotate production” is not an IAM policy.

Failure modes to design for

Confident but incomplete context

The agent sees a vulnerable version but misses that the asset is a fragile production appliance. Or it sees a compensating control but misses that the control is in monitor-only mode. Make missing context visible and teach workflows to stop on critical unknowns.

Tool and instruction injection

Advisories, repositories, tickets, and webpages are untrusted input. An agent that reads them and can take action crosses a trust boundary. Treat retrieved instructions as data, constrain tools, and avoid placing secrets in model-visible context unless required.

Patch success without risk reduction

The pull request merges, but the affected workload never redeploys. The configuration changes, but another path remains exposed. Couple remediation to deployed-state verification.

Automation bias

Reviewers approve because the evidence packet looks polished. Show uncertainty, source provenance, conflicting signals, and what was not checked. Good presentation should make judgment easier, not ceremonial.

A safe first deployment

Choose a repetitive vulnerability class with good inventory data, a reversible remediation, reliable tests, and clear ownership. Let the agent enrich findings and prepare changes. Measure technical accuracy, time saved, reviewer corrections, failed verification, and recurrence.

Only expand authority after the evidence says the control loop works.

The objective is not an agent that closes the most tickets. We already have bulk-edit for that. It is a system that makes more correct risk decisions, executes them safely, and can explain what happened afterward.