The problem rok solves

The Problem

AI agents are stateless by default. Every conversation starts from zero , no memory of past decisions, no context from other tools, no continuity across sessions. Teams hack around this with plaintext files, vector databases, or cloud-hosted memory services, all of which share the same fundamental flaw: your data is readable by the storage provider.

This matters because agentic memory isn't just chat history. It's architecture decisions, security audit findings, API keys and rotation schedules, customer-specific context, incident postmortems, and strategic plans. As agents become more capable and autonomous — writing code, managing infrastructure, triaging alerts — the memory they accumulate becomes increasingly sensitive and increasingly valuable to attackers.

What exists today is broken in three ways:

1. No privacy. Cloud memory services (Mem0, Zep, LangMem, etc.) store plaintext or server-side encrypted data. The provider holds the keys. One breach, one rogue employee, one subpoena — and every customer's agentic context is exposed. This is the same trust model we rejected for passwords a decade ago, yet we're repeating it for AI memory.

2. No access control. When you give an agent access to memory, it's all-or-nothing. A junior dev's Cursor instance sees the same memories as a principal engineer's Claude Code session. There's no way to say "this agent can read

/engineering/decisions

but not

/finance/runway

." Teams either over-share sensitive context or don't use shared memory at all — both are bad outcomes.

3. No portability. Memory is locked to one platform. Context built in Cursor doesn't carry to Claude Code. Knowledge captured in one agent framework dies when you switch to another. Every tool reinvents its own storage format, its own sync mechanism, its own context window stuffing strategy. There's no shared substrate.

What rok does differently:

rok is an end-to-end encrypted, hierarchical memory layer for AI agents built on a dual-key cryptographic architecture.

How it works under the hood:

• A spend key (Ed25519) is the root of trust. The owner holds this. From it, a root read key (X25519) is deterministically derived via HKDF with domain separation (

  rok-v1-spend-to-root-read

  ). Child read keys are further derived per scope path —

  /engineering

  ,

  /engineering/decisions

  ,

  /finance/q1

  — forming a cryptographic hierarchy.

• When a memory is written, it's encrypted with X25519 ECDH + ChaCha20-Poly1305 using an ephemeral key pair, signed with the spend key, and serialized into a compact binary envelope (

  ROK\x01

  header). The storage backend (currently Fileverse decentralized documents) receives only opaque base64 ciphertext. It never sees plaintext, scope structure, or key material.

• Scope-based access means a read key for

  /engineering

  can automatically derive child keys and decrypt anything under

  /engineering/*

  , but cryptographically cannot access

  /finance

  or any sibling scope. This is enforced by HKDF derivation paths - not ACLs, not permissions tables, not policy engines. Math, not trust.

• Agents receive scoped read keys only. They can decrypt and read memories within their scope, and propose new memories — but cannot write directly. Proposals are staged as plaintext that the owner (spend key holder) reviews and accepts. This limits blast radius: a compromised agent can't corrupt the memory store, and a leaked read key only exposes one scope subtree.

• Batch sync with deduplication: at session end, the agent extracts new knowledge and calls

  rok_memory:sync

  . The system reads existing entries, compares content, and skips unchanged memories — avoiding unnecessary re-encryption, signature generation, and HTTP round-trips.

• Post-quantum ready: optional hybrid mode combines X25519 with ML-KEM-768 (NIST FIPS 203) for forward security against quantum adversaries.

How it's delivered:

rok ships as an MCP server with 9 tools (read, write, list, grant, propose, sync, etc.) that plug into any MCP-compatible environment: Claude Code, Cursor, Windsurf, or custom agent frameworks. Session hooks auto-load memories at conversation start and prompt sync at conversation end. The StorageBackend trait is pluggable: Fileverse today, any HTTP-compatible store tomorrow.

One encrypted memory layer. Scoped cryptographic access control. Zero trust in storage. Works everywhere MCP works.

tl;dr: rok gives AI agents persistent, end-to-end encrypted memory with hierarchical access control enforced by key derivation, not permissions. Think 1Password meets agentic context, if the vault were decentralized and every agent got exactly the keys it needs and nothing more.