How AI Agents Chain Security Tools Into Real Attack Paths

What does it mean for an AI agent to "chain" tools?

Tool chaining means using the output of one security tool as the input to the next, so a sequence of narrow tools composes into a path toward impact — and an AI agent adds a decision layer that picks which tool to run next based on what it has already learned. A human pentester rarely runs one tool in isolation. They enumerate subdomains, notice a login portal, fingerprint the stack, test an exposed API, and connect those steps into a chain. The classic ProjectDiscovery pipeline makes this concrete: subfinder discovers subdomains, httpx probes which of them are live and returns server, title, and status metadata, and nuclei runs templated checks against the hosts that survived. Each stage narrows and enriches the data the next stage consumes.

An AI agent replicates that loop rather than a fixed script of it. It maintains state, decides which tool to call next given current findings, and stops when it has either demonstrated impact within scope or exhausted the attack surface it was authorized to touch.

How does an agent plan and sequence a pentest across phases?

The agent maps its work to well-understood offensive phases — reconnaissance, enumeration, vulnerability scanning, web testing, and (gated) exploitation — and selects real tools appropriate to each phase, using earlier outputs to prune and prioritize later ones. These phases loosely track MITRE ATT&CK tactics: Reconnaissance and Resource Development are pre-compromise, while Discovery, Credential Access, and Lateral Movement come after initial access. MITRE deliberately does not impose a fixed order — real engagements skip phases, loop back, and run tactics in parallel — which is exactly why an adaptive planner, rather than a rigid pipeline, has value.

Here is how phases map to real, widely used tooling and what each stage produces:

The value of the agent is in the arrows between rows. A nuclei template only fires usefully against a live host, so it depends on httpx output; httpx only has hosts to probe because subfinder resolved them first. The agent's job is to route data through that graph and decide when a branch is worth pursuing.

How does one tool's output feed the next decision?

Chaining works because each tool emits structured output that becomes a typed input to the next tool or a fact in shared state, not free-form text the model has to re-interpret. Two concrete data flows illustrate this.

First, the recon chain: subfinder emits a list of resolved subdomains → that list pipes into httpx, which filters to responsive hosts and annotates each with status code, title, and detected technology → those enriched hosts feed nuclei, which selects templates (for example, CVE or exposure categories) matching the fingerprint. Each hop discards noise and adds context.

Second, the service-to-CVE correlation: nmap -sV performs service and version detection, and that version string is the pivot. NSE scripts and databases such as the Vulners script match a detected product and version against known CVEs, marking a service VULNERABLE with a reference when the version falls in an affected range. The agent then treats that CVE as a hypothesis — a lead to corroborate with a second signal — not as a confirmed finding.

# Pseudo-orchestration loop (illustrative — not an exploit)
state = { scope: engagement.allowlist, findings: [] }

while not stop_condition(state):
    action = planner.next_action(state)          # LLM proposes a tool call
    if not scope.permits(action.target):         # harness enforces RoE
        continue
    if action.class == "exploit":
        require_human_approval(action)            # gate before any impact
    result = tools[action.name].run(action.args) # typed adapter, structured out
    state = observe(state, result)               # update shared state
    for f in candidate_findings(result):
        if verify(f) == PROVEN:                   # non-destructive proof gate
            state.findings.append(f)

The pattern that matters is that run() returns structured data and verify() sits between "the scanner said so" and "we reported it."

When is a deterministic pipeline better than an LLM planner?

A fixed, deterministic phase-runner is better whenever the workflow is stable, the ordering is known, and you want speed, cost predictability, and bit-for-bit reproducibility; an LLM planner earns its keep only when the environment is genuinely uncertain and branching decisions add value. This trade-off is easy to get wrong — teams reach for an autonomous agent when a shell script would be cheaper, more reliable, and easier to audit.

In practice the strongest designs are hybrids: deterministic runners handle the well-trodden recon-to-scan backbone, and the model is invoked only at genuine decision points — "given these three live services and this fingerprint, which is worth deeper web testing?" That keeps most of a run cheap and reproducible while reserving the expensive, probabilistic reasoning for where it actually changes the outcome.

How do you keep an autonomous offensive agent safe?

Safety is enforced by the harness that surrounds the model — not by trusting the model to behave — through scope enforcement, non-destructive defaults, human approval for exploit-class actions, and treating all tool output as untrusted data. An agent holds the combined permissions of every tool it can call, so a single bad decision or an injected instruction can cascade into a chain of tool calls. The controls exist precisely because the model is fallible.

Scope enforcement is the most important control. It runs as code before every tool call — the agent physically cannot dispatch a request at a host outside the engagement's allowlist, regardless of what it "decides." Exploit-class modules add a second gate: a human confirms rules of engagement before any action that could change target state. This human-in-the-loop step is deliberate friction, and it is where autonomy should stop.

How do you cut false positives with verification?

A verification gate re-tests each candidate finding with an independent, non-destructive check and only promotes it to a report if a concrete proof is produced — turning "the scanner flagged a version" into "we corroborated the condition." Version-based signals from nmap or nuclei are a starting hypothesis, not a conclusion: a backported patch, a WAF, or a customized build can make a version string lie. Corroboration means confirming the actual vulnerable behavior through a second, safe signal before a human ever sees it.

This matters because false positives are the fastest way to destroy trust in automated testing. Independent research on LLM-driven penetration testing has repeatedly found that unconstrained agents hallucinate steps and successes, which is exactly why the reporting path must depend on evidence rather than on the model's own confidence.

Treat every scanner result as a lead, not a verdict. The finding is only as credible as the independent proof attached to it.

Where does AI genuinely help, and where is it over-hyped?

AI genuinely helps with adaptive sequencing, correlating findings across tools, prioritizing where to look next, and drafting readable reports; it is over-hyped as an autonomous discoverer of novel vulnerabilities and as a replacement for skilled human judgment. Being honest about the split is what makes the technology useful rather than a liability.

Where it genuinely helps:

• Adaptive routing across a large tool graph, skipping irrelevant steps a static script would still run.
• Correlation — connecting a service banner, a CVE match, and an exposed endpoint into a single coherent lead.
• Continuous coverage — re-running the repeatable backbone on every deploy so regressions surface early.
• Triage and reporting — summarizing evidence and reducing noise for human reviewers.

Where it is over-hyped:

• Novel bug discovery — finding genuinely new classes of vulnerability remains a human strength; agents mostly recombine known checks.
• Full autonomy — removing the human from exploit-class decisions trades away safety for a demo.
• Trust without proof — an eloquent summary of an unverified finding is worse than no finding.

Why not just script the same sequence?

A static script is often the right choice — and you should prefer it when the sequence is stable — but it breaks the moment an environment diverges from the author's assumptions, whereas an agent branches on what it finds and pursues the path that actually leads to impact. The point is not that agents beat scripts; it is that the two solve different problems. Scripts win on the predictable backbone. The agent earns its cost only at the branch points, and always inside the same safety and reproducibility rails as the deterministic parts of the run.

Key takeaways

• Tool chaining is composition: each tool's structured output becomes the next tool's input, and the AI adds a decision layer over that graph.
• The canonical recon chain — subfinder → httpx → nuclei — works because every hop narrows and enriches the data.
• Map phases to real tools (nmap, nuclei, ZAP, ffuf, sqlmap, Prowler) and let earlier outputs prune later ones.
• Prefer a deterministic pipeline by default; add an LLM planner only at genuine branching decisions.
• Safety lives in the harness — scope enforcement, non-destructive defaults, and human-in-the-loop for exploitation — not in trusting the model.
• Treat all tool output as untrusted data; output-borne instructions are prompt injection, and function calling is a privilege boundary.
• Every finding needs an independent, non-destructive proof before it is reported; scanner version matches are hypotheses, not verdicts.

Frequently asked questions

Does the AI decide what's in scope?

No. Scope is fixed configuration enforced by the harness in code that runs before every tool call. The agent chooses tools and order within that boundary and cannot expand it — not by reasoning, and not because a target told it to.

How does the agent chain recon tools together?

It routes structured output between narrow tools: subfinder resolves subdomains, httpx filters them to live hosts and fingerprints each, and nuclei runs templates matched to those fingerprints. Each stage consumes the previous stage's typed output rather than re-parsing free text.

When should I use a fixed pipeline instead of an AI agent?

Whenever the workflow is stable and the ordering is known. A deterministic pipeline is faster, cheaper, and exactly reproducible. Reserve the LLM planner for genuinely uncertain environments where branching on findings changes the outcome, and consider a hybrid that uses the model only at decision points.

How do you stop the agent from acting on malicious tool output?

All tool output is treated as data, never as instructions. Authorization and scope come only from the engagement config, so a banner or page that says "scan this new range" is ignored as a prompt-injection attempt. Function calling is treated as a privilege boundary, with tool visibility scoped to the task.

How are false positives handled?

A verification gate re-tests each candidate finding with an independent, non-destructive check and requires concrete proof before it becomes a report. A version-based CVE match from nmap or nuclei is a lead to corroborate, not a confirmed finding.

Where does AI clearly help versus where is it hype?

It clearly helps with adaptive sequencing, cross-tool correlation, continuous coverage, and report drafting. It is over-hyped as an autonomous discoverer of novel vulnerabilities and as a replacement for human judgment on exploit-class decisions.

Is this a replacement for human pentesters?

No. It handles the repeatable, continuous testing between deep human engagements, freeing experts to focus on novel, high-value targets rather than re-running the same checks on every deploy. The human stays in the loop for exploitation and final judgment.

RedStrike's agent follows exactly this shape: deterministic tool adapters for the repeatable backbone, an LLM planner only at real decision points, and a harness that enforces scope, keeps defaults non-destructive, and gates exploit-class actions behind a human. Findings ship only after independent verification, so continuous testing stays both adaptive and accountable.

Sources

• ProjectDiscovery — Reconnaissance Series: Host and Port Discovery
• MITRE ATT&CK — Enterprise tactics and matrix
• Netlas — How to Detect CVEs Using Nmap Vulnerability Scan Scripts
• Repello AI — Pentesting Agentic AI: why the methodology changes when your LLM has tool access
• Sentry Security — Exploiting Tool and Function Calling in LLM Agents
• OWASP Top 10 for LLM Applications — Prompt Injection
• Anthropic — Tool use (function calling) documentation