neuralmind.uk / NIST SP 800-53 Rev. 5: NeuralMind’s controls and what stays yours Edit this page on GitHub ↗

NIST SP 800-53 Rev. 5: NeuralMind’s controls and what stays yours

Date: 2026-10-20 Version: 1.0 Machine-readable: security/neuralmind.oscal-component-definition.json (OSCAL 1.1.3 component definition)

1. What this is

An agency that installs NeuralMind inside an authorized system has to describe, in its System Security Plan, how each SP 800-53 control is met, including by the software it runs. NeuralMind is local software with no hosted service, so it is a component of your system, not a provider with its own authorization.

This page lists the SP 800-53 Rev. 5 controls NeuralMind touches, what it does for each, and what stays yours: a customer responsibility matrix. The same content is published as an OSCAL component definition, which GRC tools (Compliance Trestle, and the OSCAL importers of commercial GRC platforms) read straight into an SSP.

It lists the controls NeuralMind does something for. Controls it doesn’t touch (physical protection, personnel security, contingency planning, most of identification and authentication) are met by your environment alone and aren’t listed.

2. Controls

Control What NeuralMind provides What stays yours
AC-3 Access Enforcement Each MCP tool call is checked against a per-tool permission set for the roles admin, builder and reader (security.roles, or the built-in sets). With security.identity: os the caller is the OS account the MCP server runs as and its role comes from security.users (or security.default_role); the role a call declares is recorded, not used. The daemon’s routes and neuralmind build need the same role as the matching MCP tool. Every refusal is written to the audit log. security.profile: cui forces identity: os. Map each OS account to a role in security.users. Without security.identity: os, any caller can declare admin, so the permission sets limit a well-behaved agent, not a hostile caller. Other CLI commands run with the account’s file permissions.
AC-6 Least Privilege Three roles with fixed tool sets: reader (query and search), builder (adds index builds), admin (adds administration tools). Under security.identity: os an OS account missing from security.users gets security.default_role, or is refused when none is set. Give each account the least role it needs, and leave security.default_role unset or set to reader.
IA-2 Identification and Authentication (Organizational Users) NeuralMind doesn’t authenticate users. With security.identity: os it takes each MCP caller’s identity from the OS account the OS has already authenticated, and records it as the actor of every audit event; a declared actor or NEURALMIND_ACTOR is kept only as claimed_actor. OS accounts and their authentication (passwords, MFA, PIV/CAC). Without security.identity: os the actor is whatever the caller or environment declares.
AU-2 Event Logging Events logged to .neuralmind/audit_events.jsonl: queries, searches, index builds, MCP tool calls and their refusals (role, rate limit, encrypted-storage and profile refusals), audit checkpoints, and gap records for audit writes that failed. Decide which of these events your audit policy requires, and review the event list against it at each upgrade.
AU-3 Content of Audit Records Each record holds a UTC timestamp, category, action, actor (and actor_role), status, target and details, plus sha256 and prev_sha256 chaining it to the record before. ip_address is in the schema but empty: MCP runs over stdio. Correlating the actor with OS login records where the record alone isn’t enough.
AU-4(1) Transfer to Alternate Storage With security.audit_syslog set, every record is sent to syslog right after it is written, from every process that writes the log, and records a target that was down missed are sent when it is back (neuralmind audit forward sends them on demand). A syslog daemon that keeps the records, and forwards them to your SIEM.
AU-5 Response to Audit Logging Process Failures A record that can’t be written is noted in .neuralmind/audit_write_failures.jsonl, neuralmind doctor warns (fails under security.profile: cui), and neuralmind audit record-gap records the gap in the hash-chained log. With security.audit_syslog set, the failure also raises an alert-severity syslog message at once. Under security.profile: cui a failure that can’t even be noted refuses the call. Route the alert severity from your syslog daemon to a person, and alert when forwarding itself stops (doctor reports records waiting).
AU-6(3) Correlate Audit Record Repositories Forwarded records are JSON with timestamp, actor, sha256 and prev_sha256, so a SIEM can correlate them with other systems’ records and check the chain. The SIEM, the correlation, and the review itself.
AU-8 Time Stamps Timestamps are ISO 8601 in UTC, from the host clock. Synchronize the host clock to an authoritative time source.
AU-9 Protection of Audit Information The audit log is SHA-256 hash-chained; neuralmind audit verify fails on a changed or removed record, a record without a hash once the chain has started, and a line that isn’t a record. Signed, anchored checkpoints (neuralmind audit checkpoint) extend it to removal of the newest records and a recomputed chain. Appends from several processes hold an OS lock, so concurrent writers can’t break the chain. File permissions on .neuralmind/, a checkpoint schedule, and keeping the checkpoint key in an administrator account.
AU-9(2) Store on Separate Physical Systems or Components Checkpoint copies in security.audit_anchor_dir, a directory the administrator alone can write, and with security.audit_syslog every record forwarded off the log as it is written. audit verify fails when a configured anchor copy is missing. Put the anchor directory and the syslog destination on storage the developers can’t write, ideally another system.
AU-9(3) Cryptographic Protection Checkpoints are signed with an ECDSA P-256 key (FIPS 186-5) whose public half is pinned in security.audit_checkpoint_key; audit verify fails on a forged, re-signed or missing checkpoint. Signing runs through the cryptography package’s OpenSSL. Keep the private key in an administrator account. On a FIPS host, rebuild cryptography against the system OpenSSL and confirm it uses the validated FIPS provider.
AU-12 Audit Record Generation Records are generated by every process that acts on the project: the CLI, the MCP server, the Claude Code and Hermes hooks, and the daemon. Keep these processes running under accounts whose actions you need to audit.
CM-6 Configuration Settings A published hardening baseline (the hardening guide): 17 rules, each mapped to the controls it supports, covering the security profile and machine policy, identity and roles, file permissions, encrypted storage and FIPS mode, audit log integrity, checkpoints and forwarding. neuralmind hardening checks a project and its host against every rule, fails a rule it can’t check, exits 1 when any rule fails, and prints the result as JSON with –json. Adopt the baseline or record each deviation in the SSP, run neuralmind hardening on each host on a schedule and after each upgrade, keep its JSON output as evidence, and check the items the guide lists as checked by you (clock sync, syslog TLS, Windows ACLs).
CM-7 Least Functionality The MCP server uses stdio by default; the HTTP servers bind to 127.0.0.1 and require a token. No telemetry. Opt-in LLM documentation seeding is off by default. Under security.profile: cui, neuralmind serve refuses a listener beyond loopback or without its token, a daemon listening that way refuses the project, and LLM seeding is refused even when switched on. Don’t expose the HTTP transport beyond the enclave; keep NEURALMIND_LLM_SEED unset.
SC-8 Transmission Confidentiality and Integrity NeuralMind’s own listeners and syslog forwarding carry no TLS. Under security.profile: cui the HTTP servers are refused beyond loopback and without their token, and security.audit_syslog is refused unless the target is on this machine, so CUI doesn’t cross a network through NeuralMind. An SSH tunnel or the enclave’s encrypted network for remote access, and TLS from the host’s syslog daemon to the SIEM.
SC-13 Cryptographic Protection NeuralMind contains no cryptographic module of its own to validate. Its hash calls work with the OS FIPS mode on, and CI runs the test suite with the OpenSSL FIPS provider enforced. neuralmind doctor reports the OS FIPS mode and fails a project under security.profile: cui when it is off. The OS FIPS mode and FIPS-validated modules on the host.
SC-28 Protection of Information at Rest NeuralMind doesn’t encrypt data itself. With security.require_encrypted_storage (forced by security.profile: cui) it verifies FileVault, BitLocker or dm-crypt/LUKS on every volume holding the project’s state, refuses to build, query, serve MCP tools or run hooks without it, and logs each check. Copies under the home directory are written only where the same check passes. The encryption itself, with FIPS-validated full-disk encryption, covering every location neuralmind data-locations lists.
SI-2 Flaw Remediation A vulnerability disclosure policy (SECURITY.md) with response targets; bandit, pip-audit and CodeQL on every change; a published OpenVEX document for advisories that don’t apply; a CycloneDX SBOM per release. Stay on a supported release and feed the SBOM and VEX to your scanner.
SI-7 Software, Firmware, and Information Integrity Release container images are signed keylessly with cosign, and the image, wheel and sdist carry GitHub build-provenance attestations, which the release workflow verifies before publishing. Verify the signature and attestations before installing (docs/compliance/SSDF.md §2).
SR-4 Provenance Build-provenance attestations for every release artifact, a CycloneDX SBOM, and third-party GitHub Actions pinned to full commit SHAs. Record the verified version and its SBOM in your inventory.

3. Using it

Validate the file and load it with Compliance Trestle:

pip install compliance-trestle
python -c "from pathlib import Path; from trestle.oscal.component import ComponentDefinition as C; \
  c = C.oscal_read(Path('neuralmind.oscal-component-definition.json')); \
  print(len(c.components[0].control_implementations[0].implemented_requirements), 'requirements')"

In your SSP, reference the component from each control’s by-components entry, copy or adapt its description, and state the customer part as your own implementation.

The file is checked on every change (tests/test_oscal_component_definition.py):