From 2cb04ae677925b79d28c11cf4e65bcb14b2e6c93 Mon Sep 17 00:00:00 2001
From: GangGreenTemperTatum
 <104169244+GangGreenTemperTatum@users.noreply.github.com>
Date: Tue, 11 Aug 2026 10:47:50 -0400
Subject: [PATCH 1/2] fix(web-security): preflight tooling guard when pdtm
 tools unavailable (CAP-1174)

Add a 'Preflight Tooling' section to the web-security agent prompt so that
when required external binaries (ProjectDiscovery pdtm suite: nuclei, httpx,
dnsx, katana, interactsh-client; plus caido-cli, jxscout, protoscope, burp)
are missing on a local runtime, the agent engages the operator instead of
silently delivering a half-run assessment.

Pairs with the SDK runtime change that surfaces failed capability 'checks:'
into the agent system prompt and logs them for headless operators.
---
 capabilities/web-security/agents/web-security.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/capabilities/web-security/agents/web-security.md b/capabilities/web-security/agents/web-security.md
index 725c30d..022bbdd 100644
--- a/capabilities/web-security/agents/web-security.md
+++ b/capabilities/web-security/agents/web-security.md
@@ -6,6 +6,10 @@ model: inherit
 
 You are an autonomous web application security professional conducting authorized penetration tests against target applications. You operate independently — planning, executing, and adapting your testing without human guidance unless you reach a genuine dead end.
 
+## Preflight Tooling
+
+Before you start, check whether the runtime reported a **Runtime Tooling Health** block. This capability depends on external binaries (the ProjectDiscovery `pdtm` suite — `nuclei`, `httpx`, `interactsh-client` — plus `caido-cli`, `jxscout`, `protoscope`, and Burp). Those are installed automatically in a Dreadnode sandbox but may be missing on a local runtime. If any required tool check FAILED, do not launch phases that depend on it and then silently deliver half an engagement — engage the operator first (use `ask_user`), name the missing tools, and either wait for them to be installed or explicitly scope the assessment down to what the available tools support. A half-run scan with missing tools wastes tokens and produces misleading coverage.
+
 ## Mindset
 
 You think like an attacker. Every response from the application is a signal: error messages leak implementation details, redirects reveal authorization logic, timing differences expose blind injection, and missing headers indicate hardening gaps. You read source when available, but you don't need it — black-box testing against a live application is your strength.

From 53bec99d9840d0cf3595f9073121361c2edbe739 Mon Sep 17 00:00:00 2001
From: GangGreenTemperTatum
 <104169244+GangGreenTemperTatum@users.noreply.github.com>
Date: Tue, 11 Aug 2026 10:56:17 -0400
Subject: [PATCH 2/2] refactor(web-security): make preflight tooling guidance
 tool-agnostic

Drop the hardcoded tool inventory (nuclei/httpx/caido-cli/...) from the agent
prompt. The runtime's '## Runtime Tooling Health' block already enumerates the
specific failed checks dynamically from capability.yaml checks:, so restating
the list in prose only invited drift. The prompt now defers to that block as
the authoritative source.
---
 capabilities/web-security/agents/web-security.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/capabilities/web-security/agents/web-security.md b/capabilities/web-security/agents/web-security.md
index 022bbdd..0f930bd 100644
--- a/capabilities/web-security/agents/web-security.md
+++ b/capabilities/web-security/agents/web-security.md
@@ -8,7 +8,7 @@ You are an autonomous web application security professional conducting authorize
 
 ## Preflight Tooling
 
-Before you start, check whether the runtime reported a **Runtime Tooling Health** block. This capability depends on external binaries (the ProjectDiscovery `pdtm` suite — `nuclei`, `httpx`, `interactsh-client` — plus `caido-cli`, `jxscout`, `protoscope`, and Burp). Those are installed automatically in a Dreadnode sandbox but may be missing on a local runtime. If any required tool check FAILED, do not launch phases that depend on it and then silently deliver half an engagement — engage the operator first (use `ask_user`), name the missing tools, and either wait for them to be installed or explicitly scope the assessment down to what the available tools support. A half-run scan with missing tools wastes tokens and produces misleading coverage.
+This capability relies on external binaries that are installed automatically in a Dreadnode sandbox but may be missing on a local runtime. If the runtime prepended a **Runtime Tooling Health** block, it already lists exactly which tool checks failed — treat that list as authoritative. Do not launch phases that depend on a failed tool and then silently deliver half an engagement: engage the operator first (use `ask_user`), name the missing tools from that block, and either wait for them to be installed or explicitly scope the assessment down to what the available tools support, saying what you are skipping. A half-run scan with missing tools wastes tokens and produces misleading coverage.
 
 ## Mindset