Hobelbank

#What it is

Hobelbank is the umbrella over the projects below. They share one question: how do you build software in the age of AI? Each project takes on one part of the answer, from the world an agent works in to the guards on its way out.

This repository holds no code. It explains the pieces, where each one sits, and how they are meant to connect. Each piece’s own repo stays the source of truth for what it does; this map only links them up.

#Current status

Last updated 6 November 2026 · main@0efffd1

Hobelbank is a docs-only map of the workshop. The readme names every released piece, where it sits among habitat, inhabitant and wall, how the pieces are meant to connect, the shared design philosophy and the risks each measure reduces. Two diagrams show the essential setup and the full map. A glossary keeps the words the same across the repos. There is no release yet. The license matches the rest of the workshop.

This repository holds no code and no runnable setup. The pieces do not yet run together end to end: example configs and Compose files that would let them work as one are still open work. Some named pieces are ideas only, such as the package proxy and scanner. The map can lag a piece's own repository when that piece moves faster than the map is updated.

#The problem

What follows is what I have run into so far and the working hypothesis the workshop is built on, not a settled finding.

Working with agents, I keep running into a trade-off between autonomy and control. Agents seem to do their best work with broad rights, and for coding agents shell access has mattered most. But an agent with a shell can step around other safety measures, for example by calling the Azure CLI directly instead of going through the Azure MCP server.

Many approaches limit the tools an agent may use. In my practical work, though, I have rarely been able to predict which tool an agent would need to solve a problem. That points towards giving it broad rights, and doing that without any check seems reckless.

My working hypothesis is that control is still needed, but of a particular kind: control the agent cannot get around, and control that needs no human. It decides on its own and never waits for anyone. The wall blocks by itself, and you hear about it afterwards; you are told, not asked to approve.

Simon Willison calls the dangerous mix the lethal trifecta: access to private data, exposure to untrusted content, and a way to send data out. The wall works on the third part without taking tools away from the agent. It does not close the way out completely: only allowlisted destinations such as model APIs and package registries are reachable, and every request is logged.

#The picture

The pieces form three layers around one rule: an agent may do anything inside its world, and everything that controls it lives outside, where it cannot reach.

1. Habitat. Hermetarium boots an agent inside an OCI image, behind a wall. Inside, the agent is root.
2. Inhabitants. Agents that live in a habitat and build software there. Fregoli is one of them; others can move in too.
3. Wall services. Everything that sits on the wall, on the only network path: the I/O log today, a package proxy with a scanner later.

Some wall services may use a model of their own, like the AI security scanner. Such wall agents are trusted more than inhabitants, because they see what crosses the wall and decide on it. In return they may do far less: no shell and no tools, only reading what they are handed and answering.

Around the habitat sit tools the agents use, like grok-budget-mcp and claude-budget-mcp, and guards on the way to the Git remote, like Git Warden. Helferlein is a building block for the pages an inhabitant serves, not part of the wall.

The essential pieces: a supervisor starts an inhabitant behind a wall, and all its traffic leaves through Squid.

#The pieces

Piece	Layer	State	Where
Hermetarium	Habitat		pihme/hermetarium · website
Sandbox logging	Wall service, part of Hermetarium	Built: Squid access log turned into io.jsonl, metadata only	Hermetarium
Fregoli	Inhabitant		pihme/fregoli · website
grok-budget-mcp	Tool for agents		pihme/grok-budget-mcp · website
claude-budget-mcp	Tool for agents	, tested live	pihme/claude-budget-mcp · website
Package proxy and AI security scanner	Wall service (or tool inside)	Idea with an architecture sketch	Not public yet
Git Warden	Guards between agents and their Git remote: a Push Guard that checks every push, a Backup Guard that keeps an append-only backup of every branch and tag		pihme/git-warden · website
Helferlein	Building block for an app’s web page, outside the three layers: an animated 3D avatar that shows when an agent is working		pihme/helferlein · website

All released pieces are public and have their own website.

The full map with every piece. Dashed lines and boxes are not built yet.

#How they connect

• Fregoli lives in Hermetarium. Fregoli’s own image serves its web app, and its docs recommend Hermetarium as the place to run it, but do not require it. It has not moved in yet: the server only binds 127.0.0.1 (fregoli#1).
• Keys never enter the habitat. Hermetarium’s Squid injects API keys from the host-side ACL. grok-budget-mcp inside a habitat would work the same way, with a placeholder auth.json in the image and the real token added on the wall.
• claude-budget-mcp is the same tool for Claude Code. It reads the 5-hour and weekly limits from Claude Code’s own login and never refreshes the token, so everything said here about grok-budget-mcp applies to it too. Inside a habitat its placeholder would be a .credentials.json.
• grok-budget-mcp has two possible places. Inside a habitat, an agent asks how much of its weekly budget is left. Next to the supervisor, a watching agent could put a habitat to sleep when the budget is empty and wake it after the reset. Hermetarium has no sleep and wake yet.
• The scanner shares the wall. Every package fetch already crosses Squid. A package proxy there would store, scan and re-serve what agents download, using the same choke point and log as the I/O log.
• Git Warden keeps Git credentials out of habitats. Agents push to the warden instead of their Git remote, and only the warden can write there. Built and released (pihme/git-warden).
• Helferlein could give an inhabitant’s web app a face. It is an animated 3D avatar that a page summons and drives with events. A possible host is an app like Fregoli; no piece uses it yet (pihme/helferlein).

#Design philosophy

1. Keep it simple. Each piece does one job with as few moving parts as it can. A small piece is easier to check, to replace and to trust.
2. Set and forget. You set up an agent’s world once, and after that the agent never stops to ask you for permission. The decisions live outside, where the agent cannot reach them.
3. Batteries included, assembly required. Together the pieces make a working setup, but it is meant to be adapted: your images, your allowlists, your agents.
4. Bricks, not a stack. The pieces fit together, and each one can be swapped for something else that does the same job.
5. The good side of Pareto. Aim for the solution that solves 80% of the problems with a fraction of the effort, and leave the rest out rather than make everything heavier.
6. The show must go on. A check never stops the job. When something looks wrong, it is held back and you are warned, but the agent keeps working.

#Shared principles

• Freedom inside, control outside. The agent cannot switch off the wall or its log.
• One logged network path. If it cannot be set up, the habitat does not start.
• Secrets stay outside the image and are added on the way out.
• Things are reversible: habitats can be thrown away, Fregoli’s plugins can be unloaded.
• Less unchecked foreign code: agents write most of their own code, and what they download is logged.

#Risks and measures

The risks of giving an agent broad rights are leaking information, leaking or misusing secrets, downloading malicious code, a compromised agent, harmful changes to code, and harmful changes to infrastructure. Each measure below reduces some of them, but none removes a risk completely.

Harmful changes to infrastructure are reduced the least. The wall protects the host, and Git Warden would catch infrastructure kept as code. But if a cloud API is on the allowlist and its key is added on the wall, an agent can call it directly, as with the Azure CLI in The problem, and only the allowlist and the log stand in the way.

#Roadmap

Planned milestones; neither has been released yet.

• 1.0: MVPs for all components, tested with a closed-source agent harness.
• 2.0: All components work together as an integrated system, with an open-source agent harness as the reference implementation. This also marks the start of dogfooding: I plan to use these tools in my own projects.

#Glossary

Words used the same way across all repos of the workshop.