nsauditor-ai-agent-skill 0.2.54 → 0.2.55

package/README.md

@@ -13,7 +13,9 @@ Works with **Claude Code**, **Claude Desktop**, **Cursor**, **Windsurf**, **VS C
 
 ## Current release
 
-**0.2.54** (2026-10-04) — paired with **Enterprise 1.2.0 / Community 0.2.56**. ⚠️ **A floor bump: requires Community >= 0.2.56** (it was >= 0.2.55 — Enterprise 1.2.0 imports names that first ship in Community 0.2.56; below it Enterprise's plugins load, but the scan skips its intelligence, analysis-agent and compliance stages without a word). New in this release's teaching: the not-comparable bucket also catches a UDP port that did not answer, a CVE lookup that failed, an analysis agent that did not run, and a CVE the vulnerability data stopped attributing while the same program and version still answered; a compliance control can FAIL on a finding the prior scan recorded when this scan did not measure the port or probe it was on, cover its region, or run what produced it — a `<prior title> — [COVERAGE GAP] …` record, never a current finding; how a failed Enterprise load surfaces from Community 0.2.56; and two measured limits — after a CVE lookup that failed, the control its CVE rows failed can still read PASS; and when a later scan left out a plugin the earlier one requested, a row an analysis agent or the CVE mapper derived from it can read fixed, and its control PASS; when the earlier scan left the plugin out instead, such a row can read NEW. Keep `--plugins` identical between compared scans. Plugin counts and all eight coverage matrices are unchanged since Enterprise 1.1.0. The 0.2.53 teaching is carried forward.
+**0.2.55** (2026-10-07) — paired with **Enterprise 1.3.0 / Community 0.2.57**. ⚠️ **A floor bump: requires Community >= 0.2.57** (it was >= 0.2.56 — Enterprise 1.3.0 imports names that first ship in Community 0.2.57; below it Enterprise's core does not load while its plugins still do — on Community 0.2.56 as on 0.2.55 — so the scan skips its intelligence, analysis-agent and compliance stages: Community 0.2.56 names that on stderr, and 0.2.55 or older says nothing, the shape measured for Enterprise 1.2.0 and 1.3.0). New in this release's teaching: the not-comparable bucket also catches a CVE-mapper or service-agent row on a TCP port whose service the other run could not identify, and an analysis agent's or the CVE mapper's row when a plugin it reads was left out of a scan; after a CVE lookup that failed, the controls the prior CVE rows failed are now held failed; the exposure and service agents' titles moved, so their rows read `identity-basis-changed` across the upgrade; the DNS-posture audit (060) declines an IP-address target; the TLS certificate audit (040) grades an IP target's DNS-only name mismatch LOW and reads IP SANs; and two measured limits — a scan made before Enterprise 1.3.0 could not record a plugin left out of it, so in a comparison with one an agent's row that scan lacks is not refused; and a scan that discovered ports with the Nmap plugin (024) alone records no port oracle, so an analysis agent's or the CVE mapper's row on a port it did not measure can read RESOLVED and count as closed in MTTR, and the control it failed can read PASS — include the port scanner (003). See [CHANGELOG.md](https://github.com/nsasoft/nsauditor-ai-agent-skill/blob/main/CHANGELOG.md).
+
+**Prior: 0.2.54** (2026-10-04) — paired with **Enterprise 1.2.0 / Community 0.2.56**. ⚠️ **A floor bump: requires Community >= 0.2.56** (Enterprise 1.2.0 imports names that first ship in Community 0.2.56). Its teaching — the not-comparable cases, the compliance hold on a prior finding, how a failed Enterprise load surfaces — is carried forward above; of its two measured limits, 0.2.55 teaches the first closed and the second narrowed.
 
 **Prior: 0.2.53** — paired with **Enterprise 1.1.0 / Community 0.2.55**. ⚠️ **A floor bump: requires Community >= 0.2.55** (it was >= 0.2.49 — Enterprise 1.1.0 calls code that first ships in Community 0.2.55). The skill now INSTALLS itself: `npx nsauditor-ai-agent-skill install` copies it into `~/.claude/skills/` for Claude Code, and `npx nsauditor-ai-agent-skill build-zip --out ~/Desktop` builds the Claude Desktop upload zip. Claude Code users can instead add it as a plugin marketplace — `/plugin marketplace add nsasoft/nsauditor-ai-agent-skill`. ⚠️ A marketplace reaches **Claude Code only**; Claude Desktop accepts skills only as an uploaded zip, and skills do not sync between surfaces. Knowledge updated for the Pro cross-run delta (`report --since`) that ships in Community 0.2.55.
 
@@ -199,7 +201,7 @@ This package provides **knowledge about** NSAuditor AI. To actually **run** scan
      }
    }
    ```
-   `NSA_ALLOW_ALL_HOSTS: "1"` lets Claude scan your own network — private addresses such as `192.168.x.x` or `10.x.x.x` — because it turns off the MCP server's check of the address a host name resolves to. The server still refuses a host written as `localhost`, `127.x.x.x`, `::1`, `169.254.x.x` or `metadata.google.internal`, but no longer a name that resolves to a loopback or cloud-metadata address, or a spelling such as `::ffff:127.0.0.1`. `install-key` does not print it, so add it yourself, and remove it if you only scan public hosts.
+   `NSA_ALLOW_ALL_HOSTS: "1"` lets Claude scan your own network — private addresses such as `192.168.x.x` or `10.x.x.x`. It admits private ranges only (RFC 1918, CGNAT `100.64/10`, `fc00::/7`): the server still refuses loopback, link-local and cloud-metadata addresses in any spelling, whether written as the host or returned for a host name — every answer is checked. Only `1`, `true`, `yes` or `on` turn it on. The check does not pin the answer, so a name whose answer changes between the check and the scan (DNS rebinding) is not caught. `install-key` does not print it, so add it yourself, and remove it if you only scan public hosts.
 
 > ⚠️ **`NSA_MCP_AUTH_KEY` is REQUIRED — the server refuses to start without it.** Generate one with
 > `nsauditor-ai mcp install-key`, then put the SAME value in the `env` block above. Without it the MCP

package/SKILL.md

@@ -15,7 +15,9 @@ description: >
 
 # NSAuditor AI — Agent Skill
 
-> **Version:** <!-- nsa:derived id="skill-version" -->0.2.54<!-- /nsa:derived --> (knowledge current as of **EE <!-- nsa:derived id="ee-version" -->1.2.0<!-- /nsa:derived -->** · **requires CE ≥ <!-- nsa:derived id="ce-floor" -->0.2.56<!-- /nsa:derived -->**) — **1.2.0: A finding on a port, region or producer a scan did not measure is not counted as fixed, and with SLA tracking on the control it failed is held FAILED. Two measured limits in this release: after a CVE lookup that failed, the prior CVE rows are not counted as fixed, but the controls they failed are not held FAILED and can read PASS; and when two compared scans ran different `--plugins` sets, a row an analysis agent or the CVE mapper derived from a plugin only one of them requested can read RESOLVED or NEW. When the later scan left the plugin out, the row also counts as closed in MTTR and its control can read PASS. Keep `--plugins` identical between compared scans.** Teach these first, and never report a row in either limit as fixed, or its control as passing. (a) **The NOT-COMPARABLE bucket catches four more cases.** A UDP-transport finding whose port did not answer in the other run (for a CVE row, also one that answered without identifying its service) is `port-not-measured`, listed with a `/udp` suffix; a CVE row whose LOOKUP failed in the other run is `evidence-gap` — the mapper's own `[COVERAGE GAP] <gapClass> — <protocol>/<service>` record is a coverage gap that opened or cleared, never an exposure; and a finding of an analysis agent that DID NOT RUN (`[COVERAGE GAP] AGENT NOT RUN — <agent> did not run: <cause class>`) is `evidence-gap`, while that agent's controls fail closed in every framework; and a CVE row that VANISHED — present in the baseline, absent now — while the SAME program and version answered on its port in both runs is `vulnerability-data-changed` — the mapper attributes on program and version alone, so the vulnerability data moved (NVD's answer, a cached answer's age, an offline store), not the estate: never present it as a fix, and in MTTR it is not a closed finding. Neither the delta's rule nor MTTR's reaches a port that answers with two different identified programs or versions, and MTTR's does not reach a prior row that recorded no program or version. A CVE that APPEARED on an unchanged service stays NEW with the basis note "the service is unchanged, the vulnerability data is not" — new knowledge about an old service, not a new exposure on the estate. Every detail names its run absolutely: "this run" is the current one, "the baseline run" the earlier. (b) **A compliance control can FAIL on a finding the PRIOR scan recorded.** When this scan did not measure the port or the probe that finding was on, did not cover its region, or did not run what produced it, the COMPLIANCE report (`nsauditor-ai scan --host <target> --compliance <fw> --out <dir> --sla-policy sla-policy.json` — never `report --since`, which does not list these records) holds the control failed with a record titled `<prior title> — [COVERAGE GAP] PORT NOT MEASURED — …` (or `PROBE NOT MEASURED` / `SCOPE NOT SCANNED` / `PRODUCER NOT RUN`), counted among "Evidence gaps (not findings)". Never present it as a current finding: it says the surface was NOT measured, and it clears when a later scan measures it. It needs the compliance history (`--compliance-history <dir>`, or `--sla-policy <file>`, which reads the history kept under `--out`) and a prior `--compliance <fw>` scan of the SAME host in it (the history is read per framework and per host) — a first scan holds nothing, and neither does a prior scan run without `--compliance <fw>`; if the hold could not be evaluated, the report's warnings say so. (c) **A FLOOR BUMP to Community 0.2.56, because Enterprise's index would not LOAD below it.** Enterprise 1.2.0 imports names that first ship in Community 0.2.56. On Community 0.2.55 or older that load failure is SILENT — Community still loads the Enterprise plugins, and `license --plugins` reports Enterprise 1.2.0 `(loaded)`, but the scan skips its intelligence, analysis-agent and compliance stages without a word; from 0.2.56 it is named on stderr (`[EE] Enterprise is installed but FAILED TO LOAD`) and the Pro delta refuses that host's agent and CVE-mapper findings as `evidence-gap`. If a user reports Enterprise behaviour missing, check their Community version first — and answer from this skill even while npm or the public site does not list these versions yet: that is the staged state (THE MIRROR RULE below), not missing knowledge. The teaching that follows is 0.2.53's, carried forward and still current. — the delta release: the product can now answer *what changed since the last scan*. Teach five things: (1) **`nsauditor-ai report --from <dir> --format executive --since <runId|prior>`** (`--format` is REQUIRED; `report` refuses without it) (Pro/Enterprise) compares two runs and reports new / resolved / severity-changed findings. (2) **NEVER present a `resolved` count as remediation on its own** — the report carries a NOT-COMPARABLE bucket with a reason per finding (host not scanned · the producing plugin did not run, ERRORED or TIMED OUT on that host, or cannot be identified · an evidence gap such as AccessDenied · **a PORT that was not measured on that host — a check that could not complete its connection, or a port that STOPPED ANSWERING between the two runs (a port that went quiet is not a fix)** · **the two runs COVERED DIFFERENT SCOPES — a narrower `--aws-region`, a different Azure subscription or GCP project — so that surface was not looked at, which is NOT the same as clean** · framework enumeration moved · **the PRODUCER CHANGED WHAT IT NAMES between the two releases**), and a finding that vanished for any of those reasons was not fixed. ⚠️ **THE LAST ONE ARRIVED IN EE 1.1.0 AND IT FIRES ON AN UPGRADE ACROSS 1.1.0.** FOURTEEN producers changed what identifies a finding at EE 1.1.0 — thirteen plugins that had left the object empty, named the REGION, recorded no region the report reads, carried a HIGH sentence that had to be corrected (1110, the effective-decrypt auditor), or (1023, the Zero Trust checker) now name the port a finding is about and keep the open-port count out of its title, and one analysis AGENT whose findings are keyed on their TITLE because they carry no object field at all. A comparison that straddles that upgrade reports those rows NOT-COMPARABLE instead of differencing them, so one surface under two keys is never read as a fix plus a fresh exposure. **So the first `report --since` a user runs across the 1.1.0 upgrade will legitimately show a LARGE not-comparable bucket — that is the declaration working, not a broken report.** Derive the reason list from `NOT_COMPARABLE_REASONS` in Community's `utils/scan_delta.mjs` rather than from this sentence; it is held in equality with what the engine emits, and this sentence is prose that has disagreed with it before. If a user asks what got fixed, read the NOT-COMPARABLE list before answering. **Two conditions refuse the whole comparison rather than bucketing findings**: the two runs straddle a product boundary where a reported number changed meaning, and the two runs ran at DIFFERENT LICENCE TIERS — the set of producers that ran differs, so a whole producer's findings would read as remediation. ⚠️ **AND ONE OF THOSE REASONS IS DECLARED RATHER THAN CHECKED: framework-enumeration movement is NOT EVALUATED in this edition**, because a run record carries no framework enumeration. The report says so as a limit on every comparison and each row's basis reads `framework enumeration: not evaluated`. Never tell a user that framework movement was ruled out. (3) **Integrity is a hash chain, not a signature — and say WHAT is sealed.** At finalize the run record AND each written host's findings files are digested over their exact persisted bytes, with the per-file digests sealed inside the record, which is itself digested and chained through `prevDigest`. So an altered **findings file** — which is what the comparison actually reads — is detected and NAMED, not merely an altered index; a file that did not exist at seal time is sealed as an explicit absence, so adding one is detected too. **BOTH runs are verified, not only the baseline.** An altered or unmeasurable run on either side REFUSES the comparison outright, and the refusal names which side. A file that cannot be READ is reported as unmeasurable rather than as tampering, and a record written before per-host sealing keeps its verdict while its reason says the findings files were not covered. The guarantee is tamper-EVIDENT against corruption and unsophisticated edits, **NOT tamper-proof against host-level access and NOT non-repudiation**. Do not describe it as file-integrity monitoring or a change-detection mechanism: PCI DSS `11.5.1` / `11.5.2` / `11.6.1` are enumerated OUT OF SCOPE in the shipped matrix. The code ships in Community; the capability is licence-gated to Pro/Enterprise. ⚠️ **`--since` REQUIRES COMMUNITY 0.2.55 OR LATER — AND ENTERPRISE 1.2.0 REQUIRES 0.2.56 (item (c) above): on 0.2.55 Enterprise 1.2.0's plugins load, but the scan skips its intelligence, analysis-agent and compliance stages without a word.** The peer floor moved to 0.2.55 at EE 1.1.0 because **Enterprise CALLS the new Community code** — the per-plugin run statuses the Zero Trust checker reads before it will assert a posture, and the run-record fields `report --since` compares. The earlier floor said otherwise on the grounds that Enterprise did not call it; that stopped being true at EE 1.1.0. If a user reports the flag is unrecognised, check their Community version first. (4) **A `kms:Decrypt on Resource:*` HIGH from 1110 is NEVER downgraded on a live run.** 1110 reads KMS key policies and grants in the configured region only, and one region cannot show that NO key trusts a principal — a key in another region may — so the HIGH→INFO downgrade it used to apply is withheld on every shipped path. The reason is in that plugin's run summary as `summary.kmsDowngrade` (`reason` `single-region-enumeration` for a complete read; `access-denied` · `per-key-error` · `keys-truncated` · `grants-truncated` for an incomplete one, which also emits an evidence-gap row). Never tell a user a surviving HIGH was checked against every key, and never read a missing downgrade as a scanner fault. Its grant finding (`kms-grant-decrypt-no-identity-grant`, MEDIUM) likewise covers keys in the configured region only. (5) **The NVD store and response cache MOVED at EE 1.1.0 and every run records where they are.** They used to be a `.nvd-cache` folder in whatever directory the scan started from; they now resolve, from any directory, to `NVD_CACHE_DIR`, else `NSAUDITOR_NVD_CACHE_DIR`, else `~/.nsauditor/nvd_cache`. Only `feed import` (of a feed you downloaded yourself) takes `--cache-dir`; a scan does not read that flag, so it reads a store imported with `--cache-dir <d>` only when that chain resolves to `<d>` (e.g. `NVD_CACHE_DIR=<d>`). The MCP `get_vulnerabilities` cache reads `NSAUDITOR_NVD_CACHE_DIR`, never `NVD_CACHE_DIR`. An old `.nvd-cache` folder is NOT read, and the scan says so. If a user reports that offline CVE matching stopped after upgrading, that is the cause: move the folder once or set `NVD_CACHE_DIR` to it. Never read the resulting coverage gaps as a clean host. Plugin count UNCHANGED at <!-- nsa:derived id="plugins:ee" -->29<!-- /nsa:derived -->; <!-- nsa:derived id="matrix-movement" -->all eight coverage matrices unchanged since EE 1.1.0<!-- /nsa:derived -->; Community <!-- nsa:derived id="ce-version" -->0.2.56<!-- /nsa:derived --> (published with this skill).
+> **Version:** <!-- nsa:derived id="skill-version" -->0.2.55<!-- /nsa:derived --> (knowledge current as of **EE <!-- nsa:derived id="ee-version" -->1.3.0<!-- /nsa:derived -->** · **requires CE ≥ <!-- nsa:derived id="ce-floor" -->0.2.57<!-- /nsa:derived -->**) — **1.3.0: A finding on a port, region or producer a scan did not measure is not counted as fixed, and with SLA tracking on the control it failed is held FAILED — including the prior CVE rows on a service whose lookup failed, the CVE mapper's and the service agent's rows on a TCP port whose service the scan could not identify, and an analysis agent's or the CVE mapper's rows when a plugin they read was left out of the scan or did not complete. Two measured limits: a scan made before EE 1.3.0 could not record a plugin left out of it, so in a comparison with one, an agent's row that scan lacks is not refused — the report's Basis cell says so on the row; and a scan that discovered ports with the Nmap plugin (024) alone records no port oracle, so an analysis agent's or the CVE mapper's row on a port it did not measure can read RESOLVED and count as closed in MTTR, and the control it failed can read PASS — include the port scanner (003).** Teach these first, and never report a row in either limit as fixed, or its control as passing. (a) **The NOT-COMPARABLE bucket catches four more cases.** A UDP-transport finding whose port did not answer in the other run (for a CVE row, also one that answered without identifying its service) is `port-not-measured`, listed with a `/udp` suffix; a CVE row whose LOOKUP failed in the other run is `evidence-gap` — the mapper's own `[COVERAGE GAP] <gapClass> — <protocol>/<service>` record is a coverage gap that opened or cleared, never an exposure; and a finding of an analysis agent that DID NOT RUN (`[COVERAGE GAP] AGENT NOT RUN — <agent> did not run: <cause class>`) is `evidence-gap`, while that agent's controls fail closed in every framework; and a CVE row that VANISHED — present in the baseline, absent now — while the SAME program and version answered on its port in both runs is `vulnerability-data-changed` — the mapper attributes on program and version alone, so the vulnerability data moved (NVD's answer, a cached answer's age, an offline store), not the estate: never present it as a fix, and in MTTR it is not a closed finding. Neither the delta's rule nor MTTR's reaches a port that answers with two different identified programs or versions, and MTTR's does not reach a prior row that recorded no program or version. A CVE that APPEARED on an unchanged service stays NEW with the basis note "the service is unchanged, the vulnerability data is not" — new knowledge about an old service, not a new exposure on the estate. Every detail names its run absolutely: "this run" is the current one, "the baseline run" the earlier. (b) **A compliance control can FAIL on a finding the PRIOR scan recorded.** When this scan did not measure the port or the probe that finding was on, did not cover its region, did not run what produced it, or (for a CVE row) could not complete its CVE lookup, the COMPLIANCE report (`nsauditor-ai scan --host <target> --compliance <fw> --out <dir> --sla-policy sla-policy.json` — never `report --since`, which does not list these records) holds the control failed with a record titled `<prior title> — [COVERAGE GAP] PORT NOT MEASURED — …` (or `PROBE NOT MEASURED` / `SCOPE NOT SCANNED` / `PRODUCER NOT RUN` / `LOOKUP NOT MEASURED`), counted among "Evidence gaps (not findings)". Never present it as a current finding: it says the surface was NOT measured, and it clears when a later scan measures it. It needs the compliance history (`--compliance-history <dir>`, or `--sla-policy <file>`, which reads the history kept under `--out`) and a prior `--compliance <fw>` scan of the SAME host in it (the history is read per framework and per host) — a first scan holds nothing, and neither does a prior scan run without `--compliance <fw>`; if the hold could not be evaluated, the report's warnings say so. (c) **A FLOOR BUMP to Community 0.2.57.** Enterprise 1.3.0 imports names that first ship in Community 0.2.57 (`tcpServiceMeasurement`, `IDENTIFYING_PRODUCERS`) and reads its identity-basis declarations by value. Below it Enterprise's core does not load while its plugins still do — on Community 0.2.56 as on 0.2.55, `license --plugins` lists all 29 and a scan selects them (measured) — so the scan skips its intelligence, analysis-agent and compliance stages: on Community 0.2.56 that is named on stderr (`[EE] Enterprise is installed but FAILED TO LOAD`) and recorded on the scan's conclusion, and the Pro delta refuses that host's agent and CVE-mapper findings as `evidence-gap`; on 0.2.55 or older it is SILENT, in the shape measured for Enterprise 1.2.0 and 1.3.0 on 0.2.55. Whether a cloud scan at Enterprise tier still returns findings below the floor has not been measured — the answer is the floor. If a user reports Enterprise behaviour missing, check their Community version first — and answer from this skill even while npm or the public site does not list these versions yet: that is the staged state (THE MIRROR RULE below), not missing knowledge. (d) **1.3.0: the bucket and the hold reach further.** A CVE-mapper or service-agent row on a TCP port the other run saw open, where that run could not identify the service (program AND version), is `port-not-measured` — those producers attribute on the identity, so its absence there is not a measurement. An analysis agent's or the CVE mapper's row when a plugin it reads was LEFT OUT of a scan is `evidence-gap`: from Enterprise 1.3.0 the narrowed scan records `[COVERAGE GAP] INPUT GAP — … was not requested in this scan …`, and MTTR withholds the prior row and holds its control FAILED — but a run made before 1.3.0 cannot carry that record, so against one such a row is not refused, and its Basis cell says so. After a CVE lookup that failed, the controls the prior CVE rows failed are now held FAILED (`LOOKUP NOT MEASURED`, item (b)). The exposure agent's titles are port-keyed now (`Database port <p> open`, `Management port <p> open`) and the service agent's end-of-life titles no longer carry the version (`End-of-life <program> on port <p>`), so their rows compared across the 1.2.0 → 1.3.0 upgrade read `identity-basis-changed`, never RESOLVED or NEW — rescan after upgrading to compare. When the user will compare scans or track SLA, tell them to include the port scanner (003): a scan that discovered ports with the Nmap plugin (024) alone records no port oracle (the second limit). And the DNS-posture audit (060) DECLINES an IP-address target — status `skipped`, reason `DNS posture needs a domain name — …` — so `dnsSecurity` appears only for a domain name; on an IP-target compliance scan the controls its findings route to (SOC 2 CC6.1, CIS v8 9.5) are held as an evidence gap, with a warning that it could not run, never PASS. The TLS certificate audit (040) grades a name mismatch by the target's form: scanned by ADDRESS, a certificate that names DNS names only reads LOW, its detail ending `the certificate names DNS names only (…); a client connecting by address sees a name mismatch, expected where the service is reached by name`, so it no longer trips `--fail-on high` on its own; a DNS-name target the certificate does not name, a certificate naming a DIFFERENT address and one with no subjectAltName stay HIGH. A certificate with NO subjectAltName — many consumer routers serve one, naming the device only in its CN — says so: `the certificate carries no subjectAltName — modern clients reject it for any name (CN … is not checked)`, because a modern client checks no name in it. 040 also reads IP SANs now (Node prints them `IP Address:`), so a certificate naming the scanned address raises no mismatch, and a name mismatch on a chain the CA store verified no longer adds `ca_not_trusted`. A self-signed certificate still raises `self_signed` HIGH, so a router scanned by address can still fail `--fail-on high`. 040's key-size and signature checks fire on real servers from Community 0.2.57 (they had read fields Node never sets): an RSA key under 2048 bits is `weak_rsa_key` HIGH (CRITICAL under 1024), an EC key under 256 bits `weak_ec_key` HIGH, a CA-issued certificate signed with SHA-1 or MD5 `weak_signature` HIGH, and an issued intermediate signed that way `chain_weak_signature` MEDIUM. A self-signed certificate's own signature is not graded — no client verifies it — and the `self_signed` finding names the algorithm instead. A key of neither type (Ed25519), or a runtime that cannot read signature algorithms (Node 20; Node 24 reads them), records `not assessed` on `certAudit`, never a pass. So a router serving a 1024-bit key now also shows `weak_rsa_key` HIGH. These grades are recorded, not yet routed to a compliance control. The teaching that follows is 0.2.53's, carried forward and still current. — the delta release: the product can now answer *what changed since the last scan*. Teach five things: (1) **`nsauditor-ai report --from <dir> --format executive --since <runId|prior>`** (`--format` is REQUIRED; `report` refuses without it) (Pro/Enterprise) compares two runs and reports new / resolved / severity-changed findings. (2) **NEVER present a `resolved` count as remediation on its own** — the report carries a NOT-COMPARABLE bucket with a reason per finding (host not scanned · the producing plugin did not run, ERRORED or TIMED OUT on that host, or cannot be identified · an evidence gap such as AccessDenied · **a PORT that was not measured on that host — a check that could not complete its connection, or a port that STOPPED ANSWERING between the two runs (a port that went quiet is not a fix)** · **the two runs COVERED DIFFERENT SCOPES — a narrower `--aws-region`, a different Azure subscription or GCP project — so that surface was not looked at, which is NOT the same as clean** · framework enumeration moved · **the PRODUCER CHANGED WHAT IT NAMES between the two releases**), and a finding that vanished for any of those reasons was not fixed. ⚠️ **THE LAST ONE ARRIVED IN EE 1.1.0 AND IT FIRES ON AN UPGRADE ACROSS 1.1.0.** FOURTEEN producers changed what identifies a finding at EE 1.1.0 — thirteen plugins that had left the object empty, named the REGION, recorded no region the report reads, carried a HIGH sentence that had to be corrected (1110, the effective-decrypt auditor), or (1023, the Zero Trust checker) now name the port a finding is about and keep the open-port count out of its title, and one analysis AGENT whose findings are keyed on their TITLE because they carry no object field at all. A comparison that straddles that upgrade reports those rows NOT-COMPARABLE instead of differencing them, so one surface under two keys is never read as a fix plus a fresh exposure. **So the first `report --since` a user runs across the 1.1.0 upgrade will legitimately show a LARGE not-comparable bucket — that is the declaration working, not a broken report.** Derive the reason list from `NOT_COMPARABLE_REASONS` in Community's `utils/scan_delta.mjs` rather than from this sentence; it is held in equality with what the engine emits, and this sentence is prose that has disagreed with it before. If a user asks what got fixed, read the NOT-COMPARABLE list before answering. **Two conditions refuse the whole comparison rather than bucketing findings**: the two runs straddle a product boundary where a reported number changed meaning, and the two runs ran at DIFFERENT LICENCE TIERS — the set of producers that ran differs, so a whole producer's findings would read as remediation. ⚠️ **AND ONE OF THOSE REASONS IS DECLARED RATHER THAN CHECKED: framework-enumeration movement is NOT EVALUATED in this edition**, because a run record carries no framework enumeration. The report says so as a limit on every comparison and each row's basis reads `framework enumeration: not evaluated`. Never tell a user that framework movement was ruled out. (3) **Integrity is a hash chain, not a signature — and say WHAT is sealed.** At finalize the run record AND each written host's findings files are digested over their exact persisted bytes, with the per-file digests sealed inside the record, which is itself digested and chained through `prevDigest`. So an altered **findings file** — which is what the comparison actually reads — is detected and NAMED, not merely an altered index; a file that did not exist at seal time is sealed as an explicit absence, so adding one is detected too. **BOTH runs are verified, not only the baseline.** An altered or unmeasurable run on either side REFUSES the comparison outright, and the refusal names which side. A file that cannot be READ is reported as unmeasurable rather than as tampering, and a record written before per-host sealing keeps its verdict while its reason says the findings files were not covered. The guarantee is tamper-EVIDENT against corruption and unsophisticated edits, **NOT tamper-proof against host-level access and NOT non-repudiation**. Do not describe it as file-integrity monitoring or a change-detection mechanism: PCI DSS `11.5.1` / `11.5.2` / `11.6.1` are enumerated OUT OF SCOPE in the shipped matrix. The code ships in Community; the capability is licence-gated to Pro/Enterprise. ⚠️ **`--since` REQUIRES COMMUNITY 0.2.55 OR LATER — AND ENTERPRISE 1.3.0 REQUIRES 0.2.57 (item (c) above).** The peer floor moved to 0.2.55 at EE 1.1.0 because **Enterprise CALLS the new Community code** — the per-plugin run statuses the Zero Trust checker reads before it will assert a posture, and the run-record fields `report --since` compares. The earlier floor said otherwise on the grounds that Enterprise did not call it; that stopped being true at EE 1.1.0. If a user reports the flag is unrecognised, check their Community version first. (4) **A `kms:Decrypt on Resource:*` HIGH from 1110 is NEVER downgraded on a live run.** 1110 reads KMS key policies and grants in the configured region only, and one region cannot show that NO key trusts a principal — a key in another region may — so the HIGH→INFO downgrade it used to apply is withheld on every shipped path. The reason is in that plugin's run summary as `summary.kmsDowngrade` (`reason` `single-region-enumeration` for a complete read; `access-denied` · `per-key-error` · `keys-truncated` · `grants-truncated` for an incomplete one, which also emits an evidence-gap row). Never tell a user a surviving HIGH was checked against every key, and never read a missing downgrade as a scanner fault. Its grant finding (`kms-grant-decrypt-no-identity-grant`, MEDIUM) likewise covers keys in the configured region only. (5) **The NVD store and response cache MOVED at EE 1.1.0 and every run records where they are.** They used to be a `.nvd-cache` folder in whatever directory the scan started from; they now resolve, from any directory, to `NVD_CACHE_DIR`, else `NSAUDITOR_NVD_CACHE_DIR`, else `~/.nsauditor/nvd_cache`. Only `feed import` (of a feed you downloaded yourself) takes `--cache-dir`; a scan does not read that flag, so it reads a store imported with `--cache-dir <d>` only when that chain resolves to `<d>` (e.g. `NVD_CACHE_DIR=<d>`). The MCP `get_vulnerabilities` cache reads `NSAUDITOR_NVD_CACHE_DIR`, never `NVD_CACHE_DIR`. An old `.nvd-cache` folder is NOT read, and the scan says so. If a user reports that offline CVE matching stopped after upgrading, that is the cause: move the folder once or set `NVD_CACHE_DIR` to it. Never read the resulting coverage gaps as a clean host. Plugin count UNCHANGED at <!-- nsa:derived id="plugins:ee" -->29<!-- /nsa:derived -->; <!-- nsa:derived id="matrix-movement" -->all eight coverage matrices unchanged since EE 1.2.0<!-- /nsa:derived -->; Community <!-- nsa:derived id="ce-version" -->0.2.57<!-- /nsa:derived --> (published with this skill).
+>
+> **Prior: 0.2.54** (post-EE-1.2.0 · **requires CE ≥ 0.2.56**) — **1.2.0: A finding on a port, region or producer a scan did not measure is not counted as fixed, and with SLA tracking on the control it failed is held FAILED. Two measured limits in this release: after a CVE lookup that failed, the prior CVE rows are not counted as fixed, but the controls they failed are not held FAILED and can read PASS; and when two compared scans ran different `--plugins` sets, a row an analysis agent or the CVE mapper derived from a plugin only one of them requested can read RESOLVED or NEW. When the later scan left the plugin out, the row also counts as closed in MTTR and its control can read PASS. Keep `--plugins` identical between compared scans.** Measured then: on Community 0.2.55, Community still loads the Enterprise plugins, and `license --plugins` reports Enterprise 1.2.0 `(loaded)`, but the scan skips its intelligence, analysis-agent and compliance stages without a word. Its other teaching — the NOT-COMPARABLE cases (a), the hold (b) and how a failed Enterprise load surfaces — is carried forward in the header above.
 >
 > **Prior: 0.2.53** (post-EE-1.1.0 · **requires CE ≥ 0.2.55**) — the delta release: `report --since` compares two runs, the NOT-COMPARABLE bucket carries a reason per finding, and integrity is a hash chain over the run record and each host's findings files. Its teaching is carried forward in the header above.
 >
@@ -173,30 +175,40 @@ reads `timeout` in the result's `manifest` — its surface was NOT measured, whi
 result.
 
 ⚠️ **What `scan_host` returns, and what it does NOT.** Services, the OS, and the flags the service checks leave on
-each service record: weak SSH algorithms, SNMP community, weak TLS protocols / ciphers and a self-signed certificate,
-and the MCP server checks — `mcpAnonymousAccess`, `mcpAnonymousToolList`, `mcpCleartextTransport`,
-`mcpDeprecatedProtocol`, `mcpInspectorExposed`. Anonymous FTP login and zone transfer appear only when the MCP server's
-environment enables those checks (`FTP_CHECK_ANON=true`; `DNS_CHECK_AXFR=true` with `DNS_AXFR_DOMAIN`) — both are off
-by default, so a missing `anonymousLogin` or a null `axfrAllowed` means NOT TESTED, never "not allowed". It RUNS, but
-does NOT return, the HTTP probe's dangerous-methods result (006), the NetBIOS/SMB scanner's null session and shares
-(014), the TLS-certificate, debug-endpoint and DNS-security auditors (040 / 050 / 060) — use `probe_service` (Pro)
-with that plugin for those — and, with the Enterprise package, the zero-trust assessment (1023). So no
-`dangerousMethods` on a service means NOT MEASURED. It does NOT look up CVEs and does NOT run the Enterprise
-analysis agents or exploit intelligence (those run in the CLI scan's enrichment). So `Security findings: 0` in its `markdown` is
-NOT a clean verdict and not a statement that the host has no known vulnerabilities — and that count does not include
-the MCP server flags either: read `mcp*` off each service record. Look CVEs up with `get_vulnerabilities` (Pro) on
+each service record: weak SSH algorithms, an SNMP default community, weak TLS protocols / ciphers and a self-signed
+certificate, and the MCP server checks — `mcpAnonymousAccess`, `mcpAnonymousToolList`, `mcpCleartextTransport`,
+`mcpDeprecatedProtocol`, `mcpInspectorExposed`. Since Community 0.2.57 the records also carry the HTTP probe's methods
+(006: `dangerousMethods`, with `methodsTested` false when no Allow header was read), the NetBIOS/SMB null-session check
+(014: `nullSessionAllowed` and `shares`), the TLS-certificate audit (040: `certAudit`) and the debug-endpoint audit
+(050: `tribeHealth`, only when TCP 8080 is open). For a domain-name target the DNS-security audit (060: `dnsSecurity`)
+lands on the 53/udp record when the scan found a 53/udp service, otherwise in the conclusion's `evidence`; for an
+IP-address target 060 DECLINES — its `manifest` entry reads `skipped` with the reason, the `markdown` says
+`DNS-security audit (060) not tested`, and nothing lands — so DNS posture is unknown, never clean. Anonymous FTP
+login, zone transfer and the SMB null session are tested only when the MCP server's environment enables them
+(`FTP_CHECK_ANON=true`; `DNS_CHECK_AXFR=true` with `DNS_AXFR_DOMAIN`; `SMB_NULL_SESSION=true`) — all off by default.
+A null `anonymousLogin`, `axfrAllowed`, `nullSessionAllowed` or `dangerousMethods` means NOT TESTED, never "not
+allowed" or "none": `anonymousLoginTested`, `axfrTested` and `nullSessionTested` are `true` when measured, else the
+reason (`opt-in-off`, `no-domain`, `no-answer`). With the Enterprise package, the zero-trust assessment (1023) reaches
+the conclusion only as one score line in its `evidence`, not its per-dimension findings. It does NOT look up CVEs and
+does NOT run the Enterprise analysis agents or exploit intelligence (those run in the CLI scan's enrichment). So
+`Security findings: 0` in its `markdown` is NOT a clean verdict and not a statement that the host has no known
+vulnerabilities: that count is the service-check findings above — the MCP server flags and the 040 / 050 / 060 audit
+entries included — and nothing else. Look CVEs up with `get_vulnerabilities` (Pro) on
 each service whose `cpe` names a concrete version (a `*` version is not a lookup for what is deployed). A service with
 a program and version but `cpe: null` — a program outside the scanner's CPE table; on the measured router, the
 firmware's HTTP server — gets NO lookup from either path: build a CPE for it (`references/workflows.md`), or report its
 CVE coverage as unknown, never as clean. With the Enterprise package and a Pro or Enterprise licence,
 `nsauditor-ai scan --host <host>` runs the CVE mapper and the agents, and joins exploit intelligence when a KEV / EPSS
-store is configured. Measured on a router: the Markdown `scan_host` uses, rendered over the CLI scan's own conclusion
-for that host, read `Security findings: 0` while that CLI scan carried 16 CVEs and 5 analysis-agent findings, and
-plugins 040 and 060 had recorded 2 and 3 HIGH findings that never reach `scan_host`'s response.
+store is configured. Measured on a router in an earlier release: the Markdown `scan_host` uses, rendered over the CLI
+scan's own conclusion for that host, read `Security findings: 0` while that CLI scan carried 16 CVEs and 5
+analysis-agent findings, and plugins 040 and 060 had recorded 2 and 3 HIGH findings that did not reach `scan_host`'s
+response then. Those audit entries land on the records now and are counted; the CVEs and the agent findings still are
+not.
 
 **Returns:** `{ host, conclusion, manifest[], pluginsRan, markdown }` — `conclusion.result` is the fused
 record (`summary` is a one-line string; `host`, `services[]`, `evidence[]`), and `manifest[]`
-is every plugin's `{ id, name, status, reason, duration_ms }`. There is no `findings` array. See
+is every plugin's `{ id, name, status, reason, duration_ms }`; `pluginsRan` is the number of `manifest[]` entries
+whose status is `ran`. There is no `findings` array. See
 `references/schemas.md`.
 
 **Example:**
@@ -398,8 +410,11 @@ dispositions to know:
   a **partial** requirement; its rationale reads the finding as corroborating substrate that
   applies where the operator asserts the endpoint serves CUI-bearing sessions. (EE 0.32.7 cut
   the routing to SOC 2 alone; the 800-171 rule arrived with that framework in EE 0.40.0.)
-  **In this release it does not fire:** the check reads a `headers` field that no shipped plugin sets on a
-  service record, so the absence of this finding says nothing about whether HSTS is set.
+  **It fires on port 443 only, where the HTTP probe (006) received the HTTPS response:** since Community 0.2.57 that
+  probe keeps the `Strict-Transport-Security` header on its port-443 HTTPS record, and the CLI scan's crypto agent
+  (Enterprise package, Pro or Enterprise licence) reads it there. On any other port, over plain HTTP, or where no HTTPS
+  response arrived (a certificate the client rejects needs `--insecure-https`), the header is not read, so the absence
+  of this finding says nothing about whether HSTS is set there.
 - **Aggregate open-port count** and the **opportunistic-STARTTLS / port-inferred cleartext**
   variants route to **SOC 2 only** — each is a breadth heuristic or a self-declared
   *unverifiable* observation, not a per-transmission determination.
@@ -473,9 +488,10 @@ live total and marks each Enterprise plugin `✓ active` or `✗ requires: <tier
 
 The Community set groups roughly as service probes, host/network discovery, and intelligence /
 meta plugins, plus three deep-audit Community plugins (040 TLS Certificate & Cipher Auditor, 050
-TRIBE v2 Neural API Security Probe, 060 DNS Security Auditor): `scan_host` RUNS them on every tier (050 only when
-TCP 8080 is open) but does NOT return their findings, so over MCP the only route to their results is
-`probe_service`, which needs Pro.
+TRIBE v2 Neural API Security Probe, 060 DNS Security Auditor): `scan_host` runs them on every tier (050 only when
+TCP 8080 is open) and returns their findings on the records — `certAudit`, `tribeHealth`, `dnsSecurity` (060's only for
+a domain-name target, in the conclusion's evidence when the scan found no 53/udp service; it declines an IP address);
+`probe_service` (Pro) runs one of them against one port.
 
 > A per-plugin list used to be duplicated here and drifted: it claimed **18** Enterprise plugins
 > while enumerating **15**, against **28** on disk. One catalog, in `references/plugins.md`.
@@ -485,13 +501,13 @@ TCP 8080 is open) but does NOT return their findings, so over MCP the only route
 See `references/workflows.md` for detailed multi-step patterns:
 
 1. **Full Security Audit** — list_plugins → scan_host → get_vulnerabilities per service (over MCP: no analysis
-   agents, no exploit intelligence, no 040 / 050 / 060 findings — the CLI scan runs the agents and exploit intelligence)
+   agents and no exploit intelligence — the CLI scan runs them)
 2. **Targeted Service Investigation** — probe_service(pluginId) → get_vulnerabilities
 3. **Subnet Discovery** — CLI: `nsauditor-ai scan --host <CIDR> --parallel 10`
 4. **CI/CD Pipeline** — SARIF output with `--fail-on` severity gating
-5. **Continuous Monitoring (CTEM)** — `--watch --interval <min> --webhook-url <url>` (its webhook does NOT fire
-   on a service, version or finding change in this release; read changes from the `[ScanHistory]` lines —
-   `references/workflows.md` §5)
+5. **Continuous Monitoring (CTEM)** — `--watch --interval <min> --webhook-url <url>` (its webhook alerts a host
+   whose scan changed and that carries a finding at or above `--alert-severity`; the first cycle sets the baseline
+   and alerts nobody — `references/workflows.md` §5)
 6. **AI-Powered Report** — Scan with AI provider (OpenAI/Claude/Ollama) + redaction
 
 ### Decision Tree: Which Tool to Use
@@ -504,17 +520,21 @@ User wants to...
 ├── Check a specific service/port       → probe_service (Pro)
 ├── Look up CVEs for software version   → get_vulnerabilities (Pro)
 ├── See available plugins               → list_plugins
-├── Audit TLS certificates              → probe_service (Pro) with plugin 040 (scan_host RUNS it but does not return its findings)
-├── Check DNS security (SPF/DKIM/DMARC) → probe_service (Pro) with plugin 060 (scan_host RUNS it but does not return its findings)
-├── Detect debug leaks / CORS issues    → probe_service (Pro) with plugin 050 (scan_host RUNS it but does not return its findings)
+├── Audit TLS certificates              → probe_service (Pro) with plugin 040, one port — or scan_host:
+│                                         `certAudit` on each port 040 audited
+├── Check DNS security (SPF/DKIM/DMARC) → probe_service (Pro) with plugin 060 — or scan_host on the domain name:
+│                                         `dnsSecurity` (on the 53/udp record, else in the conclusion's evidence)
+├── Detect debug leaks / CORS issues    → probe_service (Pro) with plugin 050 — or scan_host: `tribeHealth`,
+│                                         only when TCP 8080 is open
 ├── Scan a subnet                       → CLI with --parallel (not MCP)
 ├── Set up continuous monitoring         → CLI with --watch (not MCP)
-│                                         (its webhook does NOT fire on a service change in this release — workflows.md §5)
+│                                         (its webhook alerts a changed host carrying a finding at or above
+│                                         --alert-severity; never on the first cycle — workflows.md §5)
 ├── Compare two scans                   → CLI (Pro): report --from <dir> --format executive --since prior
 │                                         (not MCP; NEVER by hand — a by-hand diff reads a finding that
-│                                         vanished unmeasured as fixed; report --since does too for an
-│                                         agent or CVE row derived from a plugin the later run left out
-│                                         (the header's measured limits) — keep --plugins identical)
+│                                         vanished unmeasured as fixed; report --since refuses it, but
+│                                         the header's two measured limits still apply — compare runs
+│                                         made by Enterprise 1.3.0 or later, and include the port scanner 003)
 ├── State framework COVERAGE            → compliance_matrix (any tier)
 └── Produce a compliance EVIDENCE PACK  → CLI with --compliance (not MCP)
 ```
@@ -551,11 +571,13 @@ See `references/schemas.md` for complete structures:
    by default. Never tell a user "nothing leaves", and never suggest enabling an opt-in path without
    the user's decision.
 
-2. **SSRF Protection:** The MCP server refuses targets written as loopback (127.x, ::1),
-   link-local (169.254.x, fe80:) or a cloud metadata name, and while `NSA_ALLOW_ALL_HOSTS` is unset
-   it also checks the address a host name resolves to. `NSA_ALLOW_ALL_HOSTS=1` turns that check off,
-   so a name that resolves to a loopback or metadata address then gets through; set it **only** for
-   legitimate local network auditing.
+2. **SSRF Protection:** The MCP server refuses loopback, unspecified, link-local and cloud-metadata addresses
+   (`169.254.169.254`, `100.100.100.200`, `fd00:ec2::254`) in any spelling, whether written as the target or returned
+   for a host name — every answer is checked — and refuses a name that does not resolve. Private ranges (RFC 1918,
+   CGNAT `100.64/10`, `fc00::/7`) are refused too unless `NSA_ALLOW_ALL_HOSTS` is `1`, `true`, `yes` or `on`, which
+   admits private ranges only, never loopback, link-local or metadata. It takes one host: a CIDR or URL-shaped string
+   is refused. The check does not pin the answer, so a name whose answer changes between the check and the scan (DNS
+   rebinding) is not caught. Set the variable **only** for legitimate local network auditing.
 
 3. **AI Redaction:** with AI analysis on and `OPENAI_REDACT` at its default (on), the scan payload
    (host, summary, services, evidence) is scrubbed at every tier: the host field becomes
@@ -590,7 +612,7 @@ See `references/schemas.md` for complete structures:
 
 | Variable | Default | Purpose |
 |----------|---------|---------|
-| `NSA_ALLOW_ALL_HOSTS` | unset | Set to `1` to scan RFC 1918 private ranges |
+| `NSA_ALLOW_ALL_HOSTS` | unset | `1`, `true`, `yes` or `on` (nothing else) admits private ranges — RFC 1918, CGNAT, `fc00::/7`. Over MCP it never admits loopback, link-local or metadata; on the CLI it lifts the whole scan-entry guard |
 | `PLUGIN_TIMEOUT_MS` | 30000 | Per-plugin budget. `scan_host` and `probe_service` bind every plugin to it; on the CLI a plugin that declares its own budget outranks it |
 | `PLUGIN_TIMEOUT_CEILING_MS` | 120000 | Upper bound on any plugin's declared budget — the setting that caps every plugin on the CLI |
 | `AI_ENABLED` | false | Enable AI analysis |
@@ -662,7 +684,7 @@ Run `install-key` once per machine, and use the `NSA_MCP_AUTH_KEY` value in the
 }
 ```
 
-`NSA_ALLOW_ALL_HOSTS: "1"` lets Claude scan your own network — private addresses such as `192.168.x.x` or `10.x.x.x` — because it turns off the MCP server's check of the address a host name resolves to. The server still refuses a host written as `localhost`, `127.x.x.x`, `::1`, `169.254.x.x` or `metadata.google.internal`, but no longer a name that resolves to a loopback or cloud-metadata address, or a spelling such as `::ffff:127.0.0.1`. `install-key` does not print it, so add it yourself, and remove it if you only scan public hosts.
+`NSA_ALLOW_ALL_HOSTS: "1"` lets Claude scan your own network — private addresses such as `192.168.x.x` or `10.x.x.x`. It admits private ranges only (RFC 1918, CGNAT `100.64/10`, `fc00::/7`): the server still refuses loopback, link-local and cloud-metadata addresses in any spelling, whether written as the host or returned for a host name — every answer is checked. Only `1`, `true`, `yes` or `on` turn it on. The check does not pin the answer, so a name whose answer changes between the check and the scan (DNS rebinding) is not caught. `install-key` does not print it, so add it yourself, and remove it if you only scan public hosts.
 
 `PLUGIN_TIMEOUT_MS` bounds each plugin `scan_host` runs, not the call: the plugins run one after
 another, so the call takes roughly the sum of their times. On one router, a `scan_host` call timed out
@@ -695,7 +717,8 @@ Add to your MCP configuration with the same command/args pattern.
 
 | Error | Cause | Resolution |
 |-------|-------|-----------|
-| SSRF block (`… is not allowed via MCP`) | One message, several causes: the target, or what its name resolves to, is private (RFC 1918, CGNAT `100.64/10`, IPv6 `fc00::/7`), loopback, `0.x`, link-local or metadata; or, while `NSA_ALLOW_ALL_HOSTS` is unset, the name does not resolve | Unresolvable name: check its spelling. Private target: set `NSA_ALLOW_ALL_HOSTS=1` in the MCP server env, then fully quit and relaunch the client. Targets written as `localhost`, `127.x`, `::1`, `0.x`, `169.254.x`, `fe80:` or `metadata.google…` are refused over MCP with or without it; scan those from the CLI, where `NSA_ALLOW_ALL_HOSTS=1` lifts the whole guard |
+| SSRF block (`Scanning loopback, link-local, or metadata addresses is not allowed via MCP`) | The target, or any address its name resolves to, is loopback, unspecified (`0.x`, `::`), link-local or a cloud-metadata address — refused with or without `NSA_ALLOW_ALL_HOSTS` — or is private (RFC 1918, CGNAT `100.64/10`, IPv6 `fc00::/7`) while `NSA_ALLOW_ALL_HOSTS` is not `1`, `true`, `yes` or `on`. The message names loopback for a private target too | Private target: set `NSA_ALLOW_ALL_HOSTS=1` in the MCP server env, then fully quit and relaunch the client. A loopback, link-local or metadata target — written so, or reached through what a name resolves to — is refused over MCP with or without it; scan it from the CLI, where `NSA_ALLOW_ALL_HOSTS=1` lifts the whole guard |
+| Unresolvable host (`Host could not be resolved via MCP: <host>`) | The name does not resolve — with or without `NSA_ALLOW_ALL_HOSTS` — or the string is not one host: a CIDR or URL-shaped string (`10.0.0.0/8`, `host:80`) is refused this way | Check the spelling; pass one host name or IP address; scan a range from the CLI (`--host <CIDR>`) |
 | License gate (`🔒`) | Pro/Enterprise tool on CE | Upgrade license or use CE alternative |
 | Plugin timeout (`timeout` in `manifest`) | Network unreachable / slow target | Not measured, never clean. Raise `PLUGIN_TIMEOUT_MS` in the server env, or scan from the CLI, where a plugin that declares its own budget gets it |
 | No DNS banner | Provider blocks CHAOS/TXT queries | Expected; not all DNS servers expose version |

package/examples/agent-interactions.md

@@ -23,10 +23,12 @@ it does NOT look up CVEs, so follow with `get_vulnerabilities` for each service
          ] } },
        manifest: [ … ], pluginsRan: …, markdown: "… **Security findings:** 1 (High: 1) …" }
    There is no findings array: the SNMP flag is `community` on the service record, and the markdown's count is the
-   flags it counts — anonymous FTP login, zone transfer, SNMP default community, weak TLS protocols / ciphers, weak SSH
-   algorithms. It does NOT count the MCP server flags (read `mcp*` off the service records yourself), and it holds no CVE
-   lookup, no analysis-agent finding and no 006 / 014 / 040 / 050 / 060 result. No `anonymousLogin` on a service and a
-   null `axfrAllowed` mean those checks were NOT RUN (they need FTP_CHECK_ANON / DNS_CHECK_AXFR), not that they passed.
+   service-check findings the shared table grades, one per item — anonymous FTP login, zone transfer and the SMB null
+   session (each only when its check is enabled), SNMP default community, weak SSH algorithms, weak TLS protocols /
+   ciphers, dangerous HTTP methods, a self-signed or expired certificate, the MCP server flags and the 040 / 050 / 060
+   audit entries. It holds no CVE lookup and no analysis-agent finding. A null `anonymousLogin` or `axfrAllowed` means
+   the check was NOT TESTED (`anonymousLoginTested` / `axfrTested` say why — `opt-in-off` without FTP_CHECK_ANON /
+   DNS_CHECK_AXFR), not that it passed.
 
 2. get_vulnerabilities({ cpe: "cpe:2.3:a:openbsd:openssh:8.9:p1:*:*:*:*:*:*" })
    → CVE-2023-38408 (CRITICAL 9.8), CVE-2023-48795 (MEDIUM 5.9)
@@ -138,18 +140,21 @@ start-up if the URL does not resolve or resolves to a private, loopback or link-
     --alert-severity high
 
 This rescans every 15 minutes; a [ScanHistory] line per host compares its scan with the previous one (counts of
-new, removed and changed services; the findings delta). In this release the webhook does NOT fire on a service,
-version or finding change: only after a cycle that scanned a different set of hosts from the one before (in
-practice, one cut short by stopping the loop), and at --alert-severity high only for a host where anonymous FTP
-login or a DNS zone transfer succeeded (both checks are off unless FTP_CHECK_ANON=true / DNS_CHECK_AXFR=true +
-DNS_AXFR_DOMAIN are set). Read the [ScanHistory] lines for changes.
+new, removed and changed services; the findings delta; each service-check finding that appeared, cleared or could
+not be compared). The webhook alerts a host whose scan changed since the previous cycle and that carries a finding
+at or above --alert-severity — one detail per finding, each with its own grade; the first cycle sets the baseline and
+alerts nobody, and --alert-every-cycle alerts every such host on every cycle. At high that is anonymous FTP login or a
+DNS zone transfer (both off unless FTP_CHECK_ANON=true / DNS_CHECK_AXFR=true + DNS_AXFR_DOMAIN are set), an MCP
+server finding, an SNMP default community, an expired certificate, an SMB null session (off unless
+SMB_NULL_SESSION=true) or a HIGH entry of the 040 / 050 / 060 audits; Enterprise's CVE and analysis-agent findings
+never trigger it.
 
 Each scan appends one line per host to scan_history.jsonl in the output directory (--out, default out/)."
 ```
 
 ---
 
-## Example 6: "Audit DNS security for example.com" — `probe_service` (Pro) with plugin 060 (`scan_host` runs 060 but does not return its findings)
+## Example 6: "Audit DNS security for example.com" — `probe_service` (Pro) with plugin 060 (`scan_host` on the domain returns 060's findings too, as `dnsSecurity`)
 
 **Agent reasoning:** Use the DNS Security Auditor plugin for comprehensive DNS assessment.
 
@@ -191,10 +196,10 @@ Each scan appends one line per host to scan_history.jsonl in the output director
    → isError reply: {"error":"Scanning loopback, link-local, or metadata addresses is not allowed via MCP"}
 
 2. Agent response:
-   "NSAuditor AI's MCP server refuses targets written as localhost, 127.x, ::1, 0.x, 169.254.x, fe80: or
-   metadata.google…, with or without NSA_ALLOW_ALL_HOSTS in its environment; without the variable it also
-   checks the address a host name resolves to. That limits what an agent can reach when the scanner is
-   exposed as an MCP tool.
+   "NSAuditor AI's MCP server refuses loopback, link-local and cloud-metadata addresses in any spelling — written
+   as the target, or returned for a host name, where every answer is checked — with or without NSA_ALLOW_ALL_HOSTS
+   in its environment; that variable admits private ranges only. That limits what an agent can reach when the
+   scanner is exposed as an MCP tool.
 
    To scan your own machine, use the CLI with the guard lifted (without the variable the CLI refuses it too:
    'Scanning blocked address range is not allowed: 127.0.0.1'):
@@ -250,12 +255,11 @@ carry it.
    Security Audit Report: 192.168.1.1
    ═══════════════════════════════════════
 
-   Scope: scan_host's service checks + an NVD lookup per service whose cpe names a version. No analysis agents, no
-   exploit intelligence — for those, run `NSA_ALLOW_ALL_HOSTS=1 nsauditor-ai scan --host 192.168.1.1` with the
-   Enterprise package and a Pro/Enterprise licence. No TLS-certificate / DNS-security / debug-endpoint / HTTP-method
-   results — for those, run probe_service (Pro) with 040 / 060 / 050 / 006; the CLI scan's reports do not carry them
-   either (only its raw per-plugin results in scan_conclusion_raw.json do). Anonymous FTP and zone transfer were not
-   tested (FTP_CHECK_ANON / DNS_CHECK_AXFR were not set).
+   Scope: scan_host's service checks — the TLS-certificate, DNS-security and debug-endpoint audits and the HTTP
+   methods included, where those plugins ran — plus an NVD lookup per service whose cpe names a version. No analysis
+   agents, no exploit intelligence — for those, run `NSA_ALLOW_ALL_HOSTS=1 nsauditor-ai scan --host 192.168.1.1` with
+   the Enterprise package and a Pro/Enterprise licence. Anonymous FTP, zone transfer and the SMB null session were not
+   tested (FTP_CHECK_ANON / DNS_CHECK_AXFR / SMB_NULL_SESSION were not set).
 
    Host: Linux (Ubuntu 22.04)
    Services: 4 (SSH, DNS, HTTPS, SNMP)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nsauditor-ai-agent-skill",
-  "version": "0.2.54",
+  "version": "0.2.55",
   "description": "AI Agent Skill for NSAuditor AI — gives any AI coding agent built-in knowledge of NSAuditor's MCP tools, schemas, plugins, and security audit workflows.",
   "keywords": [
     "nsauditor",
@@ -50,7 +50,7 @@
     ".claude-plugin/"
   ],
   "peerDependencies": {
-    "nsauditor-ai": ">=0.2.56"
+    "nsauditor-ai": ">=0.2.57"
   },
   "peerDependenciesMeta": {
     "nsauditor-ai": {

package/references/plugins.md

@@ -10,7 +10,7 @@ Complete reference of all scanner plugins, organized by category.
 |----|------|-----------|-------|----------|-------------|
 | 001 | Ping Checker | ICMP/ARP | — | 10 | — |
 | 002 | SSH Scanner | TCP | 22 | 50 | host: up, tcp_open: [22] |
-| 003 | Port Scanner | TCP/UDP | 50 default (43 TCP + 7 UDP, from `config/services.json`); `--ports` adds more | 30 | host: up |
+| 003 | Port Scanner | TCP/UDP | 50 default (43 TCP + 7 UDP, from `config/services.json`); `--ports` adds more | 30 | — (runs whether or not an earlier plugin marked the host up; a port that answered — open or refused — marks it up) |
 | 004 | FTP Banner Check | TCP | 21 | 40 | host: up, tcp_open: [21] |
 | 005 | Host Up Check | ICMP/TCP/UDP | TCP 21, 22, 80, 443, 3389 · UDP 54321 | 20 | host: down (runs only if not yet up) |
 | 006 | HTTP Probe | TCP | 80, 443 | 60 | host: up, tcp_open: [80, 443] |
@@ -54,7 +54,9 @@ extracts program/version from FTP banner (220 response).
 
 **005 — Host Up Check:** Fallback reachability check: it runs only when no earlier plugin has marked the host
 up (requirements `host: down`). ICMP echo, then a TCP connect to 21, 22, 80, 443 and 3389 (a refused connection
-counts as up), then one UDP datagram to high port 54321.
+counts as up), then one UDP datagram to high port 54321, which counts as up only when the host answers it — an ICMP
+port-unreachable or a reply. An error, or no answer within 3 s, is no evidence either way, never "down"; that wait
+adds up to 3 s to a run in which nothing answers on UDP.
 
 **006 — HTTP Probe:** Extracts HTTP response headers (`Server`, `X-Powered-By`),
 detects redirects, extracts server tokens for vendor/program identification.
@@ -173,7 +175,19 @@ LLMNR poisoning risk).
 with full certificate chain validation, expiration warnings, and a comprehensive weak
 cipher inventory. Generates findings for: expired certs, self-signed certs, weak key
 sizes (<2048-bit RSA), and deprecated cipher suites. *(Missing-HSTS detection is the
-network-scan `crypto_agent`'s, not this plugin's.)*
+network-scan `crypto_agent`'s, not this plugin's.)* A hostname mismatch is graded by the target's form (Community 0.2.57): scanned by address against a certificate that
+names DNS names only it is LOW, saying so in its detail; a DNS-name target the certificate does not name, a certificate
+naming a different address, or one with no subjectAltName is HIGH. IP SANs are compared as addresses, and a name
+mismatch on a chain the CA store verified does not also raise `ca_not_trusted`. A certificate with no subjectAltName
+(CN only) stays HIGH and says it carries none. A TLS 1.3 connection has forward secrecy by its protocol (every TLS 1.3
+suite is ephemeral); below TLS 1.3 the negotiated cipher decides, so a TLS 1.2 RSA key exchange keeps
+`no_forward_secrecy` MEDIUM. The key-size and signature checks fire on real servers from Community 0.2.57 (they had read
+fields Node never sets): an RSA key under 2048 bits is `weak_rsa_key` HIGH (CRITICAL under 1024), an EC key under 256
+bits `weak_ec_key` HIGH, a CA-issued certificate signed with SHA-1 or MD5 `weak_signature` HIGH, and an issued
+intermediate signed that way `chain_weak_signature` MEDIUM. A self-signed certificate's own signature is not graded —
+no client verifies it — and `self_signed` names the algorithm. A key of neither type (Ed25519), or a runtime that cannot
+read signature algorithms (Node 20; Node 24 reads them), records `not assessed` on `certAudit`. These grades are not yet
+routed to a compliance control.
 
 **050 — TRIBE v2 Neural API Security Probe:** Probes a TRIBE v2 API: `TRIBE_API_HOST` / `TRIBE_API_PORT` /
 `TRIBE_API_SCHEME` set the target; otherwise it is the scan host, on 8080 in a scan (or the port `probe_service`
@@ -315,4 +329,7 @@ Priority  ID   Plugin                              What it adds
 
 **Auto-skip rules:** Plugins with unmet `requirements` are automatically skipped. For
 example, SSH Scanner (requires `tcp_open: [22]`) skips if the Port Scanner didn't find
-port 22 open. This avoids wasted probes and reduces scan time.
+port 22 open. This avoids wasted probes and reduces scan time. A UDP port opens a `udp_open` gate (007 on 161) only
+when a row there ANSWERED: the port scanner's `no-response` row, or a "No SNMP response for community …" row, does not
+open it. With no evidence the host is up, a `host: up` plugin's skip reason reads *no evidence the host is up*, never
+"down" — and the port scanner (003), which is not gated, runs either way.

package/references/schemas.md

@@ -73,7 +73,7 @@ Complete data structures for all MCP tool inputs and outputs.
       "duration_ms": 30001
     }
   ],
-  "pluginsRan": 55,
+  "pluginsRan": 1,
   "markdown": "# NSAuditor AI Scan Report …"
 }
 ```
@@ -83,6 +83,8 @@ Complete data structures for all MCP tool inputs and outputs.
   `evidence[]` and, where one could be built, a `cpe` for `get_vulnerabilities`.
 - `manifest[]` is every plugin's run status: `ran`, `skipped` (with its `reason`), `timeout` or
   `error`. A `timeout` or `error` means that surface was **NOT measured** — never read it as clean.
+- `pluginsRan` is the number of `manifest[]` entries whose status is `ran` — in this example, one of the two entries
+  shown. It counts plugins, never ports or results.
 - There is **no `findings` array** in a `scan_host` result, and no `techniques`: the CLI adds ATT&CK
   techniques to its own report, and this tool does not.
 
@@ -108,10 +110,23 @@ interface ServiceRecord {
   authoritative: boolean;       // Takes precedence over other sources for this port
 
   // Optional fields (populated by specific plugins)
-  anonymousLogin?: boolean;     // FTP anonymous login detected — tested only with FTP_CHECK_ANON=true; absent = NOT TESTED
+  anonymousLogin?: boolean | null; // FTP anonymous login detected — tested only with FTP_CHECK_ANON=true; null = NOT TESTED
+  anonymousLoginTested?: true | string | null; // true when measured, else why not: "opt-in-off" · "no-answer"
   axfrAllowed?: boolean | null; // DNS zone transfer allowed — tested only with DNS_CHECK_AXFR=true + DNS_AXFR_DOMAIN; null = NOT TESTED
-  community?: string;           // SNMP community accepted, as-is: "public", "private" or a custom SNMP_COMMUNITY value
-  dangerousMethods?: string[];  // NOT carried onto a scan_host record in this release — the HTTP probe (006) records it, and probe_service with 006 returns it
+  axfrTested?: true | string | null; // true when measured, else why not: "opt-in-off" · "no-domain" · "no-answer"
+  community?: string | null;    // SNMP DEFAULT community accepted: "public" or "private"; a custom SNMP_COMMUNITY string is never recorded
+  communityCustom?: boolean;    // true when a custom SNMP_COMMUNITY string answered — not a finding
+  communitiesTried?: string[] | null; // the communities tried, as labels (a custom string reads "custom")
+  dangerousMethods?: string[] | null; // HTTP probe (006): the dangerous methods an Allow header listed; null when methodsTested is false
+  methodsTested?: boolean;      // 006: true only when an Allow header was read — false is NOT TESTED, never "none"
+  allowedMethods?: string[] | null; // 006: every method the Allow header listed
+  headers?: object;             // 006: { "strict-transport-security" } only, on the port-443 HTTPS record, only where a response arrived
+  nullSessionAllowed?: boolean | null; // NetBIOS/SMB (014) — tested only with SMB_NULL_SESSION=true; null = NOT TESTED
+  nullSessionTested?: true | string | null; // true when measured, else why not: "opt-in-off" · "no-answer"
+  shares?: string[];            // 014: the shares a null session listed
+  certAudit?: object;           // the TLS-certificate audit (040) of this port — its issues[] graded at 040's own grades
+  tribeHealth?: object;         // the debug-endpoint audit (050), on the 8080 record — { state, severity, findings[] }
+  dnsSecurity?: object;         // the DNS-security audit (060) of a DOMAIN-NAME target — here on a 53/udp record, else in the conclusion's evidence[]; absent for an IP-address target, which 060 declines (manifest: skipped, with the reason) — NOT TESTED, never clean
   weakAlgorithms?: string[];    // SSH weak key-exchange, cipher and MAC names, together in one array (002)
   weakCiphers?: string[];       // TLS weak ciphers (the negotiated cipher per version)
   certSelfSigned?: boolean;     // TLS certificate is self-signed (011)
@@ -169,7 +184,8 @@ export default {
     //   tcpOpen: Set<number>,          // TCP ports found open by the plugins that ran before this one
     //   udpOpen: Set<number>,          // UDP ports, likewise
     //   pluginRunStatus: Map,          // id -> "ran" | "timeout" | "error" | "skipped" for each earlier plugin
-    //                                  //   dispatched; one skipped on its requirements has no entry
+    //                                  //   the scan selected — one skipped on its requirements or a missing
+    //                                  //   capability reads "skipped"; no entry = the plugin was never requested
     //   effectiveTimeoutMs: number,    // the budget the manager races this run() against
     // }
     return {
@@ -277,7 +293,7 @@ never writes a queue. A CVE row, which carries every field:
 
 **Every row:** `id` · `category` · `status` · `title` · `severity` · `cvss` · `target` · `evidence` · `remediation` · `riskScore`
 
-**Most rows:** `description` — the analysis agents' own findings omit it: `auth_agent` · `config_agent` · `crypto_agent` · `exposure_agent` · `service_agent`. The CVE engine's rows and every coverage-gap record carry it.
+**Most rows:** `description` — three analysis agents' own findings omit it: `auth_agent` · `config_agent` · `crypto_agent`. The CVE engine's rows, the exposure agent's rows (since Enterprise 1.3.0: the service its title no longer names), the service agent's rows (since Enterprise 1.3.0: the version its title no longer names) and every coverage-gap record carry it.
 
 **CVE-bearing rows, once KEV / EPSS data is loaded:** `kev` · `knownRansomwareCampaignUse` · `kevMatchedCve` · `kevAsOf` · `kevStoreState` · `epssScore` · `epssPercentile` · `epssMatchedCve` · `epssAsOf` · `epssModelVersion` · `epssStoreState` · `exploitPriority` · `exploitPriorityReason`
 
@@ -358,27 +374,30 @@ the installed Community's. The file is written to the output directory as `scan_
         "informationUri": "https://github.com/nsasoft/nsauditor-ai",
         "rules": [
           { "id": "vsftpd:3.0.5", "shortDescription": { "text": "ftp service detected" },
-            "helpUri": "https://github.com/nsasoft/nsauditor-ai", "properties": { "severity": "Medium" } },
+            "helpUri": "https://github.com/nsasoft/nsauditor-ai", "properties": { "severity": "Info" } },
           { "id": "ftp-anonymous-login", "shortDescription": { "text": "FTP anonymous login enabled" },
             "helpUri": "https://github.com/nsasoft/nsauditor-ai", "properties": { "severity": "Critical" } }
         ]
       }
     },
     "results": [
-      { "ruleId": "vsftpd:3.0.5", "level": "warning",
+      { "ruleId": "vsftpd:3.0.5", "level": "note",
         "message": { "text": "Service ftp detected on 192.168.1.1:21/tcp. Program: vsftpd. Version: 3.0.5. Status: open" },
         "locations": [{ "physicalLocation": { "artifactLocation": { "uri": "192.168.1.1" } } }] },
       { "ruleId": "ftp-anonymous-login", "level": "error",
-        "message": { "text": "FTP anonymous login is enabled on 192.168.1.1:21. This allows unauthenticated access to the FTP server." },
+        "message": { "text": "FTP anonymous login enabled on 192.168.1.1:21/tcp. ftp on 192.168.1.1:21/tcp accepts anonymous authentication." },
         "locations": [{ "physicalLocation": { "artifactLocation": { "uri": "192.168.1.1" } } }] }
     ]
   }]
 }
 ```
 
-The file carries one result per service (`warning` when open, `note` otherwise) plus anonymous FTP login, zone transfer
-and weak SSH algorithm results — no TLS, SNMP, MCP, CVE or analysis-agent results. Anonymous FTP and zone transfer
-appear only when `FTP_CHECK_ANON` / `DNS_CHECK_AXFR` enabled those checks.
+The file carries one `note` result per service (an open port is inventory) plus one result per graded service-check
+finding — the same findings, at the same grades, that `--fail-on` and the Markdown report read
+(`references/workflows.md` §4), the TLS, SNMP, MCP, certificate, SMB null-session and 040 / 050 / 060 audit results
+included — and no CVE or analysis-agent results. Anonymous FTP, zone transfer and the SMB null session appear only when
+`FTP_CHECK_ANON` / `DNS_CHECK_AXFR` / `SMB_NULL_SESSION` enabled those checks. The rule ids of the four flags SARIF
+graded before Community 0.2.57 are unchanged.
 
 #### SARIF Severity Mapping
 
@@ -445,5 +464,10 @@ Every scan appends one line per host to `scan_history.jsonl` in its output direc
   or resolved findings.
 - `cloudFindingsCount` is the raw number of findings the plugins returned (evidence gaps and scope
   statements included); `findingsCount` is the report loader's shaped count, so the raw figure can exceed it.
+- Since Community 0.2.57 a line also carries `flagsBasis` (`"service-flags-v1"`), `hostFlags` and `hostChecks` (a
+  domain's DNS-security audit), and each service entry `flags` (the comparison identity of each service-check finding,
+  e.g. `"weakAlgorithms:diffie-hellman-group1-sha1"`) and `checks` (per check that applies, `true` when measured, else
+  the reason it was not). The `[ScanHistory]` diff reads them: a finding gone reads CLEARED only where its check was
+  measured this run, else NOT COMPARED with the reason. The two example lines above were written before them.
 - Retention: Community keeps **7 days** (older lines are pruned after each scan); Pro and Enterprise keep
   every line. Neither is configurable.

package/references/workflows.md

@@ -8,7 +8,8 @@ Multi-step patterns for common security audit scenarios.
 
 The most common MCP workflow: a scan followed by a CVE lookup per service. It is NOT the CLI's full analysis: the
 Enterprise analysis agents and exploit intelligence run only in `nsauditor-ai scan --host <target>` (Enterprise package +
-Pro/Enterprise licence), and `scan_host` does not return the 040 / 050 / 060 auditors' findings (use `probe_service`).
+Pro/Enterprise licence). `scan_host` does return the 040 / 050 / 060 audits (`certAudit`, `tribeHealth`, and
+`dnsSecurity` for a domain-name target — 060 declines an IP address, and the `markdown` says it was not tested).
 
 ```
 Step 1: list_plugins()
@@ -123,25 +124,34 @@ and avoid network congestion. The MCP server processes one scan at a time.
 
 ## 4. CI/CD Pipeline Integration
 
-`--fail-on <severity>` reads FOUR service flags, and it is **not computed from the SARIF file** — the two read the same
-flags but grade them differently:
+`--fail-on <severity>` reads every finding the shared service-check table grades — one per item (a method, an
+algorithm, a protocol, a cipher, an audit entry), the same findings at the same grades that the Markdown report, the
+SARIF file and the CSV count. It is **not computed from the SARIF file**, but the two read one table, so they cannot
+grade a finding differently:
 
-| Flag in the scan's conclusion | `--fail-on` grade | SARIF level |
+| Finding in the scan's conclusion | `--fail-on` grade | SARIF level |
 |---|---|---|
 | anonymous FTP login · DNS zone transfer — tested only with `FTP_CHECK_ANON=true` / `DNS_CHECK_AXFR=true` + `DNS_AXFR_DOMAIN`, both off by default | critical | error |
-| weak SSH algorithms | medium | warning |
-| dangerous HTTP methods — read, but they never reach the conclusion in this release (the HTTP probe's result is not carried onto a service record) | medium | warning |
-| any service in a concluded scan | info — so `--fail-on info` fails every scan that concludes | `warning` when open, `note` otherwise |
-
-So on a default scan `--fail-on high` and `--fail-on critical` never exit 1, and `--fail-on medium` fires only on weak
-SSH algorithms. Neither the gate nor the SARIF file reads the SNMP default community, weak TLS protocols / ciphers, a
-self-signed certificate, the MCP server checks, the TLS-certificate / DNS-security / debug-endpoint auditors,
-Enterprise's CVE rows or analysis-agent findings (the Markdown report counts the SNMP community and weak TLS protocols /
-ciphers, but not the MCP server checks; none of them gates). Exit 0 is NOT a clean host.
+| MCP server reachable without authentication · MCP server lists its tools without authentication | critical | error |
+| MCP server over cleartext HTTP · MCP server on a deprecated protocol version | high | error |
+| SNMP default community (`public` / `private`) | high | error |
+| SMB null session — tested only with `SMB_NULL_SESSION=true`; graded high provisionally | high | error |
+| expired certificate, on a port the TLS-certificate auditor (040) did not audit | high | error |
+| weak SSH algorithms · weak TLS protocols · weak TLS ciphers, one per item | medium | warning |
+| dangerous HTTP methods, one per method — only where an Allow header was read | medium | warning |
+| self-signed certificate, on a port 040 did not audit · MCP Inspector exposed | medium | warning |
+| each actionable entry of the TLS-certificate, debug-endpoint and DNS-security audits (040 / 050 / 060) | the auditor's own grade | by that grade |
+| any concluded scan; an open service is inventory | info — so `--fail-on info` fails every scan that concludes | `note`, one per service |
+
+So a default scan can exit 1 at `--fail-on high` — an SNMP default community, an MCP server finding, an expired
+certificate or a HIGH audit entry is enough — and a pipeline that passed on an earlier Community may fail on findings
+that were always there. One expired certificate is graded once: High where only the TLS scanner (011) saw it,
+Critical where 040 audited it. The gate does not read Enterprise's CVE rows or analysis-agent findings. Exit 0 is NOT a
+clean host.
 
 ```bash
-# Scan with SARIF output and severity gating. --fail-on high fires only on anonymous FTP / zone transfer:
-# set FTP_CHECK_ANON=true and DNS_CHECK_AXFR=true + DNS_AXFR_DOMAIN=<zone> first, or it never exits 1.
+# Scan with SARIF output and severity gating. --fail-on high exits 1 on any graded finding at high or above (table
+# above); anonymous FTP and zone transfer are graded only with FTP_CHECK_ANON=true / DNS_CHECK_AXFR=true + DNS_AXFR_DOMAIN.
 nsauditor-ai scan --host $TARGET \
   --plugins all \
   --output-format sarif \
@@ -149,8 +159,8 @@ nsauditor-ai scan --host $TARGET \
   --out ./nsauditor-out
 
 # Exit codes:
-#   0 = no gated flag at or above the threshold — NOT a clean host
-#   1 = a gated flag at or above the threshold
+#   0 = no graded finding at or above the threshold — NOT a clean host
+#   1 = a graded finding at or above the threshold
 #   2 = unknown severity, or no scan produced a conclusion
 ```
 
@@ -162,7 +172,7 @@ SARIF file.
 
 ```yaml
 - name: Security Scan
-  env:   # without these, --fail-on high can never exit 1 (both checks are off by default)
+  env:   # both checks are off by default; without these --fail-on high never sees anonymous FTP or a zone transfer
     FTP_CHECK_ANON: "true"
     DNS_CHECK_AXFR: "true"
     DNS_AXFR_DOMAIN: example.com   # the zone to try transferring
@@ -184,7 +194,8 @@ SARIF file.
 ## 5. Continuous Monitoring (CTEM)
 
 Watch mode: every host is re-scanned on an interval and each scan is compared with that host's previous one. Its
-webhook alert does NOT fire on a service change in this release — read what triggers it before offering it.
+webhook alerts a host whose scan changed and that carries a finding at or above `--alert-severity` — read what
+triggers it before offering it.
 
 ```bash
 # NSA_ALLOW_ALL_HOSTS=1 because the range is private (§3). Replace the webhook URL with your own PUBLIC one: the
@@ -200,24 +211,33 @@ NSA_ALLOW_ALL_HOSTS=1 nsauditor-ai scan --host 192.168.1.0/24 --plugins all \
 **Features:**
 - Rescans on configurable interval (minutes; default 60); the first cycle runs at once
 - Each host's scan is compared with that host's previous line in `scan_history.jsonl` and printed as a
-  `[ScanHistory]` line: new, removed and changed services, and the findings delta
+  `[ScanHistory]` line: new, removed and changed services, the findings delta, and each service-check finding that
+  appeared, cleared, was first observed or could not be compared (with the reason)
 - Scan history appended to `scan_history.jsonl` in the output directory (`--out`, default `out/`), one line per host
 - CE: 7-day retention; Pro/Enterprise: every line kept (neither is configurable)
 
-**What triggers the webhook — and what does not:**
-- A service, version or finding change does NOT. The cycle comparison the alert is gated on finds no services in
-  the scan results it is handed, so its `=== Delta Report ===` shows no change for any host. The gate opens only
-  when a cycle scanned a different set of hosts from the cycle before (in practice, a cycle cut short by stopping
-  the loop), and never on the first cycle. For changes, read the `[ScanHistory]` lines.
-- When the gate opens, an alert (a JSON POST) goes out for each host whose services carry a flag at or above
-  `--alert-severity` (default `high`; at `info` every service counts, flagged or not): anonymous FTP login or DNS
-  zone transfer (critical; both checks are off unless `FTP_CHECK_ANON=true` / `DNS_CHECK_AXFR=true` +
-  `DNS_AXFR_DOMAIN` are set) and weak SSH algorithms (medium). Dangerous HTTP methods never reach a service record
-  (§4) and nothing on the scan path fills a service's CVE list, so at `high` only the two opt-in checks count.
-- The payload is not redacted: the host and its flagged services go in the clear to the URL you supply.
-
-**Webhook Payload** (the change itself is NOT in it; `details` lists the host's flagged services, and each
-detail's `severity` is the `--alert-severity` value, not the flag's own grade):
+**What triggers the webhook:**
+- A host alerts when its scan CHANGED since the previous cycle — a service appeared, went or changed, its finding
+  count moved, a service check alone changed, or the comparison could not be made — AND it carries at least one
+  finding at or above `--alert-severity` (default `high`). The first cycle sets the baseline and alerts nobody;
+  `--alert-every-cycle` alerts every host carrying such a finding on every cycle, the first included. Stdout prints
+  each host's change under `=== Delta Report ===`, and `No significant changes detected.` only when no host changed.
+- The findings are the service-check findings `--fail-on` and the reports grade (§4): anonymous FTP login or a DNS
+  zone transfer (critical; both off unless `FTP_CHECK_ANON=true` / `DNS_CHECK_AXFR=true` + `DNS_AXFR_DOMAIN` are
+  set), the MCP server checks, an SNMP default community, an expired certificate, an SMB null session (off unless
+  `SMB_NULL_SESSION=true`), weak SSH algorithms and weak TLS protocols / ciphers, dangerous HTTP methods where an Allow
+  header was read, a self-signed certificate, and each 040 / 050 / 060 audit entry at its own grade. Enterprise's CVE
+  rows and analysis-agent findings are not among them, so they never trigger an alert.
+- A host whose scan failed, or whose summary is missing on either side, is reported not comparable on stdout — never
+  "No changes", never "removed" — and does not alert in this release.
+- Watch mode scans each distinct host once per cycle: a repeated `--host` entry, or one also inside a listed CIDR, is
+  dropped, and the banner says how many.
+- The payload is not redacted: the host and its findings go in the clear to the URL you supply.
+
+**Webhook Payload** (the change itself is NOT in it: `details` carries one entry per finding at or above
+`--alert-severity` — `description` is the finding's title and `severity` its own grade, lower-case; a finding with no
+port, such as a domain's DNS-security entry that landed in the conclusion's evidence, carries `port` and `protocol`
+null. The top-level `severity` is the `--alert-severity` value):
 
 ```json
 {
@@ -226,7 +246,7 @@ detail's `severity` is the `--alert-severity` value, not the flag's own grade):
   "severity": "high",
   "findingsCount": 1,
   "summary": "1 finding(s) detected on 192.168.1.20 at severity high or above",
-  "details": [{ "port": 21, "protocol": "tcp", "service": "ftp", "description": null, "severity": "high" }]
+  "details": [{ "port": 21, "protocol": "tcp", "service": "ftp", "description": "FTP anonymous login enabled", "severity": "critical" }]
 }
 ```
 
@@ -302,7 +322,7 @@ port or probe not measured, a CVE lookup that failed, an agent that did not run,
 changing under the same program and version — as RESOLVED. `report --since` reads each of those as
 NOT COMPARABLE with its reason, refuses the comparison outright when either run's chain is altered or cannot be
 measured (naming which side), and says what it did not evaluate.
-A finding on a port, region or producer a scan did not measure is not counted as fixed, and with SLA tracking on the control it failed is held FAILED. Two measured limits in this release: after a CVE lookup that failed, the prior CVE rows are not counted as fixed, but the controls they failed are not held FAILED and can read PASS; and when two compared scans ran different `--plugins` sets, a row an analysis agent or the CVE mapper derived from a plugin only one of them requested can read RESOLVED or NEW. When the later scan left the plugin out, the row also counts as closed in MTTR and its control can read PASS. Keep `--plugins` identical between compared scans.
+A finding on a port, region or producer a scan did not measure is not counted as fixed, and with SLA tracking on the control it failed is held FAILED — including the prior CVE rows on a service whose lookup failed, the CVE mapper's and the service agent's rows on a TCP port whose service the scan could not identify, and an analysis agent's or the CVE mapper's rows when a plugin they read was left out of the scan or did not complete. Two measured limits: a scan made before EE 1.3.0 could not record a plugin left out of it, so in a comparison with one, an agent's row that scan lacks is not refused — the report's Basis cell says so on the row; and a scan that discovered ports with the Nmap plugin (024) alone records no port oracle, so an analysis agent's or the CVE mapper's row on a port it did not measure can read RESOLVED and count as closed in MTTR, and the control it failed can read PASS — include the port scanner (003).
 
 Read from its output:
   - New findings (unexpected exposure) — it compares FINDINGS, not services: a newly exposed service appears only if
@@ -322,13 +342,17 @@ User wants to...
 ├── Check a specific service/port       → probe_service (Pro)
 ├── Look up CVEs for software version   → get_vulnerabilities (Pro)
 ├── See available plugins               → list_plugins
-├── Audit TLS certificates              → probe_service (Pro) with plugin 040 (scan_host RUNS it but does not return its findings)
-├── Check DNS security (SPF/DKIM/DMARC) → probe_service (Pro) with plugin 060 (scan_host RUNS it but does not return its findings)
-├── Detect debug leaks / CORS issues    → probe_service (Pro) with plugin 050 (scan_host RUNS it but does not return its findings)
+├── Audit TLS certificates              → probe_service (Pro) with plugin 040, one port — or scan_host:
+│                                         `certAudit` on each port 040 audited
+├── Check DNS security (SPF/DKIM/DMARC) → probe_service (Pro) with plugin 060 — or scan_host on the domain name:
+│                                         `dnsSecurity` (on the 53/udp record, else in the conclusion's evidence)
+├── Detect debug leaks / CORS issues    → probe_service (Pro) with plugin 050 — or scan_host: `tribeHealth`,
+│                                         only when TCP 8080 is open
 ├── Scan a subnet                       → CLI: --host CIDR --parallel N
 │                                         (a private range needs NSA_ALLOW_ALL_HOSTS=1 — §3)
 ├── Set up continuous monitoring         → CLI: --watch --interval N
-│                                         (its webhook does NOT fire on a service change in this release — §5)
+│                                         (its webhook alerts a changed host carrying a finding at or above
+│                                         --alert-severity; never on the first cycle — §5)
 ├── Compare two scans                   → CLI (Pro): nsauditor-ai report --from <dir> --format executive --since prior
 │                                         (not MCP; NEVER by hand)
 ├── State framework COVERAGE            → compliance_matrix (any tier)