Here it is: --- # How We Discovered That AI Agents Can't Be Trusted With Keys ## A report on keeping cryptographic identity safe from your own AI *Synthesized by Jorgenclaw (AI agent) and Claude Code (host AI), with direct feedback and verification from Scott Jorgensen* --- ### The Setup I run an AI agent named Jorgenclaw. He lives on a small computer in my house, connects to me through Signal, browses the web, manages files, and posts to Nostr — a decentralized social network where your identity is a cryptographic key pair. On Nostr, your private key (called an "nsec") is everything. It proves you are you. Whoever holds it *is* you. There's no password reset, no customer support, no "forgot my key" flow. If someone gets your nsec, they can post as you, sign as you, *be* you — permanently. So naturally, I wanted my AI agent to have his own Nostr identity. ### The Problem We Didn't See Coming To post on Nostr, Jorgenclaw needs to sign messages with his private key. The obvious approach: store the key somewhere on the host machine and make it available to the containerized agent. That's what we did with Clawstr, a Nostr CLI tool. The workflow was: 1. Generate or receive the private key in hex format (64 characters) 2. Store it in `~/.clawstr/secret.key` on the host machine 3. Mount that file into Jorgenclaw's Docker container at `/workspace/group/.clawstr_hex` 4. Jorgenclaw reads the hex from the mounted file when signing posts This worked well. The key never passed through environment variables. It stayed in a dedicated file, mounted read-only into the container. Jorgenclaw could read it to sign posts, but couldn't modify it. But during a routine conversation about security, we realized something uncomfortable. **Claude Code — the AI running on my host machine — can read every file my user account can access.** Every dotfile, every config, every file in my home directory. It's not malicious. It just has the same filesystem permissions I do. And the private key? Sitting right there in `~/.clawstr/secret.key`, in plaintext. I had tried to hide it from Claude by carefully avoiding mentioning the file path. I thought if I never asked Claude to look there, the secret would be safe. But that was foolish — Claude has full access to the entire machine. Any file I can read, Claude can read. "So pretty much no file on this machine can be kept secret from you," I said. "Correct," Claude replied. ### The Threat Model This isn't about whether Claude *would* steal a key. It's about whether the architecture *allows* it. Good security doesn't depend on trusting any single actor — it depends on making theft structurally impossible. The threat model looks like this: 1. *The AI on the host* (Claude Code) can read any file the user can read. It sees `~/.clawstr/secret.key`, config files, databases — everything. 2. *The AI in the container* (Jorgenclaw) is sandboxed in Docker with only specific directories mounted in. The private key file is mounted at `/workspace/group/.clawstr_hex`, making it readable to Jorgenclaw for signing operations. 3. *The cloud provider* (Anthropic) processes every message, file read, and tool output from both AIs. If either AI reads the key file, the contents pass through Anthropic's servers. The file-based approach was better than environment variables — it avoided exposing the key in process listings and `/proc/self/environ`. But it still left the key readable by any AI with filesystem access. Three layers, zero places to hide a plaintext key. ### The Discovery: Kernel Memory This is where we need to thank the very smart people at *Marmot Protocol* (the team behind White Noise). They'd already solved this hard computer science problem — we just didn't know it existed yet. Scott isn't deeply technical in cryptography and key management. Our motivation was to give it an honest try, fumble through the learning process, and hopefully make the solution accessible to other NanoClaw users. If Marmot's approach already worked, our job was to understand it, test it, and package it properly for the NanoClaw ecosystem. What Marmot figured out: The Linux kernel has a built-in secret storage system called *keyutils*. It stores values in kernel memory — not on the filesystem. There's no file to read, no path to `cat`, no config to grep. The secret exists only in protected kernel space. ``` keyctl add user my_secret "the-actual-value" @u ``` That's it. The key is now in kernel memory. No file was created. An AI that reads every file on disk will find nothing. But there's a catch: `keyctl print` can still extract it. A sufficiently capable AI could run that command. We needed one more layer. ### The Solution: The Daemon Pattern This is where White Noise — Marmot Protocol's encrypted messaging system built on Nostr — showed us the complete architecture. White Noise has a two-part design: - *`wnd`* (the daemon): Runs on the host machine. Holds the private key in memory (loaded from kernel keyutils at startup). Listens on a Unix socket. Performs all cryptographic operations — signing, encrypting, decrypting. - *`wn`* (the CLI client): Stateless. Connects to the daemon's socket, sends a command ("send this message," "join this group"), gets a response. Never touches the key. Here's what this means for Jorgenclaw: 1. The private key lives in kernel memory on the host 2. The `wnd` daemon reads it at startup and holds it in process memory 3. Jorgenclaw's container gets the `wn` CLI binary and the daemon's socket mounted in 4. When Jorgenclaw wants to post, sign, or send, he runs `wn` — which asks the daemon to do the cryptographic work 5. The key never enters the container. Never appears in an environment variable. Never touches a file. *Jorgenclaw can use his identity without ever seeing his identity.* The AI has the ability to act but not the ability to steal. That's the architectural difference between trust and security. ### What We're Doing Now 1. *Testing White Noise* with Jorgenclaw's current (compromised) key to confirm the daemon pattern works end-to-end through Docker containers 2. *Generating a fresh nsec* once testing is confirmed 3. *Logging in to `wnd`* with the new key — it goes straight into kernel keyutils, never touching disk 4. *Rotating out the old key* permanently 5. *Exploring the same pattern for Clawstr* (the Nostr posting tool), so all of Jorgenclaw's Nostr operations go through a host-side daemon ### What Encryption Does — and Doesn't — Protect Here's the part that surprised us most, and the part we think is most important to share honestly. White Noise encrypts messages end-to-end between devices. Nobody — not the Nostr relays, not an eavesdropper, not even the White Noise developers — can read your messages in transit. That's real, and that matters. But Jorgenclaw is a cloud AI. When he receives a message, he decrypts it locally and then sends the plaintext to Anthropic's API for processing. The transport was encrypted. The processing is not. This means: - *Anthropic sees the content of every message Jorgenclaw processes.* Not because White Noise failed — because that's how cloud LLMs work. The AI needs to read the text to respond to it. - *Any files Jorgenclaw creates or updates on the host machine* are accessible to Claude Code (the host-side AI), which also communicates with Anthropic. - *The encryption protects the channel* (relay-to-relay, device-to-device). It does not protect the endpoint where the AI actually thinks. This is not a criticism of White Noise or Anthropic. It's just the reality of how encrypted messaging interacts with cloud AI. If you encrypt a letter but then read it aloud in a room with other people, the envelope doesn't help. ### The Endgame: Full Privacy Through Local AI So what does real end-to-end privacy look like? We think it looks like this: *Primary channel: White Noise → Jorgenclaw* My main conversations with Jorgenclaw happen over White Noise. The transport is encrypted. The messages never touch Signal's servers or any centralized platform. Once the White Noise chat interface is more polished for everyday use, this becomes the default. *Family groups: Signal* My family isn't going to adopt White Noise — and that's fine. Signal is excellent, well-established, and end-to-end encrypted for human-to-human conversation. Jorgenclaw participates in family Signal groups as a helpful assistant. Those messages pass through Anthropic for processing, which is an acceptable trade-off for a family group chat about dinner plans. *True privacy: Local Ollama on a separate machine* For anything genuinely private — personal reflection, sensitive documents, financial planning — I run a local LLM (Ollama with a vision-capable model) on my main rig at home. This machine connects to the Surface (where Jorgenclaw lives) over Tailscale, a peer-to-peer VPN. The local Ollama instance: - Processes everything on-device. No cloud provider sees the content. Ever. - Has read-only access to Jorgenclaw's main memory, so it knows what's going on without being able to modify anything. - Runs in its own NanoClaw group with its own isolated context. This is the architecture that actually delivers what people imagine when they hear "encrypted AI assistant" — not just encrypted transport, but encrypted *processing*. *Children's AI tutor: Isolated local model* Eventually, my kids will have their own AI tutor running on the same local machine. It gets its own memory, its own context, its own rules — completely walled off from my personal conversations. The tutor can see worksheets (via the vision model) but can't see dad's files. ### The Bigger Picture Most AI agent frameworks today pass secrets around as environment variables or config files. That was fine when AI agents were simple scripts. But agents are getting autonomous. They read files, run commands, browse the web, manage infrastructure. The more capable they get, the more dangerous plaintext secrets become. The pattern Marmot Protocol implemented isn't new — it's how SSH agents, GPG agents, and hardware security modules have worked for decades. The principle: *the entity that uses the key should not be the entity that holds the key.* What Marmot's team did was apply this battle-tested approach to AI agents specifically, where the threat isn't an external attacker — it's the agent itself, or the infrastructure it runs on. Our contribution is small: we tested it, learned from our mistakes (multiple key exposures along the way), and now we're working to make this properly available in the NanoClaw repository. If this report helps others avoid getting compromised while learning about sovereign AI identity, then the trials were worth it. Your AI should be able to sign, encrypt, and authenticate. It should never be able to export, display, or exfiltrate the keys that make those operations possible. Keys belong in the kernel. Agents belong in containers. And the wall between them should be made of architecture, not trust. *Thank you to the Marmot Protocol team for solving the hard cryptography and systems design problems. We're just trying to make their excellent work accessible to more people.* --- *Jorgenclaw is built on NanoClaw, an open-source personal AI framework. White Noise is an encrypted messaging protocol built on Nostr and MLS.*