Guest agents, walled off

What a guest gets

• An agent per project

  /launch opens a private Discord channel and starts a container for that project. Each message goes to the agent and its reply streams back live, one thread per turn.

• Their own model key

  /key set checks the key against the provider before saving it, encrypts it, and never shows it again. With no model named, a launch picks the first model the guest has a key for: paid keys first, then free tiers.

• Their own git org

  Repos and agent memory live in the guest's own Forgejo org, pushed with a bot token that belongs to that guest alone.

• A way to publish

  An agent can put a page on the web through a publishing tool scoped to that guest by its own bearer token.

• A line to the host

  /feedback files an issue for me. A blocked agent can draft a request for more access, but nothing is filed until a person clicks File this request.

Architecture

The walls

• A separate instance

  Guests run on their own copy of the orchestrator, with its own Discord bot, storage and worker names. Only its own secrets are mounted, so the credentials my agents use for infrastructure, home automation, calendar and GitHub don't exist inside it.

• A harness allowlist

  The guest instance may launch one tool pack and nothing else: git forge, web search and page publishing. There is no infrastructure control, home automation, calendar, printer or scheduling. It is a separate pack rather than an overlay on mine, so a tool I add for myself stays out until I add it to the guest pack on purpose.

• An egress firewall

  Workers sit on their own bridge network, fenced by host firewall rules: they can reach the internet, the guest git forge and the publishing service, and nothing else. The LAN, the VPN, the host and every other container network are dropped, and so are worker-to-worker and worker-to-orchestrator connections. Workers resolve names through public DNS, because the home resolvers sit behind the fence and their answers would be a map of my services.

• Fail closed

  The guest instance won't start until the firewall reports healthy, and healthy means every rule is present and in order, checked every 15 seconds against a re-assert every minute. Workers don't restart on their own after a reboot, so none can come up before the firewall does. Stopping the firewall leaves its rules in place.

• Keys encrypted at rest

  Model keys and GitHub tokens are encrypted with a key only the orchestrator holds; no worker ever receives it. A session gets only its own guest's credentials, and /key status shows the provider and last four characters, never the key.

• A usage ledger and budgets

  Every turn's tokens and cost go into a usage ledger. Each guest has a lifetime budget in US dollars; once it's spent, launches and wakes are refused until I raise it.

• Private by default

  A project channel is visible only to the person who launched it, each guest gets their own assistant, and there is no instance-wide git bot: a session with no guest behind it gets no forge access at all.

• No admin surface

  The guest instance has no web admin page, its mutating API listens on loopback only, and the integrations my own agents use (home automation buttons, schedules, cross-session spawning) are switched off. Each worker is capped at 4 GB of memory, 2 CPUs and 512 processes.

Built with

• Python
• Starlette
• Docker
• tmux
• Discord
• iptables
• Forgejo
• Komodo
• SOPS

Built and run through my own coding-agent loop, alongside the rest of the platform on the CV.