This is months of thinking about what to give a self-hosted agent access to: what I tried and uninstalled, how Proton Pass became the credential surface, and where the Matrix approval pattern ended up versus where it started.
TL;DR
- I installed Openclaw, it kept me up one night, and I uninstalled it the next morning.
- Proton Pass is the credential layer: separate vaults per project, each its own blast radius.
- Two long-running Hermes Agents now run: Hidalgo on a ThinkPad with its own ESP32 workbench, and Hiero in its own vcluster on the Talos cluster.
- Matrix is still up and works; Discord is what I use more right now because I already had a server and this stage is mostly experimentation.
What I was solving for
The interesting question wasn’t how to run a self-hosted agent. It was what I was willing to let one touch. My homelab has git repos, a Debian server, a Kubernetes cluster, DNS zones, and cameras. An agent with broad access could do real damage. An agent with no access is a chatbot. I wanted the middle ground: enough capability to be useful, scoped tightly enough that a mistake or prompt-injection event wouldn’t ruin my week.
The three-layer guardrail
The credential roadmap sits on top of three layers:
- Least-privilege at the credential layer. Each capability gets its own scoped credential, its own Secret, and narrow RBAC at the source.
- A custom pre-tool hook (safety.sh) layered on top of Hermes Agent’s built-in dangerous-command floor. It adds homelab-specific blocks the framework doesn’t know about:
kubectl delete namespaceon protected namespaces,kubectl delete pvanddelete node,talosctl reset/wipe,sudo iptables -F(which would break the Debian NAT gateway),sudo systemctl stopontailscaled/ssh/sshd(which would lock me out of the Debian box), sudo power-state commands, andgit push --forceoutside the sandbox org. When it blocks, it posts to a Matrix notification room. - Ask-first in the personality. The SOUL.md file encodes an “ask first, build second” voice. I answer in-thread; the agent doesn’t act unilaterally on big changes.
Hiero’s credential roadmap
This is the practical answer to “what access.” Four steps, lowest-risk first:
- Forgejo Personal Access Token. Write access to a sandbox organization’s repos, read:organization, write:issue, read:user. Intentionally not
write:organization. Repo creation still goes through me. The agent can clone, commit, push, and open issues; it cannot create new repos. - Debian SSH key. A dedicated ed25519 keypair. The public key is authorized only for a specific dedicated user account on the Debian server. The private key lives only as a Kubernetes Secret inside the vcluster; it never touches my workstation.
- Read-only host Kubernetes kubeconfig. A ServiceAccount on the host cluster bound to
viewplus a custom ClusterRole that adds nodes, PersistentVolumes, StorageClasses, CRDs, IngressClasses, and other cluster-scoped reads. The built-inviewrole doesn’t include those. I minted a long-lived service-account token Secret directly because modern Kubernetes doesn’t auto-create one anymore. - Cloudflare DNS token. Scoped to Zone:DNS:Edit on my private zone only. No expiration, no IP filter.
Each credential ships in its own Kubernetes Secret. Each has its own RBAC gate at the source. Rotation procedures are documented per credential.
Where the credentials sit (Proton Pass)
I use Proton Pass as the credential surface. Every project gets its own vault, and each vault is its own blast radius. An agent assigned to one vault sees only the entries in that vault. It doesn’t see other projects. It doesn’t see a master vault. It sees exactly what it needs.
I refused the obvious path of dropping one big secrets bundle somewhere and handing the agent a key to it. If an agent gets compromised, I want the damage to stop at the vault it was holding.
The two long-running agents today
Both agents are built on the Hermes Agent framework from Nous Research. It’s open source, I can inspect it, run it locally, and modify it without a hosted control plane.
Hidalgo runs on a ThinkPad T480s with Fedora Atomic and SwayWM. It has its own ESP32 workbench with 2 ESP32 boards hooked up to it, and it can run experiments I think of or tweak on the go when I run ideas past it on Discord. I think that’s neat as hell.
Hiero runs inside its own vcluster on the Talos cluster. A vcluster gives it a virtual Kubernetes control plane with its own API server and CRDs, no shared state with the host cluster. Its storage is on Longhorn with daily snapshots and 7 retained.
The LLM backends behind both agents get swapped regularly for testing. I won’t name the specific models because we’ll have changed them by the time you read this.
A 3 GB GGUF incident
When Hiero was first being deployed, a manifest pulled a roughly 3 GB GGUF model from the public internet at line rate. The cluster has no direct egress, so the pull went through the Debian server’s WiFi NAT. Debian dropped off the tailnet for hours, probably from conntrack overflow or the WiFi NIC wedging. I was about six hours away from the box. Recovery took a physical power-cycle when I got home. Afterward I added rate limits on large pulls (5 MB/s), GGUF magic-header validation, and curl -C resume support. It was a good reminder that the gateway’s blast radius is real even when the agent itself is contained.
Matrix and Discord
The original plan was Matrix all the way. Synapse runs in the cluster, exposed to the tailnet through the Tailscale Operator, with Let’s Encrypt HTTPS from cert-manager. End-to-end encrypted rooms are available.
In practice I already had a Discord server. Adding the agents to it took minutes. Discord is currently being used more in this specific stage of integration and experimentation. Matrix is still up and still works.
If my communications with the agents were more sensitive I’d probably move back to Matrix only. Right now the traffic is just poking and prodding the agents, figuring out what works, what doesn’t, and research.
What I tried and quickly pivoted from (Openclaw)
I originally installed Openclaw. That night I couldn’t sleep. The next morning I uninstalled it.
It literally kept me up that night. I had a dream that I had inadvertently DDoSed Github. That was a real dream I had, and was in the middle of trying to figure out how much legal trouble I was in when I (thankfully) woke up.
That was enough. The public timeline of Openclaw’s rise and fall is documented better than I could reconstruct it: https://www.glukhov.org/ai-systems/openclaw/openclaw-rise-and-fall-timeline/. I won’t add a timeline from my point of view to it.
What I learned
I learned that the credential layer is the part worth designing first. The agent framework matters, the compute layer matters, but if you can’t say exactly what an agent is allowed to touch and where that permission stops, the rest is decoration.
I also learned that “try it and uninstall it the next day” is a valid research step. Openclaw taught me more in one night than I would have learned by reading about it for a week.