Agentic AI can speed vulnerability check creation, but oversight remains essential

At a glance

What this is: Intruder describes using agentic AI to accelerate vulnerability check creation and improve coverage where existing scanners miss exposed attack surfaces.

Why it matters: For IAM and security practitioners, the lesson is that automation can raise detection velocity, but quality control and verification still determine whether coverage is trustworthy.

By the numbers:

• 92% of technology professionals agree governing AI agents is critical to enterprise security, according to SailPoint.

👉 Read Intruder's analysis of agentic AI for faster vulnerability check creation

Context

Agentic AI can shorten the time needed to create vulnerability checks, but the security problem does not disappear when the generation step gets faster. The hard part is still control quality, because a check that misses a real exposure or flags false positives creates operational noise and weakens trust in the scanner. In vulnerability management, speed without validation can widen the gap between exposure and remediation.

This article sits at the intersection of AI-assisted security engineering and vulnerability management operations. The identity angle is indirect but real: exposed admin panels, leaked credentials, and unauthenticated access paths often become the entry point for identity abuse. That makes the governance question broader than tooling efficiency. Teams need to decide where AI can accelerate work, and where expert review must remain mandatory.

Intruder's experiments suggest the starting position is common rather than unusual. Many teams want more coverage and faster check creation, but few can safely remove human judgement from the loop.

Key questions

Q: How should security teams use agentic AI to create vulnerability checks safely?

A: Use it as a drafting and testing accelerator, not as an autonomous author. The safest pattern is a supervised workflow where engineers define the task, provide reference targets, review the output, and verify the check against both vulnerable and non-vulnerable systems before it enters production.

Q: Why do agentic AI workflows still need human oversight in vulnerability management?

A: Because generated detections can hallucinate unsupported scanner features, choose weak matchers, or miss validation details that affect accuracy. Human oversight is what keeps the output aligned to the actual tool, the real product behaviour, and the organisation's tolerance for false positives and false negatives.

Q: What do security teams get wrong about detection-led security in AI attacks?

A: They often assume detection can still assemble enough context before the attacker finishes. In machine-speed intrusions, the problem is not visibility alone, but timing. If identity controls do not intervene during the request itself, alerts arrive after the meaningful access has already happened.

Q: What should teams do first when introducing AI into detection engineering?

A: Teams should start with a bounded use case, such as one persistence pattern or one log source, and require measurable outcomes before expanding scope. That approach lets security leaders compare AI-assisted rules against analyst-written baselines and prevents the detection programme from becoming dependent on unreviewed automation.

Technical breakdown

Why agentic AI outperforms a simple LLM prompt for detection writing

A plain LLM prompt can draft text, but it does not reliably reason over code structure, validation steps, or tool-specific syntax. An agentic workflow adds search, repository indexing, iterative testing, and feedback loops, which gives the system more context and a way to correct itself. In this case, the agent was able to inspect example templates, compare outputs against known vulnerable and non-vulnerable targets, and refine matchers and extractors. That makes the output more useful for security engineering, but not autonomous in the governance sense.

Practical implication: treat agentic generation as a drafting layer, not a control substitute, and require validation against known good and bad targets before release.

How multi-request checks confirm real exposure rather than surface noise

Effective vulnerability checks often need more than a single response match. A multi-request template can first identify a candidate service, then probe follow-on endpoints to confirm whether data is actually exposed to unauthenticated users. That second step matters because banners, error pages, and partial responses can look risky without proving exploitability. By adding request chaining and stronger matchers, teams reduce false positives and gain confidence that the issue reflects genuine exposure, not just an imprecise fingerprint.

Practical implication: design detections to prove exposure, not presence, especially where scanners are used to drive remediation queues.

Why hallucinations and tool-use gaps still limit full automation

The article highlights three recurring failure modes. First, the model can invent functionality that does not exist in the underlying scanner. Second, it can choose weak matchers that pass validation but produce false positives. Third, it can mis-handle command-line capabilities and waste context, which reduces completeness. These are not cosmetic issues. They are governance failures because they affect whether the detection pipeline can be trusted to represent the attack surface accurately.

Practical implication: keep a human approval step for generated checks until the pipeline can prove deterministic tool use, validation, and coverage consistency.

Threat narrative

Attacker objective: The objective is to find and operationalise exposed services before defenders can close the visibility gap.

1. Entry occurs when an exposed administrative panel or unsecured service is discovered by the scanner and treated as a potential attack surface.
2. Escalation follows when the check confirms the service is truly unauthenticated or misconfigured, turning discovery into actionable exposure intelligence.
3. Impact is the ability to prioritise and remediate real exposure faster, while reducing false negatives that would otherwise leave reachable systems untracked.

NHI Mgmt Group analysis

Agentic AI can accelerate vulnerability engineering, but it does not remove the need for governed validation. The article shows that generation speed improves when agents can search, index, and test against known targets, but that same workflow still depends on human review. For security programmes, the real question is not whether AI can write checks, but whether the organisation can prove those checks are accurate enough to drive remediation. Practitioner implication: treat agentic output as supervised security engineering.

Detection quality is now an operational control, not just an engineering preference. False positives and false negatives shape whether a scanner becomes trusted evidence in risk decisions. That matters for vulnerability management, but also for IAM and NHI governance because unauthenticated panels, exposed credentials, and weakly protected admin paths often become identity abuse pathways. Practitioner implication: quality gates for detection content should sit alongside change control and review.

Agentic tooling introduces a governance debt problem when teams scale output faster than review capacity. The more checks an organisation generates, the more it needs traceability around what was created, tested, accepted, and retired. That is similar to configuration sprawl in other security domains, except the sprawl now includes machine-generated logic. Practitioner implication: log prompt inputs, test cases, and acceptance criteria as part of the control record.

Automated vulnerability creation is most valuable where the attack surface is repetitive and shallow, not where judgment is complex. Exposed panels, standard misconfigurations, and known product fingerprints are good candidates. Complex exploit reasoning, ambiguous match logic, and edge-case validation still need experienced engineers. Practitioner implication: reserve AI for high-volume detection drafting and keep expert ownership for any check that influences severity or exposure decisions.

AI-assisted security engineering should be measured by precision, coverage, and remediation value, not by the number of templates produced. Template count alone can reward noise. A mature programme evaluates whether generated checks reduce blind spots, improve time-to-detect, and survive regression testing across environments. Practitioner implication: tie agentic AI adoption to measurable detection outcomes, not throughput claims.

What this signals

Agentic AI will increasingly sit inside detection engineering pipelines, which means programme owners need to govern not just the scanner, but the logic that creates the scanner content. The practical shift is from code review alone to model-assisted change control, where prompts, test targets, and acceptance criteria become part of the evidence chain.

Template governance debt: when AI-generated checks scale faster than validation, the organisation accumulates hidden risk in the detection layer itself. That risk belongs in security engineering metrics, not just in model governance reviews. Teams should pair agentic automation with explicit approval gates, regression testing, and traceable ownership for every generated control.

This also reinforces a broader identity-security lesson. Exposed panels, unauthenticated endpoints, and weak service controls often become the entry points for credential abuse, privilege escalation, and NHI compromise. The control problem is not only discovering more assets, but proving that the checks describing those assets are accurate enough to trust.

For practitioners

• Set a supervised generation workflow for new checks Require engineers to provide the task, target examples, expected matcher type, and extraction criteria before the agent drafts a template. Keep human review mandatory before any generated check is accepted into the production scanner.
• Validate detections against both vulnerable and non-vulnerable targets Use known-good and known-bad hosts for every new template so the check proves exposure rather than just recognising a product fingerprint. This is especially important for admin panels and services that can return misleading banners.
• Track false positives as a control metric Measure how many generated checks create noisy results, because false positives consume triage time and reduce trust in the scanner. Review every template that affects severity, prioritisation, or incident escalation.
• Preserve scanner capability knowledge in rules and prompts Document supported scanner features such as host lists, request chaining, and extraction logic so the agent does not invent inefficient workarounds or miss available flags.

Key takeaways

• Agentic AI can accelerate vulnerability check creation, but it only works as a governed drafting layer, not an autonomous security control.
• The core technical challenge is accuracy, because hallucinations, weak matchers, and tool-use mistakes can create false confidence in coverage.
• Teams should judge AI-assisted detection engineering by validated exposure coverage and reviewability, not by how many templates the model produces.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Detection Engineering: The discipline of designing, testing, and maintaining detection logic so it remains useful against real attacker behaviour. It covers telemetry selection, rule quality, false-positive management, and the operational workflow needed to keep alerts actionable.
• False Positive: A false positive is a scanner result that looks like a secret but is not actually sensitive. In secret governance, false positives matter because they consume analyst time, weaken trust in alerts, and can delay response to the findings that truly change exposure and access risk.
• Matcher: A matcher is a condition a security check uses to decide whether a target matches a vulnerability pattern or exposed state. Strong matchers help prove that a service is truly risky, not merely present or returning a generic response.

What's in the full article

Intruder's full article covers the operational detail this post intentionally leaves for the source:

• The exact prompt structure and rule set used to steer the agent during template creation
• Step-by-step examples of how the Elasticsearch detection was built, tested, and refined
• Specific false-positive fixes, including matcher changes that reduced noisy results
• Practical notes on how the team used Cursor to index a curated Nuclei repository

👉 Intruder's full post covers the template workflow, testing approach, and the limits of automation

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps security practitioners connect identity controls to the broader risk decisions their programmes already own.