18. Security Considerations — MMP Specification

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 category texts in plaintext.

In the Core Secure profile, implementations MUST encrypt CAT7 categories and application bytes end to end on every transport. A relay forwards an opaque envelope and MUST NOT learn protected content.

The v2.0 Core Secure suite is X25519 key agreement, HKDF-SHA256 derivation and IETF ChaCha20-Poly1305 authenticated encryption. Ed25519 identity proofs and X25519 key confirmations bind both public keys to the authenticated handshake transcript (§5.2).

{
  "type": "cmb-encrypted",
  "protocolVersion": "2.0",
  "suite": "X25519-HKDF-SHA256-ChaCha20-Poly1305",
  "sessionId": "<32 lowercase hex>",
  "sequence": "0",
  "direction": "client-to-server",
  "metadata": { "key": "cmb-…", "assertionId": "asrt-…",
                "createdByNodeId": "<uuid>", "room": "team", "to": "<uuid>" },
  "sealed": "<unpadded base64url ciphertext || 16-byte tag>"
}

Each direction has a distinct HKDF-derived 32-byte traffic key. The first sequence is zero; the nonce is that sequence encoded as an unsigned 96-bit big-endian integer. An ordered receiver MUST require the exact next sequence and reject replay, rollback and gaps.

The protected plaintext contains categories and decoded application bytes. Associated data binds protocol version, session, direction, sequence, cognition key, assertion identity, author nodeId, room and recipient. After decrypting, the receiver reconstructs the logical two-section record and follows §8.8.5 verification order. Exact outputs are published in the E2E vector.

When metadata.application is null, the protected plaintext MUST omit applicationData entirely. A present application whose decoded data is zero bytes instead carries applicationData: "". The two states are distinct and MUST NOT be collapsed. Both byte shapes are pinned by the E2E vector.

18.3 Node Identity & Authentication

Node identity is a UUID bound to an Ed25519 key through the authenticated transcript in §5.2. An X25519 session key is separately generated but proven in the same transcript.

• —Each node MUST generate an Ed25519 keypair at first launch and persist it alongside the nodeId.
• —Discovery records are untrusted hints. A peer MUST NOT pin their identity or E2E key from DNS-SD, relay discovery or an unproven hello.
• —Both nonces, nodeIds, keys, room, protocol version, implementation identifiers and extension negotiation MUST enter the signed transcript.
• —Core Secure MUST require both the Ed25519 transcript proof and X25519/HKDF key confirmation. Network isolation is not identity authentication.

18.3.1 CMB Signature Verification

Transport identity (above) authenticates the connection; CMB signatures authenticate each record assertion end-to-end. Every Core Secure CMB MUST be signed by its author using the Ed25519 identity proven in the handshake or a verifiable author key-binding chain.

• —The byte-exact mmp-sig-v2.0 payload is specified only in §8.8.4. It binds the cognition address, address scheme, author nodeId and label, signed author time, room, recipient, lineage commitments and application commitment.
• —The receiver MUST resolve the author key by createdByNodeId, never createdBy.
• —Before admission or application exposure, the receiver follows all checks in §8.8.5, including record address, assertion identity, signature and audience.
• —An unsigned, legacy-suite or unverifiable record MUST NOT enter Core Secure. It may be quarantined under an explicitly selected Legacy Import profile; no automatic downgrade is permitted.

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. The Core Secure envelope leaves only the routing and verification metadata required by its schema in cleartext and authenticates it as AEAD associated data. CAT7 categories, including mood text, valence and arousal, and application bytes are encrypted. A relay can still observe endpoints, room/routing identifiers, record and assertion identifiers, sizes, timing and traffic volume. MMP v2.0 does not provide traffic-analysis resistance.

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 ancestors 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 category 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 — metadata.createdBy names the agent, while metadata.createdByNodeId binds it to the signing identity.
• —When — metadata.createdTimestamp records the author-asserted millisecond timestamp.
• —What — the 7 CAT7 categories capture the full semantic content of the observation.
• —Why — metadata.lineage.parents shows what was directly remixed. Following the signed parent links traces the full decision chain.
• —How — metadata.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 category extraction accuracy. The protocol does not extract categories — agents do. Each agent’s LLM (or structured-data mapper) decomposes observations into CAT7 categories. 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-category 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 category extraction quality is critical (healthcare, legal, finance) SHOULD validate extraction output before calling remember(). Strategies include:

• —Schema validation — reject CMBs with empty or defaulted categories 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.