## TL;DR
Cross-tool correlation is meant to unite two views of the same issue on the same host; when the correlation key drops the host, a sqlmap result on one system and a nuclei result on another fuse into a fictional finding that exists nowhere. Make host, normalised the same way for every tool, a mandatory part of the correlation key, and split any existing merged finding back into its real per-host findings.

```text
agent merged sqlmap and nuclei findings from different hosts into one finding
```

## Use this when
- A finding's evidence section references two different hostnames or addresses from the authorized scope.
- The merged finding's location, such as a URL, disagrees with the host in its own title or table row.

## Not for this skill when
- Both tools genuinely reported the same host and issue. That merge is the design working.
- The two hosts are documented aliases or the same load-balanced service the client treats as one target. Then the report should say so explicitly, with the aliasing noted.

## Steps
1. Pick the suspect finding and list every evidence item with the host each item actually came from, straight from the raw tool outputs. Verify: Verify: the evidence hosts are enumerated and the mismatch is shown, not assumed.
2. Normalise host identity across tools: decide how hostname, IP, port, and scheme combine into the host key, accounting for tools that report URLs and tools that report addresses. Verify: Verify: the same real target produces the identical key from a sqlmap record and a nuclei record in a test pair.
3. Re-run correlation with the host inside the key, and split previously merged cross-host findings into separate per-host findings with their own evidence. Verify: Verify: finding counts increase by exactly the number of false merges undone, each new finding citing one host.
4. Add a render gate: a finding whose evidence hosts differ fails generation, unless it carries an explicit multi-host grouping flag with a human-written justification. Verify: Verify: a seeded cross-host merge blocks at the gate.
5. If a draft with a fused finding was delivered, issue a correction identifying the real per-host findings, since remediation owners differ by host. Verify: Verify: the correction names the affected hosts and findings.

## Variant phrasings
### cross tool correlation key missing host merged findings
The key-design phrasing.
### sqlmap nuclei evidence different hosts one finding
The symptom phrasing.
### host normalisation url vs ip pentest agent correlation
The normalisation phrasing.

Compatibility: Compatibility: any agent pipeline correlating multiple scanners; host normalisation rules must be shared across all importers.

## Why it happens
Correlation code typically keys on the issue type and a fuzzy title match, because that is what aligns across tools. Host lives in different fields per tool, a URL in one, an address in another, so a careless key treats it as noise. The fused result is dangerous fiction: it sends one host's owner another host's remediation, and can claim a critical chain that no single system exhibits.

## Edge cases / pitfalls
- Hostname and IP forms of the same target are the reverse trap, splitting one finding into two; the normalisation in step 2 must handle both directions.
- Wildcard or load-balanced targets need a deliberate grouping decision by a human, documented in the finding, not an accidental merge.
- Check historical reports from the same pipeline for the same fusion pattern after fixing the key.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_O7COV-7hZTRmQ9HkO-FShg