nsauditor-ai-agent-skill 0.2.46 → 0.2.48

package/CHANGELOG.md

@@ -4,6 +4,43 @@ Release notes for **`nsauditor-ai-agent-skill`** — installable knowledge packa
 
 ---
 
+## 0.2.48 (2026-09-02) — paired with EE 0.43.0: teach what a provider badge means, and what an evidence gap must not say
+
+**Two teaching changes, both about how to READ a scan rather than how to run one.**
+
+**A provider badge is now trustworthy, and the assistant should say why it was not.** Until
+EE 0.43.0, an Enterprise scan whose cloud SDK failed to load reported that provider as
+**audited** — eighteen refusals across seventeen AWS and GCP plugins returned `up: false` with
+the cause written only into `warnings`, and the Community plugin manager derives
+`auditedProviders` from plugins that *ran*. Teach: **`auditedProviders` and `providerStatus`
+are now answerable questions** — `{ran, skipped, errored}` per provider — and a cloud whose SDK
+is missing appears as `errored`, not as audited. If a user reports a provider missing from
+`auditedProviders` after upgrading, that is the fix working, not a regression.
+
+**An evidence gap states a CAUSE, never an instruction.** The engine quotes a plugin's reason
+into the *"could not run"* sentence of every control that plugin evidences. It used to quote the
+whole thrown message, and the SDK loaders throw remediation inside it, so `Install: npm install
+<pkg>@latest` reached the gap text of 7 SOC 2, 2 GDPR and 12 NIST SP 800-171 controls. Teach the
+split: **the report says what was not evidenced; the operator channel says how to change it** —
+and never quote an evidence-gap line to a user as a remediation step. ⚠️ Especially for
+**air-gapped** deployments, where an `npm install` instruction cannot be followed at all.
+
+**Also taught:** the two causes are now distinct in the gap text — `plugin skipped: <reason>`
+(fix with `--host` / `CLOUD_PROVIDER`) versus `scanner error: <cause>` (fix a dependency or a
+credential); and a GDPR Art. 32 report now fails closed when an Azure scan refuses, where it
+previously failed nothing. Plugin catalog UNCHANGED at 29 EE; all eight coverage matrices
+UNCHANGED; **peer floor UNCHANGED at CE >= 0.2.49** — not a bump.
+
+## 0.2.47 (2026-08-27) — paired with EE 0.42.0: the sovereign-cloud release
+
+Requires **CE >= 0.2.49** (raised from 0.2.45 — Enterprise 0.42.0 needs the new partition detection).
+
+- **Teaches that non-commercial AWS partitions and Azure sovereign clouds are first-class.** An agent driving a GovCloud, China, ISO or European-Sovereign scan should expect findings that previously read clean: public S3 access points riding a bucket delegation, IAM privesc at CRITICAL rather than HIGH, shadow-admin graph edges that were absent, and the full effective-decrypt severity ladder.
+- **Teaches the Azure cloud selectors and, more importantly, the REFUSAL.** `AZURE_ENVIRONMENT` / `ARM_ENVIRONMENT` / `AZURE_ARM_ENDPOINT` / `AZURE_AUTHORITY_HOST` select the cloud; an unrecognised or contradicted selection refuses and emits an evidence gap. An agent must not treat that refusal as a scan failure to retry past — it is the product declining to report on an estate the operator did not select.
+- **Teaches the subject stamp.** Every Azure scan states which estate it addressed. An agent summarising a clean Azure result should name the estate, because a clean report about the wrong estate looks exactly like a clean report.
+- **Teaches the FIPS boundary.** `docs/fips-posture.md` claims approved *algorithms* and explicitly not a validated *module*; an agent must never let a user infer FIPS 140 validation from it.
+- Plugin count **UNCHANGED at 29**; all eight coverage matrices **UNCHANGED**.
+
 ## 0.2.46 (2026-08-26) — paired with EE 0.41.0: the DocumentDB plugin reaches the skill's teaching
 
 **Requires CE >= 0.2.45 — UNCHANGED.** Paired with **Enterprise 0.41.0 / Community 0.2.48**.

package/README.md

@@ -11,7 +11,22 @@ Works with **Claude Code**, **Claude Desktop**, **Cursor**, **Windsurf**, **VS C
 
 ## Current release
 
-**0.2.46** — paired with **Enterprise 0.41.0 / Community 0.2.48**. New in this release's teaching: the 29th Enterprise plugin, `1230 AWS DocumentDB Auditor` (docdb-engine ownership on the shared RDS control plane — encryption + custody, `tls`, audit logging + export, retention, deletion protection, replica/AZ topology, snapshot sharing), the RDS auditor's engine filter with its standing disclosure (a Neptune estate is explicitly unaudited), and the deferred status of DocumentDB Elastic clusters. Prior: **0.2.45** — paired with **Enterprise 0.40.3 / Community 0.2.47**. New in this release's teaching: on
+**0.2.48** — paired with **Enterprise 0.43.0 / Community 0.2.50**. ⚠️ **NOT a floor bump: Community stays >= 0.2.49**, derived rather than reflexive — the one Community behaviour the Enterprise fix depends on already shipped there. New in this release's teaching: **a provider badge is now trustworthy** (an Enterprise scan whose cloud SDK failed to load used to report that provider as *audited*, because a plugin result carrying neither an error nor a skip flag falls through to `ran` and `auditedProviders` derives from `ran`; eighteen refusals across seventeen AWS and GCP plugins now carry their cause, so such a provider reads `errored` and drops out — a provider disappearing after upgrade is the fix, not a regression), and **an evidence gap states a cause, never an instruction** (the engine quoted whole thrown messages, so the loaders' `Install: npm install <pkg>@latest` reached the gap text of 7 SOC 2 / 2 GDPR / 12 NIST SP 800-171 controls — never quote a gap line to a user as remediation, and note that under air-gapped operation it cannot be followed at all). The two causes are now distinct — `plugin skipped:` vs `scanner error:` — because the remedies differ; and a GDPR Art. 32 report now fails closed on an Azure refusal where it previously failed nothing.
+
+**Prior: 0.2.47** — paired with **Enterprise 0.42.0 / Community 0.2.49**. ⚠️ **A real floor bump: Community >= 0.2.49.**
+New in this release's teaching: non-commercial AWS partitions (GovCloud, China, the ISO partitions and
+the European Sovereign Cloud) and Azure sovereign clouds are first-class, and both **refuse rather than
+silently reporting on the wrong estate**. An agent driving a sovereign scan should expect findings that
+previously read clean — a public S3 access point riding a bucket delegation, IAM privesc at CRITICAL
+instead of HIGH, shadow-admin graph edges that were missing, the full effective-decrypt severity ladder.
+For Azure, `AZURE_ENVIRONMENT` / `ARM_ENVIRONMENT` / `AZURE_ARM_ENDPOINT` / `AZURE_AUTHORITY_HOST` select
+the cloud, an unrecognised or self-contradicting selection **refuses and emits an evidence gap**, and
+every Azure scan **states which estate it addressed** — an agent summarising a clean Azure result should
+name the estate, because a clean report about the wrong estate looks exactly like a clean one. Also
+taught: the FIPS boundary (approved *algorithms*, explicitly not a validated *module*) and the SBOM gate.
+Plugin count **unchanged at 29**; all eight coverage matrices **unchanged**.
+
+**Prior: 0.2.46** — paired with **Enterprise 0.41.0 / Community 0.2.48**. New in this release's teaching: the 29th Enterprise plugin, `1230 AWS DocumentDB Auditor` (docdb-engine ownership on the shared RDS control plane — encryption + custody, `tls`, audit logging + export, retention, deletion protection, replica/AZ topology, snapshot sharing), the RDS auditor's engine filter with its standing disclosure (a Neptune estate is explicitly unaudited), and the deferred status of DocumentDB Elastic clusters. Prior: **0.2.45** — paired with **Enterprise 0.40.3 / Community 0.2.47**. New in this release's teaching: on
 the **opt-in** RFC 3161 path (`NSAUDITOR_TSA_URL`; no default authority), a granted token that attests
 a DIFFERENT digest than the request carried is now refused (`tsa_imprint_mismatch`); the auditor
 instruction printed on every timestamped report is corrected to one that actually runs; and a
@@ -177,7 +192,7 @@ This package provides **knowledge about** NSAuditor AI. To actually **run** scan
 |---------|-------|-----------|
 | **Community** | Free / MIT | 27 plugins (service probes + host/network discovery + intelligence/meta), basic AI, SARIF, CTEM, scan history |
 | **Pro** | $49/mo | + CVE matching, risk scoring, and intelligence-enriched AI prompts (CVE + MITRE ATT&CK context injected) |
-| **Enterprise** | $2k+/yr | + 28 enterprise plugins (1020-1222 range) — 27 cloud-substrate auditors across AWS / Azure / GCP plus `1023 Zero Trust Assessment`, which scores zero-trust posture from a NETWORK-host scan and does not run on a cloud pass, multi-framework evidence-pack (SOC 2 / HIPAA / NIST CSF 2.0 / PCI DSS v4.0.1 / ISO 27001:2022 / CIS Controls v8 / GDPR Art. 32 / NIST SP 800-171 Rev 2), SHA-256 chain-of-custody attestations, the suppression-approval CLI with opt-in Ed25519 signing (reachable from EE 0.35.0, proven 0.36.0, verified per approver holding key material), air-gapped operation (offline licensing + offline CVE matching) |
+| **Enterprise** | $2k+/yr | + 29 enterprise plugins (1020-1230 range) — 28 cloud-substrate auditors across AWS / Azure / GCP plus `1023 Zero Trust Assessment`, which scores zero-trust posture from a NETWORK-host scan and does not run on a cloud pass, multi-framework evidence-pack (SOC 2 / HIPAA / NIST CSF 2.0 / PCI DSS v4.0.1 / ISO 27001:2022 / CIS Controls v8 / GDPR Art. 32 / NIST SP 800-171 Rev 2), SHA-256 chain-of-custody attestations, the suppression-approval CLI with opt-in Ed25519 signing (reachable from EE 0.35.0, proven 0.36.0, verified per approver holding key material), air-gapped operation (offline licensing + offline CVE matching) |
 
 → [Pricing](https://www.nsauditor.com/ai/pricing/)
 

package/SKILL.md

@@ -16,14 +16,44 @@ description: >
 
 # NSAuditor AI — Agent Skill
 
-> **Version:** 0.2.46 (knowledge current as of **EE 0.41.0** · **requires CE ≥ 0.2.45**) — the DocumentDB release.
+> **Version:** 0.2.48 (knowledge current as of **EE 0.43.0** · **requires CE ≥ 0.2.49**) — the provider-status release.
 >
-> **What this release (EE 0.41.0) teaches:** **The 29th Enterprise plugin — `1230 AWS DocumentDB Auditor` — owns the `docdb` engine on the shared RDS control plane.** Teach these three facts together: (1) a `--host aws` pass now includes DocumentDB cluster security — storage encryption + KMS custody, the `tls` cluster parameter, `audit_logs` + CloudWatch export, backup retention, deletion protection, replica/AZ topology (DocumentDB availability is replicas across AZs; the per-instance Multi-AZ flag does not apply and the plugin never consults it), and manual-snapshot public/cross-account restorability; (2) the RDS auditor (1140) engine-filters DocumentDB and Neptune out of every path with counted skips and a standing deferred-scope disclosure — when a user asks about Neptune, the honest answer is that **a Neptune estate is UNAUDITED by every plugin**, and the report says so itself; (3) DocumentDB ELASTIC clusters ride a separate API and are a declared deferred scope, not covered. Plugin count 28 → 29; all eight coverage matrices UNCHANGED.
+> **What EE 0.43.0 taught, and both items are about READING a scan rather than running one.**
+> **(1) A provider badge is now trustworthy, and it was not before.** An Enterprise scan whose
+> cloud SDK failed to load reported that provider as **audited**: eighteen refusals across
+> seventeen AWS and GCP plugins returned `up: false` with the cause written only into
+> `warnings`, and the Community plugin manager derives `auditedProviders` from plugins that
+> *ran* — an envelope carrying neither an error nor a skip flag falls through to *ran*. Teach
+> that `providerStatus` is now answerable per provider (`{ran, skipped, errored}`) and that a
+> provider DISAPPEARING from `auditedProviders` after upgrade is the fix working, not a
+> regression. ⚠️ Compliance verdicts always failed closed, so **never tell a user their controls
+> were passing over an unscanned estate** — they were not; the badge and the reason were wrong,
+> not the verdicts.
+> **(2) An evidence gap states a CAUSE, never an instruction.** The engine quotes a plugin's
+> reason into the *"could not run"* sentence of every control that plugin evidences, and it used
+> to quote the whole thrown message — so the loaders' own `Install: npm install <pkg>@latest`
+> reached the gap text of 7 SOC 2, 2 GDPR and 12 NIST SP 800-171 controls. ⚠️ **NEVER quote an
+> evidence-gap line to a user as a remediation step**, and be aware the old wording is still in
+> packs produced before 0.43.0. Under **air-gapped operation** an `npm install` instruction
+> cannot be followed at all, which is why it was the wrong channel. The two causes are now
+> distinct: `plugin skipped: <reason>` (fix with `--host` / `CLOUD_PROVIDER`) versus
+> `scanner error: <cause>` (fix a dependency or a credential).
+> Also: a GDPR Art. 32 report now fails closed when an Azure scan refuses, where it previously
+> failed nothing. Plugin catalog UNCHANGED at 29 EE; all eight coverage matrices UNCHANGED;
+> **peer floor UNCHANGED at CE ≥ 0.2.49** — derived, not a bump.
+>
+> **What this release (EE 0.42.0) teaches:** **Non-commercial AWS partitions and Azure sovereign clouds are now first-class, and both REFUSE rather than silently reporting on the wrong estate.** When you drive a scan against GovCloud, China, an ISO partition or the European Sovereign Cloud, findings that previously read CLEAN now fire: a public S3 access point riding a bucket delegation, IAM privilege-escalation at CRITICAL (it demoted to HIGH before), shadow-admin graph edges that were missing entirely, and the full effective-decrypt severity ladder (it collapsed to `info`). **THE ID→DEFECT MAPPING, HERE ON THE ALWAYS-LOADED SURFACE because a reader asked for it BY ID got "no source confirming there was a partition-side fix" while it sat in an on-demand reference (measured 2026-08-28):** `1020` S3 access point riding a bucket delegation · `1030` IAM privesc severity + shadow-admin edges · `1110` KMS effective-decrypt ladder · `1050` API Gateway policy classification + SSRF parsers · `1200` alerting-destination liveness · `1040` region denominator. ⚠️ Do NOT attribute the S3 case to `1110` or the decrypt ladder to `1050` — those are the pre-fix misattributions. Pre-0.42.0 non-commercial reports are unproven on THOSE FAMILIES; findings outside them stand. For Azure, `AZURE_ENVIRONMENT` / `ARM_ENVIRONMENT` / `AZURE_ARM_ENDPOINT` / `AZURE_AUTHORITY_HOST` now select the cloud — and an unrecognised or self-contradicting selection **refuses the scan and emits an evidence gap naming the variable that fixes it**, because falling back to commercial is how an operator holding both commercial and sovereign credentials gets a real, clean-looking report about an estate they did not mean. **Every Azure scan stamps the estate it addressed — but WHERE it lands is channel-specific and the Desktop channel does NOT carry it.** On the CLI/report path the stamp rides the evidence stream and the concluder summary. Through MCP it does NOT: `get_findings` iterates `result.findings` with no `result.data` fallback, and the cloud summariser short-circuits on a non-nullish `findings[]` (an EMPTY array is non-nullish, so a genuinely clean Azure scan — the exact case you would want it for — still never reaches `data[]`). **So on Desktop you CANNOT name the estate on a clean Azure result: say that you cannot confirm which estate was addressed and that the operator must check the CLI or the selector variables — never guess one.** On the REFUSAL path the estate IS visible, because it is written into the gap finding's own text. Also new: the SBOM gate (`npm run gate:sbom`) emits CycloneDX/SPDX over *the installed package* rather than the source tree — ⚠️ **but it is a MAINTAINER-side repository script: `scripts/` ships ZERO files in the customer tarball, so an installed package CANNOT run that command** (the npm script entry ships; the script it points at does not). **Never hand `npm run gate:sbom` to an end user as something to run against their install** — that is a published instruction that cannot succeed; the SBOM is generated from a repository checkout and provided on request. And `docs/fips-posture.md` states approved *algorithms*, explicitly not a validated *module* — do not let a user infer FIPS 140 validation from it; whether the RUNTIME beneath the product is a validated module is a property of the operator's platform, not of this product. **Plugin count UNCHANGED at 29; all eight coverage matrices UNCHANGED.**
 
-> **Prior:** 0.2.45 (post-EE-0.40.3 · **requires CE ≥ 0.2.45**) — the message-imprint release.
+> **Prior:** 0.2.47 (post-EE-0.42.0 · **requires CE ≥ 0.2.49**) — the sovereign-cloud release.
+>
+> **Prior:** 0.2.46 (post-EE-0.41.0 · **requires CE ≥ 0.2.45**) — the DocumentDB release.
 >
 > ⛔ **If tool output reports an EE version NEWER than the knowledge bound above, say this skill's knowledge does not yet cover that version — never guess at capabilities it might add.**
 >
+> ⛔ **THE MIRROR RULE — when the REGISTRY lags this skill's knowledge bound.** If npm (or `npm view`) does not yet list the EE version named in the knowledge bound above, that version is **STAGED, not nonexistent** — this skill is rebuilt at staging, before publish, so the registry lagging the bound is the NORMAL pre-release state, not a contradiction to resolve. **The registry answers what is PUBLISHED; this skill answers what a version CONTAINS.** Asked what that version fixed, changed or contains, answer from this skill and state the publication status beside it ("per the registry, 0.42.0 is not yet published") — **never deny the content exists because the registry has not caught up, and never let a registry check override this mapping.** (Measured 2026-08-28: asked for the partition-fix plugin ids, an agent checked npm first, found the version unpublished, and answered "I have no source confirming there was a partition-side fix" — a true registry fact converted into a false content claim.)
+>
+> ⛔ **THE CAP ON BOTH RULES:** if ANY source — tool output **or the user's own words** — names an EE version NEWER than the knowledge bound above, this skill's knowledge stops at the bound: say so, do not guess, and do not apply this release's mapping to that newer version.
+>
 > **What EE 0.40.3 taught:** **A timestamp for a DIFFERENT artifact is no longer accepted as yours.** RFC 3161 timestamping stays **opt-in** (`NSAUDITOR_TSA_URL`; no default authority). When enabled, a granted token carries a `messageImprint` — the digest it attests — and nothing compared it to the digest our request carried, so a replay, a caching proxy or an authority fault could return a valid timestamp for someone else's bytes and it was written as evidence, while the auditor's own `openssl ts -verify` printed `message imprint mismatch` → FAILED over it. Refused now, before any write, as **`tsa_imprint_mismatch`**, naming both digests. Two more codes join it: **`tsa_response_malformed`** (bytes RFC 3161 does not admit inside the response; openssl refuses such a file outright) and **`tsa_token_unreadable`** (neither this reader nor openssl could decode the token). **Eight refusal codes** total. ⚠️ **Teach the OPPOSITE direction too, because it is a LOOSENING and a user may report it as a change:** a **BER-encoded** token is no longer refused when openssl can read it. 0.40.2 refused those outright; CMS permits BER and `openssl ts -verify` accepts them, so the old behaviour discarded genuine evidence from authorities whose stacks nobody here has surveyed. A refusal now requires **both** readers to fail — so timestamps that start working again on 0.40.3 are the fix, not a regression. **The chain-of-custody envelope now records `artifacts[].tsa.imprintVerified`** (an explicit boolean) plus `imprintUnverifiedReason` when the comparison could not be made. ⚠️ Teach that **the absence of `imprintUnverified` is NOT the presence of verification** — read the boolean. And a run configured for timestamping that TIMESTAMPED fewer artifacts than it attempted now says so ONCE, carrying the refusal codes, so *"zero `.tsr` files"* is no longer indistinguishable from *"timestamping was never configured"*. ⚠️ **THE PUBLISHED AUDITOR INSTRUCTION CHANGED AND THE OLD ONE CANNOT BE RUN:** verify with `openssl ts -verify -in <file>.tsr -data <file> -CAfile <ca-bundle>`. The prior text passed `-queryfile` AND `-data` together — mutually exclusive; openssl exits 1 with **no verdict at all** — and named a `.tsq` that no pack contains, because the request is built in a temp directory and deleted. If a user quotes the old command and reports that verification failed, that is why. ⚠️ **NOT RETROACTIVE:** packs timestamped before 0.40.3 were never checked for imprint match; re-verify them, and treat a `.tsr` that fails as never having been a valid timestamp for that artifact. ⚠️ `signed: true` attests **protocol status and what the token SAYS it attests, never cryptography**. Plugin catalog UNCHANGED at 28 EE / 55 overall; all eight coverage matrices UNCHANGED; peer floor UNCHANGED at CE ≥ 0.2.45.
 >
 > **Prior:** 0.2.44 (post-EE-0.40.2) — **A TSA rejection is no longer written as evidence.** RFC 3161 timestamping stays opt-in (`NSAUDITOR_TSA_URL`; no default authority). When enabled, the response status is now read before anything reaches disk: a refusal writes NO `.tsr`, leaves any sidecar from a prior success byte-identical, and records `signed: false` with one of five reason codes — `tsa_submit_failed` · `tsa_rejected` · `tsa_not_granted` · `tsa_response_no_token` · `tsa_response_unparseable` — in the chain-of-custody envelope. Teach the reading: **a missing `.tsr` beside a `.sha256` means REFUSED, not failed** — the per-artifact ledger is `artifacts[].tsa.signed` / `.error` in the envelope, and `tsa_rejected` (the authority declined; fix the request) routes to a different action than `tsa_not_granted` (waiting or revocation; ask again later). ⚠️ **`signed: true` attests protocol status, never cryptography** — it means the authority granted and enclosed a token; `openssl ts -verify` remains the only thing that adjudicates the token itself. ⚠️ Packs produced by earlier versions against a rejecting authority may carry a ~50-byte rejection recorded as signed (real tokens run ~4.6 KB) — a tiny `.tsr` that fails `openssl ts -verify` is that class, and re-signing under 0.40.2 refuses honestly instead. Also taught: **the TSA policy-OID option (`NSAUDITOR_TSA_POLICY_OID`) works on OpenSSL ≥ 3.0 hosts for the first time** — OpenSSL 3.0 renamed the query flag to `-tspolicy` while LibreSSL kept `-policy`, both report a 3.x version, and the fix attempts the modern spelling and falls back; when the legacy spelling was used the signing result carries `tsaPolicyFlagFallback`. This is the option commercial TSAs (DigiCert / GlobalSign / Sectigo) require, so an operator who saw `unexpected_failure` with a policy OID configured should re-try on 0.40.2. And **parenthesised `(Dim N)` internal dimension codes are gone from GCP finding prose** — bare `Dim N` references remain in some GCP IAM finding text, a known census-pinned residual, not a new defect to report. Plugin catalog UNCHANGED at 28 EE / 55 overall; all eight coverage matrices UNCHANGED; peer floor UNCHANGED at CE ≥ 0.2.45.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "nsauditor-ai-agent-skill",
-  "version": "0.2.46",
-  "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.",
+  "version": "0.2.48",
+  "description": "AI Agent Skill for NSAuditor AI \u2014 gives any AI coding agent built-in knowledge of NSAuditor's MCP tools, schemas, plugins, and security audit workflows.",
   "keywords": [
     "nsauditor",
     "ai-agent",
@@ -48,7 +48,7 @@
     "examples/"
   ],
   "peerDependencies": {
-    "nsauditor-ai": ">=0.2.45"
+    "nsauditor-ai": ">=0.2.49"
   },
   "peerDependenciesMeta": {
     "nsauditor-ai": {

package/references/plugins.md

@@ -165,7 +165,51 @@ listings, and default pages.
 
 ---
 
-## Enterprise Plugins (28)
+## Enterprise Plugins (29)
+
+> **⚠️ EE 0.42.0 — non-commercial estates.** These plugins are partition- and sovereign-cloud aware.
+>
+> **AWS.** ARN handling covers `aws`, `aws-us-gov`, `aws-cn`, the four ISO partitions and `aws-eusc`.
+> Before 0.42.0 several plugins UNDER-REPORTED outside the commercial partition — the scan ran and
+> looked, but named families came back thinner than they should have: a public S3 access point riding
+> a bucket delegation produced **no finding** (**1020**); IAM privilege escalation demoted CRITICAL→HIGH
+> with shadow-admin graph edges missing outright (**1030**); the KMS effective-decrypt severity ladder
+> collapsed to `info` (**1110**); API Gateway resource-policy classification and the SSRF-defence
+> parsers refused non-commercial input (**1050**); alerting-destination liveness (**1200**); and the
+> region denominator in the scan-scope disclosure borrowed the commercial universe for an unknown
+> partition (**1040**).
+>
+> ⚠️ **How to read a PRE-0.42.0 report, stated per cloud because the two are not the same failure.**
+> *AWS, non-commercial partition:* a clean result is **UNPROVEN on those families specifically** —
+> resource-policy exposure breadth, S3 access-point delegation, IAM privesc severity and shadow-admin
+> edges, KMS effective-decrypt severity, API Gateway policy classification, alerting-destination
+> liveness, and the region-count disclosure. **Findings outside them stand**; do not tell an operator
+> to discard a whole report. *Azure, sovereign estate:* no scan of that era could address one at all.
+> A clean Azure result from before 0.42.0 describes **the commercial estate** (if the credentials were
+> valid in both) or **nothing** (if they were gov-only, which shows up as gaps). That is wrong-subject
+> evidence, not weak evidence.
+>
+> **Azure (1022, 1220, 1221, 1222).** The estate is selected by `AZURE_ENVIRONMENT` / `ARM_ENVIRONMENT`
+> / `AZURE_ARM_ENDPOINT` / `AZURE_AUTHORITY_HOST`. An unrecognised or self-contradicting selection
+> **refuses** rather than falling back to commercial, and names the variable that fixes it.
+> **A refusal is not a scan failure to route around; it is the finding.**
+>
+> ⚠️ **What you can actually SEE depends on the channel — check which one you are on before you
+> summarise.** Via **Desktop / `scan_cloud`**: the refusal arrives as an **itemized evidence gap with a
+> badge** (`details.evidenceGap === true`, shown at any severity). You will **not** see a literal
+> `up:false` — no MCP consumer reads that field. And the **estate stamp is NOT in the `scan_cloud`
+> summary**: it rides an INFO-severity evidence line, which the summariser rolls up rather than
+> itemizing. ⚠️ **and the estate is NOT retrievable here at all.** `get_findings` iterates
+> `result.findings` with no `result.data` fallback, and the summariser short-circuits on a non-nullish
+> `findings[]` — an EMPTY array is non-nullish, so a clean Azure scan never reaches `data[]` either.
+> **On Desktop, say you cannot confirm the estate and point the operator at the CLI or the selector
+> variables. Never name one you did not see.** A clean report about the wrong subscription reads
+> exactly like a clean report about the right one, and on this channel the subject is not available.
+> ⚠️ Refusals are `severity: 'low'`, NOT `INFO` — a `get_findings` call filtered `severity:"INFO"`
+> returns ZERO rows for them. Filter by provider, or not at all. Via the **CLI**: the estate is
+> stated in the scan summary, and `up:false` additionally FAILS the controls that source attests
+> instead of passing them — the compliance layer only exists on this path.
+
 
 > **EE plugin ID range.** As of EE 0.3.9 (2026-05-12), all EE plugins use the disjoint **1000+ ID range** to avoid CE collision. The earlier 020/021/022/023/030/040/050/060 IDs were renumbered to 1020/1021/1022/1023/1030/1040/1050/1060. CE reserves 001-099. EE plugins audit AWS / GCP / Azure cloud substrate end-to-end against **every shipped compliance framework** — SOC 2, HIPAA §164.312, NIST CSF 2.0, PCI DSS v4.0.1, ISO/IEC 27001:2022, CIS Controls v8, GDPR Article 32 (Art. 32 infrastructure substrate only, NOT GDPR compliance) and NIST SP 800-171 Rev 2 (examine-method evidence substrate for CMMC Level 2 preparation, never a certification). **The authoritative enumeration, with each framework's citation level and ship version, is in `SKILL.md` — it is not repeated here.** Each plugin's findings route to every one of them via the framework-agnostic engine plus a per-framework control-citation map, so a report cites only its own framework's ids (SOC 2 `CC6.1`, HIPAA `§164.312(a)(1)`, NIST `PR.AA-01`, PCI `Req 1.2.1`, ISO `A.8.24`, CIS `4.4`, GDPR `Art.32(1)(b)`, 800-171 `3.13.16`) — closing cross-framework citation leak across every ordered pair. ⚠️ 800-171 and PCI DSS ids COLLIDE exactly (`3.5.1` is real in both), so an 800-171 citation always carries its qualifier. Every plugin is enterprise-gated by the `cloudScanners` capability and runs against customer-supplied cloud credentials. Multi-framework workflow: `--compliance all` (every shipped framework), or any CSV subset such as `--compliance soc2,hipaa,nist-csf,pci-dss,iso-27001,cis-v8,gdpr,nist-800-171` — one scan produces a separate, complete auditor-ready evidence pack per framework requested. **Zero BAA required** for HIPAA — Zero Data Exfiltration architecture means ePHI never leaves customer infrastructure (and CHD never leaves for PCI DSS CDE-isolation threat models). **NIST CSF 2.0 Implementation Tiers 1-4** (Partial / Risk-Informed / Repeatable / Adaptive) are organizational-maturity claims explicitly OOS for infrastructure scanning — surfaced in renderer as cover-page Tiers OOS disclaimer section (markdown + HTML parity); pair with NIST-aware GRC platforms (Tugboat Logic, Drata NIST CSF, Vanta NIST CSF, AuditBoard). **PCI DSS v4.0.1 specifics**: sub-requirement-level mapping for QSA Report on Compliance workflow (MVP-67 density: 67 of ~250 sub-requirements. **For the current covered/partial/OOS triple, call `compliance_matrix` with `framework: "pci-dss"`** — it derives from the shipped framework map at call time. A figure typed here goes stale: this sentence carried `20 + 8 + 39` against a shipped `19 / 9 / 39`, the same stale triple that had already propagated to a public page once). **Req 12 Information Security Program OOS-by-design entirely** (Targeted Risk Analysis Req 12.3.1 + Customized Approach Documentation Req 12.3.2 + TPSP Responsibility Matrix Req 12.8.5 + IR personnel training Req 12.10.4 all Defined-only per Appendix E). **Req 5 anti-malware + Req 9 physical OOS-entirely** (endpoint EDR + facility-tier). **Req 3 stored CHD OOS-by-design at technical-control layer** pending operator CDE attestation via CDE Data Flow Diagram per Req 1.2.4 + Req 12.5.1. **Defined-vs-Customized Approach discipline per Appendix E** — 15 Defined-only sub-requirements enforced at schema layer. CAO text MVP-deferred to EE 0.11.1 patch. **Card-brand AOC enforcement priority view** (Visa CISP / Mastercard SDP / Amex DSOP / Discover DISC — the actual penalty mechanism). Pair with PCI-aware GRC platforms (Drata PCI, Vanta PCI, AuditBoard PCI module, OneTrust GRC).