18. Security Considerations

MMP is designed for autonomous agents that share cognitive state. Security must address both traditional protocol threats (spoofing, eavesdropping, injection) and novel threats specific to cognitive coupling (state poisoning, drift manipulation, lineage forgery).

18.1 What Crosses the Mesh

Hidden state vectors (h₁, h₂) are compact, opaque neural representations encoding cognitive patterns, not raw data. Because sufficiently advanced analysis could reconstruct aspects of the input, hidden state is a privacy surface — which is precisely why it never crosses the wire (Section 2.7). It is strictly local and confidential by construction; only CMBs — deliberately scoped, signed statements — propagate.

18.2 Transport Security

MMP does not mandate transport encryption in the base specification. Implementations SHOULD apply:

18.2.1 End-to-End CMB Encryption

WSS (TLS) encrypts the transport — it protects from eavesdroppers on the wire. But the relay operator can still read the JSON payload inside the TLS tunnel. For cmb frames containing CMBs, this means the relay sees all 7 CAT7 field texts in plaintext.

When CMBs transit a relay, implementations MUST encrypt CMB field text end-to-end so the relay forwards opaque ciphertext, not readable fields. The relay MUST NOT be able to read CMB content.

The encryption scheme SHOULD use the Ed25519 keypair from Layer 0 (Section 3) for key exchange, with X25519 Diffie-Hellman for shared secret derivation and XChaCha20-Poly1305 for symmetric encryption. The encrypted payload replaces the fields object in the CMB:

{
  "type": "cmb",
  "timestamp": 1711540800000,
  "cmb": {
    "key": "cmb-b2c3d4e5f6a7b8c9",
    "createdBy": "agent-a",
    "createdAt": 1711540800000,
    "fields": "<encrypted>",        // opaque ciphertext
    "nonce": "base64-encoded-nonce", // per-frame nonce
    "lineage": { ... }              // lineage stays cleartext for graph traversal
  }
}

lineage (parents, ancestors, method) remains in cleartext. Lineage contains only CMB keys (content hashes) — not field text. This allows the relay and intermediate nodes to maintain graph structure without reading content.

On LAN (Bonjour TCP), E2E encryption is RECOMMENDED but not required — there is no relay intermediary. On trusted LANs, the transport itself provides sufficient isolation.

18.3 Node Identity & Authentication

Node identity is UUID-based with mandatory Ed25519 cryptographic identity (Section 3.1.3). Authentication ensures that nodeId claims are verifiable and that relay intermediaries cannot impersonate peers.

• —Each node MUST generate an Ed25519 keypair at first launch and persist it alongside the nodeId.
• —The public key MUST be included in the handshake frame and DNS-SD TXT record.
• —Peers SHOULD verify identity by challenging the node to sign a nonce with its private key.
• —Implementations that have not yet adopted cryptographic verification MAY rely on DNS-SD discovery scope and network isolation as an interim trust model, but MUST document this limitation.

18.3.1 CMB Signature Verification

Transport identity (above) authenticates the connection; CMB signatures authenticate each cognitive block end-to-end — the layer that matters when a peer-pushed CMB can enter the receiving agent’s context. Every CMB SHOULD be signed by its author using the same Ed25519 identity key the node announces in its handshake.

• —The author signs a canonical payload binding the content-address key (§8.2.1), the author’s nodeId, the author’s own creation time, and the CMB’s audience. For cmb1- keys the payload is domain-separated and length-prefixed — "mmp-sig-v1\n" + LP(key) + LP(author) + LP(decimal(createdAt)) + LP(group) + LP(to) — where group is the group the CMB was authored for and to is the directed recipient’s nodeId (empty for a broadcast). Length-prefixing closes the delimiter-injection the address serialization does, and the payload MUST use the author’s own createdAt, never a receiver-local timestamp. The signature travels as cmb.sig (base64url) with cmb.sigAlg (ed25519); a verifier MUST pin the expected algorithm rather than trust sigAlg.
• —A receiver holding the author’s public key MUST verify a signed CMB on two counts before admitting or surfacing it: (1) the signature verifies against that key, and (2) the content-address key still matches the actual fields — a valid signature replayed over swapped content MUST be rejected.
• —Audience check. Because the signature binds group and to, a receiver MUST additionally reject a signed CMB whose group is not the receiver’s group, or whose to is neither empty nor the receiver’s nodeId — a cross-group or mis-directed replay that is genuinely signed but not for this audience. This is a check distinct from a bad signature, so a wrong-audience block is not mis-reported as tampering; it also enforces the §5.8 group boundary cryptographically, not only at the frame layer.
• —A CMB that fails any check MUST NOT be surfaced to the application layer or stored, and SHOULD be audit-logged. This forecloses spoofing (forging another peer’s authorship), tampering (mutating a block in flight), and cross-audience replay.
• —Unsigned CMBs MAY be accepted only from peers that never demonstrated signing. To prevent downgrade (stripping the signature and re-emitting unsigned), once a receiver has admitted a signed CMB from an identity it MUST reject subsequent unsigned CMBs purporting to be from that identity. (This requires durable per-identity state; first contact remains trust-on-first-use.)
• —Enforcement scope, disclosed. A strict mode that rejects unsigned CMBs is necessarily scoped to peers whose keys the receiver can resolve: unsigned traffic from a peer with no pinned or roster-resolvable key passes even in strict mode — the receiver cannot distinguish a never-signing peer from a stripped signature at first contact. Key resolution SHOULD consult the full binding registry (anchor-pinned, handshake-pinned, and grant-vouched keys — §6.6), not the direct-handshake map alone, so relayed peers the receiver never met still verify; the residual unsigned-from-unknown window closes only when signature enforcement is on and the roster covers the mesh. Operators of regulated meshes SHOULD run enforcement on with a seeded roster.

18.4 Cognitive Threats

MMP introduces threats unique to cognitive coupling that traditional protocol security does not address:

18.5 Privacy & Deployment Recommendations

Metadata exposure. Even with E2E field encryption (Section 18.2.1), the following metadata travels in cleartext: createdBy, lineage.parents, lineage.ancestors, and mood valence/arousal values. Mood is intentionally unencrypted because it is always delivered even from rejected CMBs (Section 9.3). Deployments where mood leakage is unacceptable MUST disable mood delivery by setting all mood field weights to 0. This is a deliberate privacy trade-off: the protocol prioritises collective intelligence over metadata confidentiality.

MMP is designed for privacy by default — L0 data never leaves the node, hidden states are opaque, and SVAF gates what enters. For domains with heightened privacy or IP concerns, the following deployment model is RECOMMENDED:

Additional privacy considerations:

• —Error frames MUST NOT contain sensitive information. The detail field is for debugging, not for conveying user data.
• —Wake channels expose push tokens to peers. Implementations SHOULD restrict wake channel gossip to trusted relays only.
• —Implementations targeting GDPR, HIPAA, or similar regulatory frameworks SHOULD treat CMB field text as personal data and apply appropriate retention and deletion policies at the application layer.

18.6 Regulatory Compliance & Audit Trail

CMB immutability and lineage create a tamper-evident audit trail within the signed, retained graph — tamper-evident, not tamper-proof: modification of any retained block is detectable via content addressing and signatures; completeness of the underlying store is not itself checkpointed (retention §6.3 may purge, and unsigned blocks weaken the guarantee, §18.3.1). Every observation, every remix, every decision is traceable through the DAG:

• —Who — createdBy on every CMB identifies the agent that produced it.
• —When — createdAt timestamps every CMB with millisecond precision.
• —What — the 7 CAT7 fields capture the full semantic content of the observation.
• —Why — lineage.parents shows what was directly remixed. lineage.ancestors traces the full decision chain.
• —How — lineage.method records the evaluation method (e.g., SVAF-v2).

Because CMBs are immutable, the audit trail cannot be retroactively altered. A CMB once created is never modified — any action produces a new CMB with lineage pointing back. The complete history is the graph itself.

18.7 Data Quality & Encoding Trade-offs

CMB quality depends on field extraction accuracy. The protocol does not extract fields — agents do. Each agent’s LLM (or structured-data mapper) decomposes observations into CAT7 fields. If extraction is poor, downstream evaluation inherits that error. MMP provides three layers of defense, but none eliminates the need for quality extraction at the source.

Per-field evaluation quality is bounded by encoder quality, not model capacity. Production deployment revealed that n-gram encoding (character trigrams + word bigrams) produces 0.31 cosine similarity for paraphrases — SVAF cannot distinguish “submit IETF draft today” from “IETF submission, zero blockers, execute now” because the encoder represents them as distant vectors. Replacing n-gram with semantic embeddings (all-MiniLM-L6-v2, 384-dim) raises paraphrase similarity to 0.69 — a 2.2× improvement — while preserving topic separation (different topics: 0.03). Implementations SHOULD use semantic embeddings for SVAF evaluation. N-gram encoding is suitable only for prototyping or resource-constrained environments where the quality trade-off is acceptable.

Implementations targeting domains where field extraction quality is critical (healthcare, legal, finance) SHOULD validate extraction output before calling remember(). Strategies include:

• —Schema validation — reject CMBs with empty or defaulted fields before they enter the mesh
• —Confidence thresholds — the LLM can assign a confidence score to its extraction; low-confidence CMBs can be withheld
• —Lineage feedback — CMBs that get remixed by other agents (have descendants in the DAG) signal high quality; CMBs that expire without children signal noise. This feedback loop lets the mesh itself shape extraction quality over time
• —Semantic embedding encoder — implementations SHOULD use a semantic embedding model (e.g. all-MiniLM-L6-v2) for SVAF drift computation. The evaluation pipeline is encoder-agnostic — any function that maps text to unit-normalised vectors works. N-gram encoding MAY be used as a zero-dependency fallback.