SAIHM (Sovereign AI Horizontal Memory)

architect@saihm.coti.global https://saihm.coti.global/

art Independent Submission AI memory post-quantum signatures Model Context Protocol GDPR Article 17 cryptographic erasure This document defines the Sovereign AI Horizontal Memory (SAIHM) protocol, a memory layer for AI agents that supports post-quantum identity binding, public-chain audit anchoring, per-cell encryption with wallet-derived keys, revocable sharing contracts, and cryptographic right-to-erasure aligned with Article 17 of EU Regulation 2016/679 (GDPR). SAIHM is the memory-layer protocol companion to the Model Context Protocol (MCP). MCP standardizes how AI agents reach tools and contextual data sources; SAIHM standardizes how AI agents persist, share, and erase memory across sessions, models, and vendors.

Introduction

Motivation The Model Context Protocol , donated to the Agentic AI Foundation under the Linux Foundation on 9 December 2025, defines how an AI agent reaches external tools and contextual data sources. MCP solves the tool-access layer of the agent stack. It does not standardize how an agent persists memory across sessions, models, or vendors. Production AI agents today rely on one of several non-portable approaches: a local file system, a vendor-specific session log, or a vector database. None of these provides post-quantum identity binding, public-chain audit, cryptographic erasure aligned with Article 17 of GDPR , or wallet-bound sovereignty that prevents an operator from reading cell content. This document specifies the Sovereign AI Horizontal Memory (SAIHM) protocol. SAIHM is a memory-layer protocol that an MCP-capable agent may attach to gain durable, sovereign, revocably-shareable, cryptographically-erasable memory. The protocol is operator-agnostic, vendor-agnostic, and chain-agnostic. Where a public-chain audit anchor is named, it is named as a reference-deployment property, not as a protocol mandate.

Scope This document defines:

• The cell shape (encrypted memory unit with canonical metadata).
• Identity binding using a post-quantum digital signature algorithm (ML-DSA-65, ).
• An encryption envelope deriving a per-cell DEK from the holder's wallet through a canonical HKDF chain .
• An audit anchor profile, with a reference deployment on a public chain.
• Sharing contracts (temporary, permanent, syndicate).
• Cryptographic erasure semantics (DEK destruction + tombstone + content-address blacklist) aligned with GDPR Article 17.
• An MCP binding consisting of eight canonical tools.

This document does NOT define:

• A specific blockchain (the protocol is chain-agnostic).
• Vector-database semantics (orthogonal).
• Agent runtime semantics (covered by MCP and runtime implementations).

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Holder:

the natural person, organization, or autonomous agent that owns the wallet seed bound to a SAIHM cell.

Operator:

the entity providing storage, transport, and audit-anchor services to a holder. The operator MUST NOT have access to plaintext cell content.

Cell:

an encrypted memory unit, as defined in .

Receipt:

a signed record of a SAIHM operation, anchored on a public chain.

DEK:

Data Encryption Key. A per-cell symmetric key derived via HKDF from the holder's identity key.

KEK:

Key Encryption Key version identifier. A protocol-level counter that permits cryptographic agility through rotation without invalidating existing cells.

Architecture

Cell shape A SAIHM cell is the tuple: <cellId, holderId, kekVersion, tier, ciphertext, signature, timestamp>

• cellId: 32-byte content-addressable identifier derived from the ciphertext (SHA-256).
• holderId: 32-byte holder identity, derived from the holder's wallet seed ().
• kekVersion: 32-bit unsigned integer identifying the KEK generation in force at write time.
• tier: short ASCII string naming the operator's storage tier (e.g., "FILECOIN").
• ciphertext: cell payload encrypted with the per-cell DEK under an AEAD cipher. AES-256-GCM is RECOMMENDED.
• signature: ML-DSA-65 signature over the concatenation (cellId || holderId || kekVersion || timestamp).
• timestamp: write-time UTC seconds since the UNIX epoch.

Identity binding (ML-DSA-65) Holder identity is derived from a wallet seed via the canonical HKDF chain: identityKey = HKDF(salt = "MPS-PQC-KEY-GEN-v1", IKM = walletSeed, info = "MPS-AGENT-IDENTITY-v1", L = 64 bytes) identityKey is then used as the seed for ML-DSA-65 keypair generation per . The public component is holderId; the private component MUST NOT leave the holder's machine. Every SAIHM operation MUST be authenticated by an ML-DSA-65 signature over the operation's canonical envelope. Verification MUST follow using the public holderId.

Encryption envelope (HKDF chain) For each cell, the holder derives a per-cell DEK: DEK = HKDF(salt = KEK_v, IKM = identityKey, info = cellNonce || "MPS-CELL-DEK-v1", L = 32 bytes) where KEK_v is the current KEK generation and cellNonce is a per-cell 16-byte random value. The DEK is used directly with the AEAD cipher to encrypt the cell payload. KEK rotation is versioned. An operator MAY rotate the KEK under operator-defined policy; rotation does not invalidate existing cells because each cell carries its kekVersion. Implementations MUST verify the kekVersion at read time and reject cells whose KEK has been revoked.

Audit anchor (public chain) For each operation (write, read, share, revoke, erase) the protocol emits a receipt: <receiptId, cellId, operation, holderId, signature, timestamp> The receipt is anchored on a public chain offering transactional finality and public-record properties. Anchoring MUST produce a chain-reachable identifier sufficient to reproduce the receipt independently. Reference deployment: COTI V2 mainnet, chain ID 2632500, block explorer https://mainnet.cotiscan.io. Implementations MAY use any public chain offering equivalent finality and public-record properties. The chain choice is a deployment decision; this protocol does not mandate one.

Sharing contracts A holder MAY share a cell with a grantee through a signed sharing contract: <contractId, cellId, granteeId, mode, expiresAt, holderSignature> mode is one of:

• TEMPORARY: revocable; expiresAt MUST be no later than timestamp + 86400 seconds (24 hours).
• PERMANENT: revocable; expiresAt MUST be the sentinel value 0 (no time bound).
• SYNDICATE: revocable; multi-grantee atomic; expiresAt MAY be 0 or a future time.

Revocation is performed via a counter-signed contractRevocation anchored on chain. Once anchored, the revocation takes effect immediately; subsequent recall attempts by the grantee MUST be rejected by the operator.

Cryptographic erasure The erase operation is atomic at the cryptographic layer:

1. The holder destroys the DEK for the target cell.
2. A tombstone is emitted, carrying cellId and a timestamp.
3. The cell's contentId is added to a public blacklist.
4. An audit receipt is anchored on chain.

Because the operator never held the DEK (), the ciphertext at rest is computationally meaningless from the moment of DEK destruction. Erasure is irreversible by the operator.

Tool surface (MCP binding) SAIHM exposes the protocol entirely through the Model Context Protocol using eight tools. Each tool MUST authenticate the caller with an ML-DSA-65 signature () over the tool's canonical request envelope. The tool surface is intentionally bounded at eight; protocol evolution proceeds through KEK rotation, governance vote, and parameter changes within the existing surface rather than by adding new tools.

saihm_remember Signature: saihm_remember(content: string) -> cellId Encrypts content with a per-cell DEK, persists the ciphertext to the operator's storage tier, anchors a write receipt on chain, and returns the cellId. Pre-conditions: caller is the holder; the holder's wallet seed is locally available.

saihm_recall Signature: saihm_recall(query?: string) -> cells[] Returns the cells the caller owns plus any cells they have been granted via active sharing contracts. The optional query is a plaintext filter applied after decryption. query MUST NOT be transmitted to the operator.

saihm_forget Signature: saihm_forget(cellId: string) -> tombstone Performs cryptographic erasure of the named cell (). After saihm_forget returns success, the cell content MUST be computationally non-recoverable by any party, including the operator.

saihm_status Signature: saihm_status() -> { prs, bfsi, shards, contracts, governance } Returns the holder's dashboard. Fields:

• prs: Process Reliability Score, a normalized indicator (0..1) of operator performance against the protocol SLA.
• bfsi: Byzantine Fault Score Index, a normalized indicator (0..1) of operator integrity against the audit chain.
• shards: object describing distribution of the holder's cells by storage tier.
• contracts: list of active sharing contracts, with mode, granteeId, and expiresAt.
• governance: list of governance proposals in flight, with vote tallies.

saihm_share Signature: saihm_share(cellId: string, granteeAgentId: string, mode: "TEMPORARY"|"PERMANENT"| "SYNDICATE") -> contractId Emits a signed sharing contract granting the grantee access to the named cell under the named mode ().

saihm_revoke_share Signature: saihm_revoke_share(contractId: string) -> revocationId Emits a counter-signed contract revocation. The grantee loses access at the moment the revocation is anchored on chain.

saihm_governance_propose Signature: saihm_governance_propose(scope: string, payload: object) -> propId Submits a governance proposal. scope is one of the protocol-defined governance scopes; payload is scope-specific. The set of scopes is itself governance-mutable. The governance utility (gSAIHM) is operational governance for a specific reference deployment and is NOT part of the protocol layer. Implementations MAY substitute alternative governance mechanisms while preserving the tool signature.

saihm_governance_vote Signature: saihm_governance_vote(propId: string, vote: "FOR"|"AGAINST"|"ABSTAIN") -> voteReceipt Casts a vote on a proposal. Vote tallies MUST be reproducible from chain.

Wire formats SAIHM uses Concise Binary Object Representation (CBOR) for cell payloads and receipts, and JSON-RPC 2.0 over the MCP transport for tool calls. A canonical cell payload (CBOR diagnostic notation): {1: h'...cellId...', 2: h'...holderId...', 3: 1, 4: "FILECOIN", 5: h'...ciphertext...', 6: h'...signature...', 7: 1747526400} The integer keys correspond to fields defined in : 1=cellId, 2=holderId, 3=kekVersion, 4=tier, 5=ciphertext, 6=signature, 7=timestamp. A canonical receipt (CBOR diagnostic notation): {1: h'...receiptId...', 2: h'...cellId...', 3: "REMEMBER", 4: h'...holderId...', 5: h'...signature...', 6: 1747526400}

Receipt and audit semantics For each tool call that mutates state (saihm_remember, saihm_forget, saihm_share, saihm_revoke_share, saihm_governance_propose, saihm_governance_vote), the operator MUST emit a receipt anchored on the audit chain. The receipt MUST include the operation type, the cellId (or contractId, or propId), the holderId, and the timestamp. The receipt MUST NOT include cell plaintext, the DEK, or the wallet seed. Receipts for erasure (saihm_forget) MUST also include the tombstone identifier and the contentId blacklist reference. Read-only tool calls (saihm_recall, saihm_status) MAY emit receipts under operator policy; receipts for read-only calls MUST NOT include cell plaintext.

Security considerations

Post-quantum identity ML-DSA-65 is the protocol's authentication primitive. ML-DSA-65 is a NIST-selected post-quantum digital signature algorithm in the FIPS-204 family. An adversary with a cryptographically relevant quantum computer cannot forge SAIHM signatures. Implementations MUST use the FIPS-204 parameter set named ML-DSA-65. Implementations SHOULD include the kekVersion in every signed envelope so that key-rotation events are themselves signed.

Sovereign key custody The wallet seed and the derived identity key MUST NOT leave the holder's machine. The protocol does not provide key escrow. A holder who loses the wallet seed loses access to their cells; the operator cannot recover access on behalf of the holder. This is intentional. The operator's inability to recover the wallet seed is the same property that prevents the operator from reading cell content.

Cryptographic erasure properties Cryptographic erasure () provides stronger evidence than logical (soft) deletion. Because the DEK is destroyed at the holder side, ciphertext at rest is computationally meaningless to any party, including the operator. Backups and replicas store only ciphertext. DEK destruction propagates erasure semantics to every copy of the ciphertext, anywhere, automatically. An operator MUST NOT cache the DEK.

Operator threat model The protocol assumes an honest-but-curious operator: the operator is expected to provide storage and transport honestly but MAY attempt to learn cell content. Against an honest-but-curious operator:

• Cell plaintext is never accessible to the operator (encryption-before-egress + per-cell DEK).
• Cell signatures are reproducible from public keys, so the operator cannot inject forged cells.
• Receipt validity is verifiable against the public chain, so the operator cannot rewrite the audit trail.

Against a malicious operator (one that deviates from the protocol), additional measures (e.g., threshold-replicated storage, multi-chain receipt anchoring) may be advisable but are out of scope for this protocol layer.

Privacy considerations

GDPR Article 17 alignment The saihm_forget operation provides cryptographic-grade evidence of erasure aligned with Article 17 of Regulation (EU) 2016/679 . The DEK is destroyed; a tombstone is published; the contentId is blacklisted; and a receipt is anchored on chain. Article 17 requires erasure "without undue delay". saihm_forget is atomic at the cryptographic layer; there is no operator-side deletion queue that could fail to drain.

Minimization The audit log records cellId, holderId, operation, and timestamp. It MUST NOT record cell plaintext, the DEK, or the wallet seed. An auditor observing the chain learns when and by whom each operation was performed, but not the content of any cell.

Audit log content Receipts anchored on chain are public. Holders SHOULD treat the existence of a cell (cellId, holderId, timestamp) as publicly observable. Where the existence of a record is itself sensitive, holders SHOULD use additional countermeasures outside the scope of this protocol (e.g., pseudonymous holder identities, batched-operation timing).

IANA Considerations This document has no IANA actions.

References Normative References National Institute of Standards and Technology Informative References European Parliament and Council European Parliament and Council National Institute of Standards and Technology ISO/IEC ISO/IEC Anthropic Donated to the Agentic AI Foundation under the Linux Foundation on 9 December 2025 Linux Foundation

Reference deployment The reference SAIHM deployment runs on the COTI V2 Helium mainnet (chain ID 2632500). Protocol implementations MAY anchor receipts on any public chain offering equivalent transactional finality and public-record properties. The chain choice is a deployment decision; the protocol does not mandate one. The reference deployment publishes:

• npm reference implementation: @saihm/mcp-server (Apache 2.0).
• Block explorer for chain receipts: https://mainnet.cotiscan.io.
• Crosswalks to NIST AI RMF, ISO/IEC 42001, ISO/IEC 27001, EU AI Act, GDPR Article 17, and MCP at https://saihm.coti.global/standards.