xinbenlv

I have something embarrassing to share: my computer was compromised, and I don’t know whether my keys were leaked.

It was an old computer that I had stopped using and let my family use. Most of the sensitive things had already been cleared, but still, when they told me they had “mistakenly run some scripts, only to realize they might not be safe,” I was like... damn...

What followed that bad news was what you can imagine: rotating passwords and cleaning things up. Not knowing how bad it was, we decided to simply wipe and reinstall the entire machine.

But this incident was the last straw. I can’t stand it anymore. I consider myself very cautious and diligent in my security setup, and yet this caught me cold. Looking back, I have used 1Password and Infisical, not to mention cloud IAMs and the macOS Keychain.

But still, due to the need to run local agents and harnesses, and all the inconveniences and tradeoffs I summarized in the blog post, I decided to put some low-sensitivity credentials—API keys for LLMs and analytics, for example—in .env.local or other local files.

And God, Claude is stupid: it keeps printing credentials despite its own guardrails, my prompts, AGENTS.md, etc.

And what's worse, the OpenClaw uses MacOS Keychain which keeps asking for permission, making it extremely annoying and unuseful like the old Windows XP's "need administrator approval"

I am fed up. I decided to start building a secret broker/manager/proxy—whatever you call it. Basically, it’s meant to be a vault where my local agents can get secrets, and it should not be complicated. It should not require cloud storage or freemium nonsense, it should work reliably, and, most importantly, it should be auditable.

It should be auditable because I think agents should be able to tell the vault why they’re accessing it and what project scope they’re working within, and the vault should record that and give them the credentials.

That’s why I started building what I call “GuestSafe.” It’s not meant to be super safe, but it should do a few things really well:

- Local-first

- ffline-first

- Should enforce auditability

- Should have a scope and justification when agents request credentials

As I’m starting to build the thing, I’d like to share it with HN first and get some early feedback. You can check out the blog post I linked there.

(Disclosure: this post is hand typed with ChatGPT spell-check and grammar fix. The URL linked blog-post was written with more Codex help with my 50+ rounds of prompts)

Thanks, that's helpful. Do you use gitleaks or other library to do pre-commit protection? @toomuchtodo

And if you are interested in testing it please let me know

Thanks @pjjpo, exactly. My bad to confuse people, no we don't put real prod-prod credentials in .env. We use mechanisms to ensure separation of secrets. Thank you for saying that it's a simple yet effective implementation. If you try it and let us know your feedback.

That's a good idea too, thanks for the suggestion

Good points

I am interested, that said, there are many memory and context services. What makes this one different?

It happened multiple times to me on Claude Code too, next time I caught it I will try to record its history and show it here

My question is not about on or off storage, is more about when you give agent access, it assume the environment agent runs is safe

What if you simply need to give them access. E.g if you want them to do code review you have to at least give them code repo read access. But you don't know if the environment where agent runs will be compromised

is the permission device+client based or role based?

Any prompt injection attack could by pass this by simply do a base64 or any encoding, I guess?

Xoogler here too, yes, we used Gmail and Google Workspace at Google.

You can search for an exact string if you use quotes. I think you can also filter out logos

We use infiscial and other mechanism but hey, wouldn't it be nice to have one less square inch of attack surface?

Haha thanks my friend, well said.

Exactly, exactly

Thanks, glad you liked it!

Wise @X friends: why have major authentication providers like @auth0 and @ClerkDev and @Google / @LinkedIn SSO have not supported "Multi-Signer Authentication": instead of a single signer, simply ask for more signers to authenticate an action (login, or approval).

For example, when traditionally a low risk action would be validated with a single email confirmation, a high risk action (change password, add passkey) will require two different email confirmation with two different email domains, and plus, a user can add N email addresses (trusted contacts) and a min M of these email addresses can help approve a change of email.

This is not very much different from what @safe achieves already using smart contract, but is massively backward compatible with emails

This will massively reduce the chance of social engineering.

Let us know if you hate the idea too

So people ask us a lot why we bother to Tokenize domains and what's the value. We finally took a time to write it down

Thank you for your response. Without this MCP, I couldn't directly install MCP servers without having to find the right command / url and add them to the mcp.json. If you know which MCP server already supports this feature, I would love to use.

Congrats Erik. We are launching something that support x402 soon. DM'ed you on LinkedIn

Here are a few links for folks to poke around:

Our source code made public on Github: https://github.com/d3servelabs/d3caf

Ethereum mainnet deployment address (Implementation V1) https://etherscan.io/address/0xcfbd663cf943ace12646a0f92c53f...

See the full list in the HackMD note.

Looks pretty nice. What tech stack behind it if you mind sharing?

## Final words (first batch of answers)

Thank you all for your passionate conversations. Your criticize and defending are all super valuable and inspiring to us.

Thank NoZebra120vClip@, bawolff@, spaceman_2020@, justsomeadvice0@, duskwuff@, 8organicbits@, mvid@, greenthrow@, sacnoradhq@: you helped us think harder with your criticizing comments and questions.

World177@, sowbug@, everfree@, 40four@, peyton@ crote@ yieldcrv@, xk_id@ Thank you for your defending, your inspiration and your support! It means a lot. We also look forward to collaborate with you if interested.

> oskarw85@: That's simply not true. Even if the underlying mechanism is the public-private key pair most owners do not use it with signing in mind.

OP: Society with and without "phones" are foundamentally different. The introduction and adoption of cryptography into daily life is at this level.

In the beginning, we probably could only attract a small group of adoptors. But the monthly active editors of Wikipedia is only O(100000) and the number of editors that actively review and "like" edits are even smaller, around O(1000). This is the scale of users that have made great impact on Wikipedia and the world's knowledge.

> Considering most Wikipedia editors are under-employed guitarists and retired house painters deciding on the veracity of details about local history events and obscure scientific niches, this doesn't help much.

OP: that's true, for majority editors. But just like Balaji says in his Network State book, it only take a small group of people to start something big. We just need early adoptions from some subset of editors and hopefully if it's useful, other poeple will see it and begin using it.

> FreeTrade@: I'm interested to see an integration of wikis and web-of-trust. This looks to be a step in the right direction.

OP: yes, thank you! That's what we see in common!

> @crote: Heck, I'm having trouble seeing what makes this better than a Facebook Like!

Yes it's pretty much the same as Facebook Like, except that the accounts are decentralized so could never be banned. Also you could have a group of people "like" an edit as a group (shared identity).

> @mvid: I work in crypto, and even I ask, what makes this better than GPG?

OP: two points.

1. It helps harness the help from EVM wallet's adoption. Most people don't know how to use GPG. Most GPG tools aren't built with mind of regular user as target audience.

2. We could soon see on-chain identities, and organizational relationships linked to it. E.g. one could use ERC-1271 to have a contract attest to a signature.