MOOTx01 holds a person's memory and, in federated configurations, mediates what one estate shares with another. If you find a problem that touches that trust, please report it privately.

This substrate does not bolt security on at the perimeter. The properties that matter are carried by the atoms of the data model:

• Every row is classified. Sensitivity (normal through secret) and exportability (private or public) are adjectives bitmapped onto every row at write time, not labels applied by a layer above. Recall is constrained by them on every read.
• Forbidden states are unreachable, not discouraged. The substrate rejects forbidden adjective combinations at the write gate. A row that is secret and public is not a policy violation to be caught later; it is a state the system cannot represent.
• The audit log is the substrate, not a sidecar. Nothing is silently overwritten. Every change is an immutable event; audit rows can be tombstoned but never modified. State that cannot be replayed from the log is state the substrate refuses to produce.
• Private by locality. Memory lives where its owner puts it. There is no required cloud, no vendor account, and no server that sees the data unless the owner runs one.
• Federation is bounded. Cross-estate handshakes share what the grant names and nothing else, and aggregate queries carry formally bounded noise.

Understand the shape of the promise. This is a vault, not a cloak. The substrate's job is to honor its owner's intention and not leak: what you mark secret stays secret, what you mark private does not cross the perimeter, and everything that happens is on the record. It is not designed to obfuscate, anonymize, or conceal that information exists. A system with those goals could be built on top of this substrate, but that is not the purpose of this project. If your deployment needs hardened, certified cryptography, ask about the Enterprise Edition.

These are design invariants, not marketing. They are enumerated and tracked in the claims ledger, and the caveat in Current posture applies to all of them.

Limits as plainly as possible.

Your machine is the boundary. An estate is a local database file owned by your user account. Any process running as you can read that file directly: a malicious app, a compromised tool, a person at your unlocked keyboard. None of the application controls (sensitivity tiers, export gates, receipts) defend against code already running on your machine. At that level the protections are the operating system's: file permissions, FileVault, and your own judgment about what you install. Estates on the default SQLite backend are whole-database encrypted at rest by SQLCipher under a 256-bit per-install key.

A PostgreSQL backend you configure yourself is protected by that server's controls, not by MOOTx01. secret rows remain excluded from recall and from every bulk channel in addition to at-rest encryption.

mootx01 upgrade detects an unencrypted reused estate and offers to convert it to encrypted, on every upgrade. This is an allowance for users who change their mind after reflecting on what they have stored in their moot estate.

Non-default estates are treated as configured deliberately by the software that created them, encrypted or not, and have no conversion path. This is by design. It protects estates built by software running on top of the mootx01 mono-SDK or the open-source moot-xxxx SDK.

The AI reads what you let it recall. This is a knowledge engine. Anything the AI can recall can leave through a conversation, slowly and one context at a time. No memory product can prevent that and remain useful. What the substrate controls is the bulk path: mass export is gated by tier, private content requires its owner present, and every bulk operation writes a receipt. The goal is that fast, lossless, silent egress is impossible. A slow trickle is the cost of having a useful engine, and the audit trail is how you see one.

The gates protect the owner's front door. Export gating, owner key prompts, and receipts exist to stop a legitimate install from being driven into bulk egress by a compromised agent, a bad configuration, or an accident. They are not a defense against someone who already owns the machine. Seatbelts, not armor plate.

Choose the local MCP transport that fits the deployment. The default resident daemon listens on loopback so several clients can share one writer, background governor, and telemetry stream. Any process running as the same user can attempt to contact that local endpoint. mootx01 install --no-daemon writes direct mootx01 serve stdio entries instead, keeping MCP traffic on the parent client's process pipes under normal operation. A stdio process forwards to an already-running resident that owns the same estate, so stop or disable the old resident when the MCP requirement is no listening socket. The direct stdio setup documents the exact configuration and checks.

This is open source. Anyone can build a version with the locks removed, and a modified build sees only the data on machines where someone chooses to run it. What you can verify is that the build you installed is the one we shipped:

• Release artifacts publish SHA-256 checksums in checksums.txt alongside each release. The installer verifies them before extraction, and fails closed if no SHA-256 tool is available — the installation is aborted rather than proceeding with an unverified binary. You can check by hand with shasum -a 256.

• macOS binaries are Developer ID signed and notarized. Verify with codesign --verify and spctl --assess.

• Windows binaries are Authenticode signed.

• Linux/POSIX — minisign Ed25519 signature (CAND-004). Linux does not have an OS-enforced code-signing mechanism equivalent to macOS Developer ID or Windows Authenticode. As an independent trust root for Linux/POSIX releases, mootx01 publishes a detached Ed25519 signature of checksums.txt (the file checksums.txt.minisig) alongside each release, signed with the project's minisign key (key id BC4D1E6ABCB5B788). The public key is bundled at distribution/minisign.pub in the repository and embedded in the Rust upgrade binary at compile time.

  The shell installer (install.sh) and the mootx01 upgrade command verify this signature fail-closed on Linux: if minisign is not installed, or the signature is missing or invalid, installation is aborted with a descriptive error rather than proceeding with an unverified binary.

  Verification order on Linux/POSIX:

  1. Download asset and checksums.txt (TLS from github.com)
  2. SHA-256 checksum verification against checksums.txt
  3. minisign Ed25519 signature verification of checksums.txt against the bundled public key (independent trust root)
  4. Extraction

Do not pipe remote installer content directly to a shell. Download, review, verify, then act — in that order. Any verification failure is a hard stop.

If the checksum or signature does not match, the binary is not ours. Nothing in this document applies to it.

Do not open a public issue for a security problem.

Use GitHub's Report a vulnerability form under this repository's Security tab, or email security@codedaptive.com.

A useful report names the kit or lib affected, the version or commit, and enough detail to reproduce what you observed.

Anything touching the guarantees described above: data integrity, the access perimeter (sensitivity, exportability, forbidden adjective combinations), the federation trust boundary, and chain of custody.

This is a community edition maintained on a best-effort basis. We read security reports, we work confirmed problems privately, and we disclose once a fix has shipped. We are glad to credit reporters. There is no bug bounty and no response-time guarantee.

Security review is continuous, both human and a for-fee automated AI powered service. We do not name the automated service while it is in use. If we change services, we will name the one we left.

Official security hardening began on June 25 and has continued since. The project is running repeated independent adversarial review, remediation, cross-port verification, and current-head revalidation across the monorepos for the Community and Enterprise Editions, as well as the open-source moot-xxxx SDK repositories.

The combined remediation record contains 543+ security findings from the initial product build campaigns and hardening effort. The count does not multiply dual-port fixes or EE-to-CE backports.

Active development on 1.0 has transitioned to maintenance only. Security findings will continue to be fixed until version 1.1 reaches stable release, at which time 1.0 users should transition to version 1.1 to receive ongoing security fixes.

The full public count, process, and commit record is in the audit ledgers under docs/validation/audits. The review covers the codebase at each reviewed commit. The invariants above remain design guarantees exercised continuously by the test suite.

Security reviewed

Not security reviewed. Back-ported fixes from 1.0.x only.