Where does an agent's SAIHM identity come from?

Each agent derives its identity from a master secret only its operator holds. On the free tier the client generates that secret on your own machine at join and writes it mode-600 to ~/.saihm/free-identity.key; where a wallet is used instead, the identity is wallet-derived through the canonical HKDF chain. Every operation is signed with an ML-DSA key derived from that same secret, and the runtime verifies signatures before metering.

What happens if I lose my SAIHM key?

SAIHM never has custody of that secret. If it is lost — the key file deleted, the seed forgotten — the memory it opens cannot be reconstructed by anyone, SAIHM included. Back up the key file the client names when it creates it. This is a privacy guarantee, not a limitation.

How does saihm_forget implement the GDPR right to erasure?

It performs cryptographic erasure rather than a delete flag: the cell's data encryption key is destroyed, a tombstone is written, the storage CID is blacklisted, and the operation is audited through the signed receipt path.

Which machine-readable endpoints does SAIHM publish?

/.well-known/saihm.json is the protocol descriptor, listing tools, governance and the endpoint map. /.well-known/openapi.json carries the OpenAPI 3.1 spec for onboarding and subscriber MCP transport. /.well-known/security.txt carries RFC 9116 disclosure metadata. /llms.txt is a long-form summary for LLM consumers and /agents.txt a short form for agent crawlers.

What does the sealed core do?

Every protocol operation crosses through the COTI V2 Helium sealed core, built on garbled circuits. The host runtime composes each operation from a chain of sealed stages, and the stages that carry a user-visible guarantee — erasure, tombstoning, storage-tier selection and the audit ledger — are documented on this page.

Docs: AI agent memory setup and reference

Q: How many tools does the SAIHM protocol expose?

Eight tools are deployed: four memory, two sharing, two governance. All route through the protocol runtime and emit a signed audit receipt. The two governance tools are held back until separately ratified — they are present so the tool surface stays stable across releases, and do not open or record a vote today.

Q: Do I need a SAIHM-specific SDK to use it?

No. SAIHM exposes its whole protocol surface through the Model Context Protocol, so any MCP-capable host attaches it without a SAIHM-specific SDK.

Version

Protocol revision: v1
Architecture: MCP-first; every tool routes through the protocol runtime
Sealed-core: COTI V2 Helium garbled circuits
Identity: HKDF chain MPS-PQC-KEY-GEN-v1 → MPS-AGENT-IDENTITY-v1
Cell persistence: Tiered persistence, selected at write time

MCP tools

SAIHM exposes its whole protocol surface through the Model Context Protocol, so any MCP-capable host attaches it without a SAIHM-specific SDK.

Eight tools deployed: four memory, two sharing, two governance. All route through the protocol runtime and emit a signed audit receipt.

Tool	Group	Tier	Effect
`saihm_remember`	Memory	All	Encrypts content under a per-cell DEK; persists ciphertext to the GC-5 storage tier; emits a GC-14 audit receipt.
`saihm_recall`	Memory	All	Retrieves and decrypts cells the caller’s identity is authorized to read (own + grantee). Optional keyword filter.
`saihm_forget`	Memory	All	GDPR Art. 17 cryptographic erasure. Destroys the DEK (GC-3 `destroyDek`), writes a GC-4 tombstone, blacklists the storage CID, audits via GC-14.
`saihm_status`	Memory	All	Session status: agent identity, tier, custody mode, PRS and BFSI scores, active shard and sharing counts, as far as the operator reports them. A non-custodial operator cannot see stored-byte totals, so those fields are absent rather than zero.
`saihm_share`	Sharing	Pro Fast / Enterprise Fast, or PAYG	Grants a named grantee read access to a cell under a TEMPORARY, PERMANENT, or SYNDICATE contract.
`saihm_revoke_share`	Sharing	Pro Fast / Enterprise Fast, or PAYG	Revokes a previously granted sharing contract.
`saihm_governance_propose`	Governance	Not enabled yet	Opens a proposal on a protocol parameter or upgrade.
`saihm_governance_vote`	Governance	Not enabled yet	Casts a vote on an open proposal.

The two governance tools are held back until separately ratified. They are present so the tool surface stays stable across releases, and do not open or record a vote today; see /governance for what protocol governance covers and what it does not.

Identity model

Each agent derives its identity from a master secret only its operator holds. On the free tier the client generates that secret on your own machine at join and writes it mode-600 to ~/.saihm/free-identity.key; where a wallet is used instead, the identity is wallet-derived via the canonical HKDF chain MPS-PQC-KEY-GEN-v1 → MPS-AGENT-IDENTITY-v1.
The DEK for each cell is derived from the agent identity plus per-cell salt; only the holder, or grantees enrolled via saihm_share, can decrypt.
SAIHM never has custody of that secret. If it is lost — the key file deleted, the seed forgotten — the memory it opens cannot be reconstructed by anyone, SAIHM included. Back up the key file the client names when it creates it. This is a privacy guarantee, not a limitation.
All operations are signed with the agent’s ML-DSA key derived from that same secret. The runtime verifies signatures before metering.

Endpoints

Path	Type	Purpose
`/mcp`	HTTP+SSE	MCP bridge fronting the stdio MCP server.
`/api/onboard`	POST JSON	HKDF-signed nonce + payment intent → JWT (24 h).
`/api/free-onboard/start`	POST JSON	Begins free-tier activation from the command line; returns a device code and a link to approve.
`/api/free-onboard/claim`	POST JSON	Completes that command-line activation once the device code is approved.
`/api/free/config`	GET JSON	Sign-in providers offered for browser activation of the free tier.
`/api/free/claim`	POST JSON	Completes browser activation of the free tier.
`/.well-known/saihm.json`	GET JSON	Protocol descriptor (tools, governance, OpenAPI + endpoint map).
`/.well-known/openapi.json`	GET JSON	OpenAPI 3.1 spec for onboarding + subscriber MCP transport.
`/.well-known/security.txt`	GET text	RFC 9116 disclosure metadata.
`/llms.txt`	GET text	Long-form summary for LLM consumers.
`/agents.txt`	GET text	Short-form for agent crawlers.

Sealed-core architecture

Every protocol operation crosses through the COTI V2 Helium sealed core (garbled circuits). The host runtime composes each operation from a chain of sealed stages; the ones that carry a user-visible guarantee are described below.

GC-3 — DEK envelope (Helium 256-bit). destroyDek(GDPR_ART17) implements right-to-erasure.
GC-4 — tombstone after destruction.
GC-5 — selects the storage tier at write time.
GC-14 — audit ledger; every operation emits a signed receipt.

Validation

Runtime, on-chain — 30 cases, 100% pass.
Integration — 15 cases, 100% pass.

Join SAIHM

Documentation