I would split the agent loop totally from the main project of tightbeam, no one wants yet another new agent harness we need to focus on the operational problems. Airlock seems interesting in theory but its really hard to believe this could capture every single behaviour of the native local binaries, we need the native tools with native behaviour otherwise might as well use something like MCP. I would bet more on a git protocol proxy and native solutions for each of these.
Good points across the board. I ran into a lot of problems auditing the security of my approach and it was just too easy to circumvent.
First lesson was that the architecture had to be secure in structure, not configuration. Otherwise, a novice will run claude code on the host machine and just bork the entire setup.
So now I've replaced tightbeam runtime with a small runtime on the workspace container. Tightbeam and Airlock have been moved to separate pods. So you don't need network egress on the workspace pod at all.
Secondly, I'm isolating credentials on Tightbeam and Airlock with k8s jobs. Rather than airlock full CLI commands, you just create "airlock tools" with k8s secrets. Airlock controller never sees the secret. The tool could be like "git-create-branch" and "gh-create-pr".
Tightbeam is pretty much symmetrical. LLM credentials are tied to jobs.
I'm tying them together into a unified architecture now. Please do let me know if you have additional thoughts!