Should organisations use AI coding agents for vulnerability hunting or human review?

When AI coding agents help, and when they mislead

AI coding agents are best treated as high-speed assistants for candidate generation and triage, not as trusted arbiters of whether a finding is real. They can quickly surface suspicious patterns, but they do not reliably separate exploitable defects from harmless oddities, especially when the code path spans configuration, build context, or tool output that changes the meaning of the result.

That distinction matters because vulnerability hunting is not just pattern matching. A useful candidate still needs human judgment to decide whether the issue is reachable, whether preconditions are realistic, and whether the apparent weakness is actually exploitable in the target environment.

AI is strongest where breadth is the problem: scanning more code, proposing more hypotheses, and clustering similar findings so analysts do not spend time on obvious dead ends. It is weaker where the question is, “Can this be exploited, under what constraints, and with what impact?” That second question usually depends on architecture, runtime behaviour, and operational context that the model may not truly understand.

Why deterministic validation still has to sit in the loop

A human review layer is still necessary because vulnerability discovery depends on confirmation, not just suspicion. Static analysis, tests, proof-of-concept reproduction, and manual code inspection remain the main ways to validate whether a candidate finding is real and whether it matters.

This is especially important for edge cases, where AI tools may overstate severity or miss the contextual detail that turns a harmless pattern into a genuine bug. For example, a suspicious function call may be safe because of upstream sanitisation, a dependency may be present but unused, or a code path may exist only in test fixtures. An agent can flag these cases, but it should not be the final decision-maker.

Deterministic tools also provide a repeatable basis for review. When teams rely only on probabilistic output, they often create a new failure mode: too many false positives, too much reviewer fatigue, and a tendency to accept machine output because it sounds confident. AI agent observability and incident response practices become useful here because the same discipline that explains agent behaviour also helps teams explain why a candidate was accepted or rejected.

How to structure a safe vulnerability-hunting workflow

The practical pattern is a two-stage workflow. First, let the agent generate candidates, rank them, and cluster duplicates. Second, route only the most plausible items into human review and deterministic validation. That keeps the speed benefit without letting the agent silently own the security decision.

One useful rule is to treat the agent’s output as advisory unless the finding can be reproduced, reasoned about, or measured. If the tool cannot point to the exact code path, precondition, or exploit condition, it should remain a lead rather than a conclusion.

Another useful boundary is ownership. Least-privilege authorisation for AI agents matters even in vulnerability hunting, because the same assistant that reads code can also trigger tools, reach repositories, or interact with CI systems. Keep those permissions narrow, and keep approval gates around actions that could modify code, release artefacts, or production-like environments.

At scale, the question is not whether the agent is clever enough. The question is whether the process preserves review quality as volume rises. That means keeping reproducibility, traceability, and human accountability in the loop even when the agent is doing the first-pass search.

Risk and Threat Considerations

AI coding agents can create security risk when teams confuse fast output with trustworthy validation. A noisy model may amplify false positives, while an over-permissive agent may take actions beyond the hunting task, such as touching repositories, secrets, or deployment workflows.

Failure mechanism: The agent generates plausible but unverified findings, or it is given enough access to move from analysis into action. In both cases, the organisation can end up either chasing phantom issues or exposing code, credentials, or change paths that were never meant to be in scope.

Impact: Teams waste review capacity, miss real vulnerabilities, or introduce a second-order security problem through excessive agent access. In the worst case, a hunting tool becomes an execution path that changes systems instead of merely evaluating them.

Practitioner Guidance

What to prioritise: Put human review on anything that affects exploitability, blast radius, or release decisioning. Use the agent to widen coverage, not to decide severity.

What to verify: Require a reproducible reason for every accepted finding, such as a concrete code path, test result, or manual confirmation that the issue is reachable in the target environment.

Common mistake: Treating the model’s confidence as evidence. In vulnerability hunting, confident output is only a starting point.

Practitioner takeaway: The right operating model is “AI for discovery, humans for proof.” That keeps the speed advantage while preserving the security judgment that actually determines whether a finding deserves action.

Related resources from NHI Mgmt Group

• Why do AI coding agents increase software risk if organisations keep the same review process they used for human developers?
• What breaks when human-in-the-loop review is the only control for AI coding agents?
• What breaks when organisations try to use human signup controls for AI agents?
• How should security teams use AI-assisted coding environments to accelerate vulnerability remediation without losing control of approvals and review?