Flow
From the wrong address to a guarded listen
1Sandbox points at loopback
It reaches only itself, because each container has its own loopback.
2Point it at the bridge address
The address the box uses to talk to its own containers.
3Listen everywhere
A loopback-only server won't hear the bridge, so the default opened up.
4Firewall rule does the guarding
The model port takes traffic from the bridge and nothing else.
5Check in steps
Box test, model list from the sandbox, dashboard, then one real agent turn.
Pointing the agent sandbox at loopback was how my install script told it to find the model server. Inside a container, loopback is the container. The sandbox was being told to knock on its own door.
The model server runs on my GPU box as a normal program. The agent runs in a sandbox made of Docker containers. All my tests ran on the box itself, so they all passed. None of them tested the sandbox.
Each container has its own loopback. So the sandbox needs a different address, one both sides know. That is the bridge gateway, the address the box uses to talk to its own containers. The install script now points the sandbox there. The docs list both addresses and say which one is for what.
Opening the bind was the risky half
A server that listens on loopback won't hear the bridge. So I changed the default to listen on every network the box has. That part scares me. The model server has no real login. Listening everywhere, it's open to anything that can reach the box.
A firewall rule now does the real guarding. It lets the model port take traffic from the bridge and nothing else. The bind is wide on purpose, and the rule is the wall. The script can't see that rule, so if you copy the script to a box without it, your model is public.
Listen and probe stopped being the same thing
The start script used one setting for where to listen and where to check if the server is up. Once "listen" meant every network, the health check needed separate treatment.
The health check now has its own setting, and it defaults to loopback.
A relay instead of rebinding the dashboard
The agent's dashboard also listens on loopback. I wanted to see it from my workstation over my private VPN. So a tiny relay listens on the VPN address and passes bytes to the dashboard. A firewall rule allows that port only on the VPN. The launch script won't start a second copy, writes down the process ID, and shows the log if the relay dies early. It adds no login of its own, and the dashboard thinks every visitor is local.
The smoke test was grading the envelope
The old quick test searched the whole raw reply for a marker word, and it only let the model say a few words. It could pass on the wrong text, or fail because the reply got cut short. Now it pulls out just the model's answer, needs an exact match, and gives the model room to finish.
Four checks passed, no stranger turned away
I checked it in steps: a test on the box, a model list from inside the sandbox, the dashboard from my workstation, and one real agent turn. That shows the path works. I never recorded the firewall turning away a stranger, or the rules surviving a reboot. Those two tests are next on my list.