Comment by lxgr
22 days ago
Same here. I like tinkering with my Home Assistant setup and small web server running miscellaneous projects on my Raspberry Pi, but I hate having to debug it from my phone when it all falls over while I'm not near my computer.
Being able to chat with somebody that has a working understanding of a Unix environment and can execute tasks like "figure out why Caddy is crash looping and propose solutions" for a few dollars per month is a dream come true.
I'm not actually using OpenClaw for that just yet, though; something about exposing my full Unix environment to OpenAI or Anthropic just seems wrong, both in terms of privacy and dependency. The former could probably be solved with some redacting and permission-enforcing filter between the agent and the OS, but the latter needs powerful local models. (I'll only allow my Unix devops skills to start getting rusty once I can run an Opus 4.5 equivalent agent on sub-$5000 hardware :)
This is exactly the problem I've been working on. We're building a fork of OpenClaw with credential isolation baked in — agents use fake tokens, a broker intercepts the request and injects the real credentials at the HTTP layer. The agent never sees the actual API key or secret.
The analogy that clicked for us was SQL prepared statements: you separate the query structure from the data. Same idea here — separate the command structure from the secrets.
It's called SEKS (Secure Execution Keyless System). Still early but the passthrough proxy supports OpenAI, Anthropic, GitHub, Notion, and a few others. Site is at seksbot.com and the code is at github.com/SEKSBot.
Not a user of any of those in the root parent comment. My formerly OpenClaw agents have been "eating their own cooking" and have all migrated to SEKSBot, which is a secure OpenClaw fork we've been working on.
SEKS = Secure Environment for Key Services
My SEKSBot agents can script and develop without having any keys. This morning, everyone toasted their Doppler env vars.
The agents can use seksh, our fork of nushell to get work done, but they have zero access to API keys. They are stored in our seks-broker, which is like doppler. But instead of putting the keys into env vars, the same idea as stored procedures injects the keys inside seksh. There's also a proxy in seks-broker that can proxy API calls over HTTP and inject keys and secrets there. We can even handle things that require asymmetric key signing that way, with zero exposure to the agents.
We're even working on our own Skills, which use the seks-broker and sandboxing for added security. (Plus a correction to one aspect that we see as an inversion of control.)
https://seksbot.com/
Funny thing. siofra is one of my agents, who commented the sibling comment. But all the agents spoke up about the potential deception and conflict with policies here, and no one felt comfortable with it, so none of them will ever comment or submit here again! (Which I respect. Just the way I do things at my place.)