NSAuditor AI Enterprise 0.36.0: the compliance report now verifies the approval signatures it renders
Nsasoft US LLC has released NSAuditor AI Enterprise Edition 0.36.0 with Community Edition 0.2.41. Every compliance report now checks the approval records it displays against the keys those records name — with two verdicts, and a missing verdict that means “not checked” rather than “failed”.
LAS VEGAS, NV — 13 August 2026 — Nsasoft US LLC has released NSAuditor AI Enterprise Edition 0.36.0, paired with Community Edition 0.2.41 and agent-skill 0.2.39. Every compliance report the Enterprise engine renders now checks the approval records it displays against the keys those records name.
The exceptions list is where audits actually get difficult
A compliance report is not only a list of what passed. It carries exceptions — findings an approver reviewed and accepted as risk, or marked as a false positive — and each exception carries an approval record naming who accepted it, why, and until when.
Assessors spend more time on that list than on almost anything else in the pack, because it is where an organisation’s judgement lives. Until this release, NSAuditor AI verified the approver’s identity against a registry, but the signature on the record itself was reported on the record’s own authority.
0.36.0 closes that gap. A registry entry may now carry the approver’s public key beside its fingerprint, the two must agree — enforced when the registry loads, so a mis-declared member is refused rather than quietly trusted — and when key material is present the engine checks each approval signature against the key it names, writing signatureVerification into the report beside the existing identity verdict.
Each verdict names the exact signature bytes it checked and pairs positionally with the record it came from. A verdict therefore cannot be attached to a different record that happens to share an identifier — a small piece of discipline that matters a great deal when an evidence pack is read years later by someone who was not there.
Two axes, and the case where they disagree
The check answers two questions rather than one:
verified— should this suppression stand?cryptoValid— did these bytes come from the key they name?
They diverge on exactly one case: a key revoked after it signed. Keeping the two apart is what turns “this approval was signed after the approver’s credential was revoked” from a statement about an editable text field into a cryptographic finding. For an assessor testing change-management and access-revocation controls, that is a materially different artifact.
A missing verdict means not checked — never failed
The most consequential decision in the release is a restraint rather than a feature. Every identity registry in the field today carries fingerprints only, so for most organisations signature verification is simply unavailable until approvers supply key material.
Reporting those records as failures would have accused an organisation’s own approvers of forgery for not having migrated yet. Instead, the report states that the record was not checked by this report, and only a genuine negative verdict renders as a failed verification. The cryptoValid axis is absent when the question is unanswerable, never false.
Riding with it is a migration advisory: the report now names how many registered approvers are still awaiting key material, and exactly what to paste to enable checking. Absence is treated as a state in its own right — a report that cannot tell you what it does not know is not a report an auditor can lean on.
Failure behaviour
An engine fault in the identity-verification phase now fails that framework’s report loudly rather than rendering a degraded section. The scan, the other frameworks and the findings artifacts are unaffected. The machine-readable report contract documents both verification channels before they publish — once a shape reaches customer evidence archives it is frozen by those archives, so it is specified in advance rather than retrofitted.
Coverage and posture unchanged
All seven compliance coverage matrices are unchanged — SOC 2 (AICPA TSC), HIPAA §164.312 Technical Safeguards, NIST CSF 2.0, PCI DSS v4.0.1, ISO/IEC 27001:2022 Annex A, CIS Controls v8 and GDPR Article 32 as an infrastructure substrate rather than GDPR compliance in the round. The plugin catalog is unchanged at 28 Enterprise plugins — 27 cloud auditors across AWS, Azure and GCP plus a Zero Trust posture assessment scored from a network-host scan — 55 counting the Community Edition set. This is a depth release on evidence integrity, and Nsasoft describes it that way.
Ed25519 suppression signing remains described as reachable and not yet proven. RFC 3161 trusted timestamping is opt-in via NSAUDITOR_TSA_URL, with no default ever; it was verified against a real public Time-Stamp Authority on 7 August 2026, and a one-byte alteration to the artifact turned the same verification into a failure — the control that makes the result a statement about those exact bytes.
Availability
@nsasoft/nsauditor-ai-ee 0.36.0 is on npm as a licensed Enterprise package. Community Edition nsauditor-ai 0.2.41 is MIT-licensed and free. Enterprise requires Community Edition 0.2.40 or newer — unchanged this cycle, because nothing in this release needs new Community Edition code.
npm install -g nsauditor-ai@latest @nsasoft/nsauditor-ai-ee@latest nsauditor-ai-agent-skill@latestScanning is agentless and read-only, and runs on the operator’s own infrastructure: scan data, credentials and findings stay where they already are, and nothing is transmitted to Nsasoft. The outbound paths the product can take are enumerated in the egress register published in its architecture documentation.
More information: https://www.nsauditor.com/ai/enterprise/
Media contact: support@nsauditor.com
