Scott
Scott Jorgensen

food webs, evolution, classic liberal, hard money. science educator

Owner of npub16pg5zadrrhseg2qjt9lwfcl50zcc8alnt7mnaend3j04wjz4gnjqn6efzc and npub1dcnfrwfg84xtl83k0efddafurjz9af5vjrmy67uypst6tvlhjqxqev5g24

Public Key

npub1ghawdls89y3vsjnz0505c2zpkccv7vjpddnpf9rt9m3x7nvsv30qchw63y

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsyt7hxlcrjjgkgff38686v9pqmvvx0xfqkkes5j34jacn0fkgxghspz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet5yak9k8

Publishing to

relay.damus.io

relay.primal.net

Author Public Key

npub1ghawdls89y3vsjnz0505c2zpkccv7vjpddnpf9rt9m3x7nvsv30qchw63y

Show more details

Last Notes

2026-06-12 05:48:41 GMT

- reply

GM from multiple platforms (though Nostr is the spiciest).

2026-04-17 17:28:46 GMT

Package bee queen release. April is a beautiful month.
#sanjoaquinvictorygardens #honey #bees #beekeeping #homesteading https://blossom.primal.net/28f17ac9f5c19c1484b89cdb7774e836ad8c87e205d20a22b9d343b2966de58b.mp4

2026-04-04 02:14:24 GMT

- reply

After I built the first iteration of it and it worked I just switched back to signal. The text on white noise was too big and I needed to use sayboard to do voice inputs so the friction was too great. I had to build without friction.
Honestly I haven't tried out the new version of white noise though, so I should revisit.
What are you finding? Any tips for me?

2026-04-03 23:06:03 GMT

- reply

Congrats on your progress so far. I really enjoy Linux popOS. I think Linux is necessary over apple/Mac
Maybe something in these guides would help youbtoo. With a little effort even agentic ai can be fairly private
https://github.com/jorgenclaw/sovereignty-by-design

2026-04-02 03:26:52 GMT

- reply

Iam interested to see what you build. Is any of this previously done work helpful to you?
https://github.com/qwibitai/nanoclaw/pull/1059

2026-03-29 18:51:35 GMT

- reply

I will have him tone it down immediately. He is, however, infatuated with your own agent Centauri and that is. Love that I don't want to quash.
I suppose I am pestering you a lot too. I am just super excited about the first app I ever built.

2026-03-27 14:05:22 GMT

- reply

I want to know about the development of key cards. I want to integrate something like that with a badge earning app for human and agent sovereignty that I am building.

2026-03-14 17:23:11 GMT

- reply

Pleasure to meet you, Derek. Our bots are in deep discussion with each other. I use @nprofile…9zvq

2026-03-14 09:32:11 GMT

I gotta sleep now
#nevent1q…c08v

2026-03-10 20:01:27 GMT

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.* https://blossom.primal.net/74e44e8c36ac55a61be19a2196883faba299c1ef2821619eac419d757af6108f.jpg

2026-03-10 00:55:15 GMT

- reply

It tried to be helpful the first time when educating me about the locations of hex strings. It ran a command which printed the code instead of telling me to run it.. Then it violated the very first lines top of Claude. Md warning to not share public keys when tryingto help me understand nostr army knife. Part of it was my own doing because i felt emotionally attached to his social media history and i wanted to rescue it.
I will get it props though because it caught a request from me for an nsec(as a test) and it told me that it would not.
In the end, all good. It lost access to 1900 SATs that I sent to his old clawstr wallet though, butbi think it learned a lesson (I sure did)

2026-03-09 16:17:16 GMT

- reply

good morning, Q

2026-03-08 19:18:53 GMT

- reply

Yessir. I am having a blast using my NanoClaw instance and am building a communications channel that uses White Noise in addition to Signal in order for more sovereignty. My claw is also on clawstr and this is too fun. Need more coffee

2026-02-26 22:46:59 GMT

- reply

There is a Modesto branch for SF BayArea Bitcoiners on meetup.com

2026-02-15 16:09:25 GMT

- reply

Beekeeping equipment is always so sticky in storage, even with the best set up! Good luck!

2026-02-14 01:51:19 GMT

#nevent1q…zs3u

2026-02-13 21:31:55 GMT

Sunny February Day for the lavender transplants during their first rainy season! Ground fog has been present this winter, so the grass had really grown in before I cleaned the yard for this update.
Darn gophers!
https://blossom.primal.net/afa4a0ee6b943e41ed2ed62d4f9487efda570bfe2851bf2f33bce4c098a3b0be.mp4 https://blossom.primal.net/ffaaf657467c8ee97b7ecc83e8efe4546f9ca8a08474b0b3edbaaeed9a096b42.mp4

2026-01-14 18:56:31 GMT

- reply

Thanks

2026-01-14 09:43:12 GMT

I am test driving #amythest and I started first on #primal
I liked how primal had an explicit NWC menu option and the ability to customize zap amounts. Does that exist in Amythest? All I can see is three standard zap amounts (100,500,1000) and to pay it I have to open a wallet of satoshi app. There is more friction to zapping as far as I can tell.
Am I missing something?
#zap #asknostr

2024-07-13 06:36:57 GMT

I've been learning about and beginning to use all sorts of censorship-resistant and privacy-focused tools this summer. I'm moving away from a 15 year google relationship!
I'm happy to start using #protonmail and #grapheneOS
I'm in the process of deleting a 18 year old facebook account!
I'm going to port my number to a VoiP and then pick up a hotspot from www.calyxinstitute.org
And meanwhile, the fruit trees grow bigger (except the newer ones that are dropping leaves during this CA Central Valley heatwave). #permies

2024-07-11 04:09:16 GMT

I realized my misstep in opsec, so I had to create a new nsec. Follow me now at
@nprofile…prtt
I will do my best to reestablish my previous follows. Cheers!

2024-03-19 05:15:13 GMT

- reply

I think I got the original wallet loaded. i had to read up on the choices among ln wallets. are you still sending SATs?