Remote security
Running an agent on a remote machine means it can read and edit whatever that user can. The network posture around it deserves the same care as the SSH access you already use.
Default to loopback
Bind local services to 127.0.0.1 / localhost whenever possible. A runtime that listens on 0.0.0.0 is reachable from anywhere the firewall allows, and model servers are not built to be authentication endpoints.
Do not expose the server directly
Do not put a local runtime or an agent session on the public internet. Remote access belongs behind one of: a trusted private network, a VPN or tunnel, or a TLS reverse proxy in front of it. Each of those adds authentication and encryption that the raw service does not have.
Use strong authentication
When your deployment enables authentication, use it, and use real credentials — not a shared password written into a script. Treat API keys and server passwords as secrets: not in a repository, not in a shell history you share, not in a support message.
What is not promised
There is no custom BotConnector encrypted pairing protocol in the current public CLI. Do not design around one, and do not assume a transport is encrypted because it is on a private network — the tunnel is what makes it private.
Next
- BCCLI over Tailscale — one concrete private path.
- Network boundary — the addresses each surface actually uses.