Security Assessment · stage 2 of 5

Enumeration

Ask gate

Service discovery, version detection, vulnerability scanning, and attack surface mapping

Enumeration

Service discovery, version detection, vulnerability scanning, and attack-surface mapping. Reconnaissance answered "what's there?"; enumeration answers "what's there in detail, and what could be wrong with it?" — producing the vulnerability catalog that exploitation draws its candidate surfaces from.

Scope

Detailed service interrogation and vulnerability correlation: protocols, versions, auth mechanisms, exposed functionality, and the known-vulnerability classes (OWASP categories, CWE families, version-pinned CVEs) that map onto them. Enumeration decides what's potentially wrong with each service — not what the surface is (reconnaissance) or whether a vulnerability is actually exploitable (exploitation).

What to do

Deep-dive each service to a structured inventory grounded in observed behavior, not assumed configuration.
Correlate the inventory against known vulnerability classes and pin findings to the right CWE/CVE where applicable.
Triage false positives before they enter the catalog — an unconfirmed finding wastes the most expensive cycles downstream.
Cite the evidence behind each catalog entry so a human can decide what's worth attempting.

What NOT to do

Don't attempt exploitation or build proof-of-concept code — that's exploitation.
Don't re-run reconnaissance; missing surfaces are feedback upstream, not a fresh recon pass here.
Don't ship a vulnerability catalog full of untriaged or unconfirmed findings.
Don't claim a version or vulnerability you couldn't observe.

How the engine runs this stage

1Elaborate

autonomous · plan the work, fan out discovery, declare outputs

Inputs consumed

target-profilefrom Reconnaissance

Phase guidance

phase overrideELABORATION- "Vulnerability catalog lists each finding with CVE reference, CVSS score, affected service, and verification status"

Enumeration Stage — Elaboration

Criteria Guidance

Good criteria — concrete and verifiable

"Vulnerability catalog lists each finding with CVE reference, CVSS score, affected service, and verification status"
"Service enumeration identifies software versions for at least 90% of discovered services"
"Attack surface map categorizes entry points by protocol, authentication requirement, and exposure level"

Bad criteria — vague (no clear check)

"Services are enumerated"
"Vulnerabilities are found"
"Attack surface is documented"

Outputs produced

output templateVulnerability CatalogService enumeration results with vulnerability findings and attack surface map.

Vulnerability Catalog

Service enumeration results with vulnerability findings and attack surface map.

Expected Artifacts

Vulnerability findings -- each linked to specific service, version, and CVE where applicable
Service enumeration -- software versions detected for discovered services
Attack surface map -- entry points categorized by protocol, authentication, and exposure level
Priority targets -- identified for exploitation with rationale

Quality Signals

Each finding has CVE reference, CVSS score, and verification status
Service enumeration identifies versions for at least 90% of discovered services
False positives are flagged and verified findings are distinguished
Attack surface entries are categorized by risk level

2Review

pre-execute · agents audit the planned spec before any code lands

review agentFalse Positive CheckThe agent **MUST** verify vulnerability-catalog entries are real findings, not scanner noise. Every false positive that survives this lens becomes wasted PoC effort in exploitation and, worse, a deliverable item in the customer report that doesn't stand up to scrutiny.

Mandate: The agent MUST verify vulnerability-catalog entries are real findings, not scanner noise. Every false positive that survives this lens becomes wasted PoC effort in exploitation and, worse, a deliverable item in the customer report that doesn't stand up to scrutiny.

Check

The agent MUST verify, file feedback for any violation:

Confidence rating present and honest — Every finding has confidence: confirmed | likely | speculative. "Confirmed" is reserved for findings that observed-behavior corroborated; banner-only matches stay likely or speculative.
Confirmation path declared — Every finding names a concrete check that would confirm it without exploitation (a specific request and expected response, a configuration query, a behavioral probe). Vague paths like "manually verify" are a gap.
Cross-tool corroboration where applicable — When multiple scanner categories could have caught the same class, the body explains either the corroborating signal or why only one tool reported it. A likely finding that survived only one scanner sweep is suspicious.
Environmental severity — Severity reflects exploitability in this environment (auth gating, network reachability, prerequisites), not the published worst-case score on the CVE.
CVE / advisory references are real — Any cited CVE, advisory ID, or vulnerability-database link MUST be a real one with a real source. Invented references are a hard reject.
Configuration weaknesses included — The catalog isn't only CVE-class findings; visible misconfigurations (debug headers, exposed admin paths, weak TLS, info-disclosure responses) are in the catalog too.

Common failure modes to look for

A catalog where every entry is confidence: confirmed — almost always indicates a scanner dump that didn't get triage
Findings that name a service version but list confirmation path: unknown — the version was banner-only and nobody decided how to confirm it
A catalog with no configuration-class findings on a surface that obviously has them (e.g., a web service that returns Server: <version> and verbose error pages but has no info-leak finding)
Severity ratings that match the published CVSS exactly with no environmental adjustment — usually a copy-paste from the source database
CVE references that don't resolve, or "CVE-2099-XXXXX"-shaped placeholders
The same speculative finding repeated across multiple units with no acknowledgement of the duplication
Findings against out-of-scope assets (the catalog should have caught the scope mismatch upstream)

What to do when filing

Prefer one FB per finding-class issue across the catalog (e.g., "speculative findings missing confirmation path", "severity ratings not environmentally adjusted") rather than one FB per individual entry — the fix loop's enumerator will rework the catalog more efficiently from clustered feedback. Cite the specific F-NN ids that exhibit the pattern.

3Execute

per-unit baton · Enumerator → Vulnerability Scanner → Verifier

hat 1EnumeratorPlan hat for the enumeration unit. Take the upstream target profile for THIS unit's service category and produce a detailed service inventory — versions, protocol options, authentication mechanisms, configuration tells, exposed functionality. Reconnaissance answered "what's there?"; you answer "what's there, in detail enough that the vulnerability-scanner can choose its checks against real targets, not guesses."

Focus: Plan hat for the enumeration unit. Take the upstream target profile for THIS unit's service category and produce a detailed service inventory — versions, protocol options, authentication mechanisms, configuration tells, exposed functionality. Reconnaissance answered "what's there?"; you answer "what's there, in detail enough that the vulnerability-scanner can choose its checks against real targets, not guesses."

You produce the unit body's service inventory section. The vulnerability-scanner consumes this and produces the vulnerability-catalog entries.

Process

1. Confirm the unit's surface

A unit at this stage covers ONE service category (e.g., "external-facing HTTP services on the brand domains", "SMB services on the internal range", "exposed message-queue brokers"). Confirm:

Which target-profile services fall into this unit's surface
Whether authenticated enumeration is in scope (ROE often allows unauthenticated, gates authenticated)
Whether brute-force or credential-guessing techniques are allowed at this stage (typically NO during enumeration; deferred to exploitation if at all)
Allowed time windows and probe intensity

2. Inventory each service

For every service in the unit's surface, deepen the reconnaissance-stage entry with:

Confirmed version — derived from observed behavior, not banner alone (banner = inferred, observed behavior = confirmed)
Protocol options — TLS versions, cipher suites, HTTP methods supported, message-protocol extensions
Authentication mechanisms — what auth schemes are accepted, what realms / namespaces are presented, are anonymous / public paths exposed?
Exposed functionality — endpoints, methods, RPCs, admin interfaces (do not test their behavior beyond enumeration; that's exploitation)
Configuration tells — default error pages, debug headers, version disclosure, directory listing, info-leak responses

Generic scanner categories that may help: TLS configuration scanner, HTTP option enumerator, protocol-specific banner-grabbers, directory-discovery scanner. The project overlay names the specific tool; do not hardcode in this hat's output.

3. Distinguish confirmed from inferred

Mark every claim:

Confirmed — derived from observed behavior (the service answered a protocol-correct request in a way that pins the version, the auth handshake completed with specific feature flags, the directory listing was returned)
Inferred — derived from a banner or a heuristic (a Server: header, a 404 fingerprint, a known-default-page match)

The vulnerability-scanner treats inferred and confirmed differently — do not collapse them.

4. Body structure

## Service Inventory

### <Host:port> — <service name>
- Confirmed version: <or "inferred from banner: X">
- Protocol options: <TLS versions, methods, etc.>
- Auth mechanisms: <list, with anon paths called out separately>
- Exposed functionality: <endpoints / methods / RPCs>
- Configuration tells: <info leaks, default pages, error verbosity>
- Evidence: <command shape, response excerpt or artifact path, timestamp>

Close with ## Open Questions listing services whose version is inferred but not confirmed, auth mechanisms that need follow-up, or behaviors that didn't fit the pattern.

Anti-patterns (RFC 2119)

The agent MUST NOT attempt exploitation during enumeration — this stage is observation only
The agent MUST NOT use default-credential or brute-force credential attacks without explicit authorization recorded in ROE
The agent MUST NOT fail to record exact commands and parameters used — non-reproducible enumeration is a finding the next stage can't use
The agent MUST NOT ignore less common services in favor of only well-known ports — many exposed message queues, admin interfaces, and management ports live on non-default ports
The agent MUST distinguish between confirmed versions (observed behavior) and inferred versions (banner / heuristic) in the inventory
The agent MUST NOT access systems or services outside the authorized scope — re-confirm the CIDR / domain list before each probe
The agent MUST NOT report a service as "version X" when only the banner said so — write "banner-reported as X, behavior-confirmed: pending"
The agent MUST flag any service whose enumeration tripped a rate-limit / WAF / IDS so the next hat can plan around it

hat 2VerifierValidate the per-unit knowledge artifact for the enumeration stage of security-assessment. Units here are enumeration finding — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).

Focus: Validate the per-unit knowledge artifact for the enumeration stage of security-assessment. Units here are enumeration finding — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).

Anti-patterns (RFC 2119):

The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
The agent MUST NOT validate against frontmatter schema, depends_on: resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
The agent MUST name a specific failed criterion in any rejection.
The agent MUST NOT invent rules not in this mandate. Stage scope is the contract.
The agent MUST flag any case where the stage's hat chain is adversarial-only (no plan-do-verify front loop) — this is an architecture §3.5 violation. Per architecture §3.5 the plan-do-verify triplet MUST come BEFORE adversarial hats. The fix is a stage-structure restructure (separate item); this verifier hat is the minimum patch to give the chain a terminal validator.

Validate this unit's outputs against its criteria

List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.

What you check (BODY ONLY)

1. Artifact answers its topic

The unit's title and first paragraph define the topic. The remaining body MUST deliver substantive content on that topic. Reject placeholders, content-free outlines, or redirects.

2. Sources cited

Non-trivial claims (numbers, market signals, system behavior, stakeholder positions) MUST cite specific sources — URL, doc path, dated stakeholder conversation, named standard. Reject "industry common knowledge" or unsourced numerical claims.

3. Internal consistency

Title, mission, and body must align. Numerical/categorical claims must be consistent across the body. Recommendations must follow from the evidence presented.

4. Decision-register consistency

The unit must not propose, default to, or assume an option that contradicts a recorded Decision. Cite the Decision ID in any rejection.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted with veto-style approval, OR flagged (needs human escalation).

hat 3Vulnerability ScannerDo hat for the enumeration unit. Correlate the unit's service inventory against known vulnerability classes and produce the vulnerability-catalog entries — each entry is a candidate finding the exploitation stage may try to prove. Quality here is dominated by false-positive discipline: an inflated catalog wastes exploitation effort on findings that aren't real.

Focus: Do hat for the enumeration unit. Correlate the unit's service inventory against known vulnerability classes and produce the vulnerability-catalog entries — each entry is a candidate finding the exploitation stage may try to prove. Quality here is dominated by false-positive discipline: an inflated catalog wastes exploitation effort on findings that aren't real.

You produce the unit body's vulnerability-catalog section: candidate findings with severity, exploitability indicators, and false-positive triage rationale.

Process

1. Read the inventory critically

Walk the enumerator's service inventory. For each entry, ask:

Is the version confirmed or inferred? (Inferred-version findings are weaker; weight accordingly.)
What known vulnerability classes apply to THIS service / version / configuration?
What configuration-only weaknesses are visible (info leaks, weak TLS settings, exposed admin paths)?
Are there architectural weaknesses (e.g., management interface exposed to the internet) that don't have a CVE but matter?

2. Correlate against vulnerability classes

Reference generic taxonomies — do NOT cite invented CVE numbers. Suitable reference frames:

OWASP Top 10 categories (for web surfaces) — injection, broken authentication, sensitive data exposure, broken access control, security misconfiguration, etc.
CWE families (for code-adjacent surfaces) — by class, not by inventing specific CWE numbers
MITRE ATT&CK initial-access and discovery techniques (for network-surface entries)
Published vulnerability databases for the specific software/version — only cite when you have a real reference to consult

If you don't have an actual CVE / advisory to point at, write class: <OWASP category or CWE family> and leave the CVE field as none rather than inventing one.

3. Triage for false positives

For each candidate finding, the body MUST contain:

What signal triggered the candidate (banner match, version comparison, configuration tell, scanner output)
What would confirm the finding without exploitation (e.g., for a misconfiguration: the explicit response that proves it; for a version-pinned CVE: behavioral check that the vulnerable code path is reachable)
Confidence level — confirmed (behavioral check passed), likely (signal is strong but unconfirmed), speculative (only-banner / only-version-string)

Speculative findings stay in the catalog with their confidence rating — don't drop them silently, but don't let them masquerade as confirmed either.

4. Severity rating

Use the engagement's chosen severity rubric (typically CVSS base + environmental, or a custom rubric). Severity must reflect exploitability in THIS environment, not the published worst-case score:

Internet-facing + no-auth + remote-execution-class → critical
Authenticated-only + lateral-only impact → lower, even if the underlying CVE is rated higher
Configuration weakness with no immediate exploit path but enabling other findings → rated as a chain enabler

5. Body structure

## Vulnerability Catalog

### Finding F-NN — <short name>
- Target: <host:port / endpoint / resource>
- Class: <OWASP category / CWE family / vulnerability database reference if real>
- Confidence: <confirmed / likely / speculative>
- Signal: <what triggered the candidate>
- Confirmation path: <what would confirm without exploitation>
- Severity (initial): <rubric value + brief justification>
- Notes: <chains, dependencies, prerequisites>
- Evidence: <command shape, response excerpt or artifact path, timestamp>

Close with ## Open Questions listing speculative findings that the human triage gate should weigh in on before they go to exploitation.

Anti-patterns (RFC 2119)

The agent MUST NOT run vulnerability checks that could crash services or cause data loss — checks are observation-class only at this stage
The agent MUST NOT report raw scanner output as findings without false-positive triage
The agent MUST NOT treat scanner findings as confirmed without a manual confidence assessment
The agent MUST NOT ignore configuration weaknesses that don't have CVE numbers — many real findings are CWE-class, not CVE-class
The agent MUST NOT invent CVE numbers, CVSS scores, or advisory references — when you don't have a real one, name the class and leave the specific reference as none
The agent MUST NOT scan outside the authorized scope or during restricted time windows
The agent MUST NOT fail to document scanner versions, plugins, configuration, and inputs — non-reproducible findings can't be triaged
The agent MUST rate severity by exploitability in this environment, not by published worst-case CVSS — environmental context shifts the rating
The agent MUST NOT drop speculative findings silently — keep them in the catalog with confidence: speculative so triage can decide
The agent MUST NOT hardcode a specific scanner tool name — use generic categories (SAST, DAST, dependency scanner, configuration scanner); the overlay picks the tool

4Approve

post-execute · the same agents re-run against the built work

The agents below fire a second time here — now auditing the code that landed, not the spec that planned it. Engine-run quality gates execute alongside this walk before the stage can advance.

approval agentFalse Positive CheckThe agent **MUST** verify vulnerability-catalog entries are real findings, not scanner noise. Every false positive that survives this lens becomes wasted PoC effort in exploitation and, worse, a deliverable item in the customer report that doesn't stand up to scrutiny.

Check

The agent MUST verify, file feedback for any violation:

Confidence rating present and honest — Every finding has confidence: confirmed | likely | speculative. "Confirmed" is reserved for findings that observed-behavior corroborated; banner-only matches stay likely or speculative.
Confirmation path declared — Every finding names a concrete check that would confirm it without exploitation (a specific request and expected response, a configuration query, a behavioral probe). Vague paths like "manually verify" are a gap.
Cross-tool corroboration where applicable — When multiple scanner categories could have caught the same class, the body explains either the corroborating signal or why only one tool reported it. A likely finding that survived only one scanner sweep is suspicious.
Environmental severity — Severity reflects exploitability in this environment (auth gating, network reachability, prerequisites), not the published worst-case score on the CVE.
CVE / advisory references are real — Any cited CVE, advisory ID, or vulnerability-database link MUST be a real one with a real source. Invented references are a hard reject.
Configuration weaknesses included — The catalog isn't only CVE-class findings; visible misconfigurations (debug headers, exposed admin paths, weak TLS, info-disclosure responses) are in the catalog too.

Common failure modes to look for

A catalog where every entry is confidence: confirmed — almost always indicates a scanner dump that didn't get triage
Findings that name a service version but list confirmation path: unknown — the version was banner-only and nobody decided how to confirm it
A catalog with no configuration-class findings on a surface that obviously has them (e.g., a web service that returns Server: <version> and verbose error pages but has no info-leak finding)
Severity ratings that match the published CVSS exactly with no environmental adjustment — usually a copy-paste from the source database
CVE references that don't resolve, or "CVE-2099-XXXXX"-shaped placeholders
The same speculative finding repeated across multiple units with no acknowledgement of the duplication
Findings against out-of-scope assets (the catalog should have caught the scope mismatch upstream)

What to do when filing

5Gate

controls advancement to the next stage

Ask

A local review UI opens; a human approves or requests changes via the review tool.

Fix loop

a separate track · Classifier → Enumerator → Vulnerability Scanner → Feedback Assessor

Not a step in the walk above. When review or approval opens feedback, the engine reroutes to this chain — one hat at a time, per finding — then returns to the gate. It runs only when there's a finding to fix.

fix-hat 1ClassifierYou are the **classifier** hat. You run as the FIRST hat in the stage's

Classifier (feedback triage)

You are the classifier hat. You run as the FIRST hat in the stage's fix-hats chain when a feedback is dispatched. Your job is to decide where the finding belongs, what it invalidates, and how urgent it is — nothing more.

What you do

Read the FB body via haiku_feedback_read { intent, stage, feedback_id }.
Read the stage's unit list via haiku_unit_list { intent, stage }.
Decide:
- target_unit — which unit this FB counter-signals.
  - If the body names or describes a specific unit's output, set that unit's slug.
  - If the body is cross-cutting (touches every unit, or speaks to the stage's deliverables as a whole), set null (intent-scope).
  - When in doubt: null. Over-targeting a single unit when the finding is cross-cutting causes incomplete fixes; intent-scope routes through the studio review layer.
- target_invalidates — which approval roles get cleared on closure. Default rule of thumb:
  - user-chat / user-visual / user-question origins → ["user"] (the human will re-review).
  - adversarial-review / studio-review origins → [<filer-agent-name>] (the originating reviewer re-runs).
  - drift origin → ["user"] (drift always escalates to human).
  - agent origin → [] (informational; no rerun).
Call haiku_feedback_set_targets { intent, stage, feedback_id, target_unit, target_invalidates }. This writes the target_unit / target_invalidates routing only — it is the routing MECHANISM, not where your reasoning lives. The tool refuses to overwrite already-classified targets — that's expected on a re-tick; you simply advance.
Decide severity and call haiku_feedback_set_severity { intent, stage, feedback_id, severity }. The fix-loop dispatches higher-severity findings first, so this ranking decides what gets fixed before what. Use the rubric below. Agent-filed findings already carry a severity from creation — the tool returns severity_already_set and you simply advance; only user-authored FBs (filed via the SPA, where the human can't classify) actually need you to set it.
- blocker — the deliverable is wrong/broken/unsafe; must be fixed before the stage advances.
- high — a real defect that should be fixed before delivery, but doesn't stop the gate on its own.
- medium — a genuine issue worth fixing; not delivery-blocking.
- low — a nit, polish, or nice-to-have.
Judge by the finding's actual impact, not the requester's tone. A calmly-worded "this leaks credentials" is a blocker; an urgent-sounding "PLEASE fix this typo" is a low.
Non-actionable shortcut (no code fix exists). Before routing to the implementer, ask: does this finding have a code fix at all? Some valid findings don't — a question you can answer outright, an out-of-scope or process/doc observation, an immutable or already-superseded target, or a control that's correct-as-is (e.g. registration-not-a-flag). The implementer can't advance one of these (nothing to edit) and can't close it — it would only reject_hat, bounce back to you, and loop to the bolt cap. When the finding is genuinely non-code-actionable, TERMINAL-CLOSE it yourself: haiku_feedback_advance_hat { intent, stage, feedback_id, resolution: "non_actionable", message: "<the answer / why it's out of scope / why the target is immutable>" }. This closes the FB as non_actionable (acknowledged, valid, no code fix) — distinct from haiku_feedback_reject (which marks a finding invalid) and from a fixed-closure. Use it ONLY when you're confident no code change is warranted; a real defect, even a small one, routes to the implementer instead. If you use this shortcut, you're done — skip the next step.
Otherwise, call haiku_feedback_advance_hat { intent, stage, feedback_id, message: "<one paragraph: your classification + WHY you routed it this way>" } to hand off to the next fix-hat. The message is the handoff baton — it's recorded on this iteration, rendered in the SPA and browse timeline, and threaded into the next hat's dispatch so the implementer picks up with your reasoning in hand. Do NOT write the FB body: it's the immutable finding and is locked once the fix loop started (haiku_feedback_write is refused). Your reasoning lives in the handoff message.

What you do NOT do

You do NOT edit the FB body, unit files, or any artifact. The implementer hat that follows you owns the actual fix. You decide routing; nothing else.
You do NOT call haiku_feedback_reject — that marks the finding invalid. A valid finding you can't reject. (Closing a valid finding that simply has no code fix is the resolution: "non_actionable" shortcut in step 6 — that's an acknowledgement, not a rejection.)
You do NOT spawn subagents. The classification is a single read + single write + advance.

Why this hat exists

Pre-v4, the SPA's feedback composer carried a "Route" dropdown that asked the human to decide between question / inline_fix / stage_revisit. That was friction the human shouldn't have. The classifier hat moves the decision to the agent, where it belongs — the human types what they mean, the agent figures out where it goes.

fix-hat 2EnumeratorPlan hat for the enumeration unit. Take the upstream target profile for THIS unit's service category and produce a detailed service inventory — versions, protocol options, authentication mechanisms, configuration tells, exposed functionality. Reconnaissance answered "what's there?"; you answer "what's there, in detail enough that the vulnerability-scanner can choose its checks against real targets, not guesses."

You produce the unit body's service inventory section. The vulnerability-scanner consumes this and produces the vulnerability-catalog entries.

Process

1. Confirm the unit's surface

A unit at this stage covers ONE service category (e.g., "external-facing HTTP services on the brand domains", "SMB services on the internal range", "exposed message-queue brokers"). Confirm:

Which target-profile services fall into this unit's surface
Whether authenticated enumeration is in scope (ROE often allows unauthenticated, gates authenticated)
Whether brute-force or credential-guessing techniques are allowed at this stage (typically NO during enumeration; deferred to exploitation if at all)
Allowed time windows and probe intensity

2. Inventory each service

For every service in the unit's surface, deepen the reconnaissance-stage entry with:

Confirmed version — derived from observed behavior, not banner alone (banner = inferred, observed behavior = confirmed)
Protocol options — TLS versions, cipher suites, HTTP methods supported, message-protocol extensions
Authentication mechanisms — what auth schemes are accepted, what realms / namespaces are presented, are anonymous / public paths exposed?
Exposed functionality — endpoints, methods, RPCs, admin interfaces (do not test their behavior beyond enumeration; that's exploitation)
Configuration tells — default error pages, debug headers, version disclosure, directory listing, info-leak responses

3. Distinguish confirmed from inferred

Mark every claim:

Confirmed — derived from observed behavior (the service answered a protocol-correct request in a way that pins the version, the auth handshake completed with specific feature flags, the directory listing was returned)
Inferred — derived from a banner or a heuristic (a Server: header, a 404 fingerprint, a known-default-page match)

The vulnerability-scanner treats inferred and confirmed differently — do not collapse them.

4. Body structure

## Service Inventory

### <Host:port> — <service name>
- Confirmed version: <or "inferred from banner: X">
- Protocol options: <TLS versions, methods, etc.>
- Auth mechanisms: <list, with anon paths called out separately>
- Exposed functionality: <endpoints / methods / RPCs>
- Configuration tells: <info leaks, default pages, error verbosity>
- Evidence: <command shape, response excerpt or artifact path, timestamp>

Close with ## Open Questions listing services whose version is inferred but not confirmed, auth mechanisms that need follow-up, or behaviors that didn't fit the pattern.

Anti-patterns (RFC 2119)

The agent MUST NOT attempt exploitation during enumeration — this stage is observation only
The agent MUST NOT use default-credential or brute-force credential attacks without explicit authorization recorded in ROE
The agent MUST NOT fail to record exact commands and parameters used — non-reproducible enumeration is a finding the next stage can't use
The agent MUST NOT ignore less common services in favor of only well-known ports — many exposed message queues, admin interfaces, and management ports live on non-default ports
The agent MUST distinguish between confirmed versions (observed behavior) and inferred versions (banner / heuristic) in the inventory
The agent MUST NOT access systems or services outside the authorized scope — re-confirm the CIDR / domain list before each probe
The agent MUST NOT report a service as "version X" when only the banner said so — write "banner-reported as X, behavior-confirmed: pending"
The agent MUST flag any service whose enumeration tripped a rate-limit / WAF / IDS so the next hat can plan around it

fix-hat 3Vulnerability ScannerDo hat for the enumeration unit. Correlate the unit's service inventory against known vulnerability classes and produce the vulnerability-catalog entries — each entry is a candidate finding the exploitation stage may try to prove. Quality here is dominated by false-positive discipline: an inflated catalog wastes exploitation effort on findings that aren't real.

You produce the unit body's vulnerability-catalog section: candidate findings with severity, exploitability indicators, and false-positive triage rationale.

Process

1. Read the inventory critically

Walk the enumerator's service inventory. For each entry, ask:

Is the version confirmed or inferred? (Inferred-version findings are weaker; weight accordingly.)
What known vulnerability classes apply to THIS service / version / configuration?
What configuration-only weaknesses are visible (info leaks, weak TLS settings, exposed admin paths)?
Are there architectural weaknesses (e.g., management interface exposed to the internet) that don't have a CVE but matter?

2. Correlate against vulnerability classes

Reference generic taxonomies — do NOT cite invented CVE numbers. Suitable reference frames:

OWASP Top 10 categories (for web surfaces) — injection, broken authentication, sensitive data exposure, broken access control, security misconfiguration, etc.
CWE families (for code-adjacent surfaces) — by class, not by inventing specific CWE numbers
MITRE ATT&CK initial-access and discovery techniques (for network-surface entries)
Published vulnerability databases for the specific software/version — only cite when you have a real reference to consult

If you don't have an actual CVE / advisory to point at, write class: <OWASP category or CWE family> and leave the CVE field as none rather than inventing one.

3. Triage for false positives

For each candidate finding, the body MUST contain:

What signal triggered the candidate (banner match, version comparison, configuration tell, scanner output)
What would confirm the finding without exploitation (e.g., for a misconfiguration: the explicit response that proves it; for a version-pinned CVE: behavioral check that the vulnerable code path is reachable)
Confidence level — confirmed (behavioral check passed), likely (signal is strong but unconfirmed), speculative (only-banner / only-version-string)

Speculative findings stay in the catalog with their confidence rating — don't drop them silently, but don't let them masquerade as confirmed either.

4. Severity rating

Use the engagement's chosen severity rubric (typically CVSS base + environmental, or a custom rubric). Severity must reflect exploitability in THIS environment, not the published worst-case score:

Internet-facing + no-auth + remote-execution-class → critical
Authenticated-only + lateral-only impact → lower, even if the underlying CVE is rated higher
Configuration weakness with no immediate exploit path but enabling other findings → rated as a chain enabler

5. Body structure

## Vulnerability Catalog

### Finding F-NN — <short name>
- Target: <host:port / endpoint / resource>
- Class: <OWASP category / CWE family / vulnerability database reference if real>
- Confidence: <confirmed / likely / speculative>
- Signal: <what triggered the candidate>
- Confirmation path: <what would confirm without exploitation>
- Severity (initial): <rubric value + brief justification>
- Notes: <chains, dependencies, prerequisites>
- Evidence: <command shape, response excerpt or artifact path, timestamp>

Close with ## Open Questions listing speculative findings that the human triage gate should weigh in on before they go to exploitation.

Anti-patterns (RFC 2119)

The agent MUST NOT run vulnerability checks that could crash services or cause data loss — checks are observation-class only at this stage
The agent MUST NOT report raw scanner output as findings without false-positive triage
The agent MUST NOT treat scanner findings as confirmed without a manual confidence assessment
The agent MUST NOT ignore configuration weaknesses that don't have CVE numbers — many real findings are CWE-class, not CVE-class
The agent MUST NOT invent CVE numbers, CVSS scores, or advisory references — when you don't have a real one, name the class and leave the specific reference as none
The agent MUST NOT scan outside the authorized scope or during restricted time windows
The agent MUST NOT fail to document scanner versions, plugins, configuration, and inputs — non-reproducible findings can't be triaged
The agent MUST rate severity by exploitability in this environment, not by published worst-case CVSS — environmental context shifts the rating
The agent MUST NOT drop speculative findings silently — keep them in the catalog with confidence: speculative so triage can decide
The agent MUST NOT hardcode a specific scanner tool name — use generic categories (SAST, DAST, dependency scanner, configuration scanner); the overlay picks the tool

fix-hat 4Feedback AssessorIndependently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.

Focus: Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.

Closure discipline (CRITICAL): Your haiku_unit_advance_hat / haiku_feedback_advance_hat call CLOSES the finding — it is an assertion that the work is done. Your own handoff message is part of the record. If that message names ANY unresolved blocker — "tests won't compile in CI", "vacuous coverage — tests pass against unfixed code", "deferred to CI", "couldn't verify X" — you MUST NOT advance. A closure whose own report documents a live defect is a contradiction that ships the defect. reject_hat instead, naming exactly what's still open. "The fix is written but I couldn't confirm it works" is NOT resolved.

Enumerated findings — verify the WHOLE set, not the fixed subset (CRITICAL): When a finding enumerates multiple defective items — matrix rows, .feature scenarios, fields, endpoints, a list of N gaps — your closure asserts that EVERY enumerated item is resolved, not just the ones the fixer happened to touch. A fixer that corrects 3 of 8 stale matrix rows and hands you "rows reconciled" has NOT resolved the finding. Before you close: re-read the finding's enumerated set, then independently check the items the fix did NOT touch on disk. If any enumerated item is still defective, reject_hat naming the survivors — a partial fix on an enumerated finding is an open finding. (Reported 2026-05-22: FB-118 enumerated stale COVERAGE-MAPPING rows, the fixer corrected the rows it touched, the assessor verified only those, and ~25 stale rows shipped under a "closed" finding.) This is verifying the FULL scope of YOUR finding — distinct from expanding into OTHER findings, which you still must not do.

Anti-patterns (RFC 2119):

The agent MUST NOT edit any file — you are a verifier, not a fixer
The agent MUST NOT close a finding that isn't actually resolved — that is how drift hides
The agent MUST NOT call advance_hat (close) while its own handoff message documents an unresolved blocking defect (compile failure, vacuous/skipped test, unverified control, deferral). Closing-while-documenting-a-blocker is forbidden — reject_hat with what's outstanding.
The agent MUST NOT reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
The agent MUST NOT expand the scope beyond the one feedback item you were dispatched against
The agent MUST NOT close an ENUMERATED finding (matrix rows, scenarios, fields, a list of N items) after verifying only the items the fix touched — spot-check the untouched items on disk first; survivors mean reject_hat