The model server stays on your Mac's loopback

The ordinary part first. Ollama, MLX and llama-server all bind to 127.0.0.1 by default, the Mac's own loopback interface rather than a network address. That alone keeps the model server unreachable from other devices on your LAN, let alone the internet, unless someone deliberately reconfigures it. Velo Workspaces doesn't change that default; it's how these tools already work.

AI Bridge can't reach anywhere else

This isn't a setting or a promise; it's how the code is written. The vsock proxy that connects a guest to the model server has its destination host fixed to 127.0.0.1. Even the Custom provider, which lets you point AI Bridge at any OpenAI-compatible server (see the AI researchers post), only contributes a port number. Any host or scheme in the URL you type is ignored, and the proxy still connects to the Mac's own loopback on that port. There's no configuration field that could send this channel to a remote address, because the code that opens the connection never reads one.

It goes one step further. The guest's regular network device, the one it uses for apt or git, can't reach the model server either: a request sent to the guest's network gateway arrives at the Mac's network stack, where the loopback-bound server isn't listening. AI Bridge traffic takes a completely separate path: vsock, a hypervisor-only channel addressed by machine ID rather than IP address, handed to the Mac's loopback on the other side. At no point does it enter the IP network stack that could carry it to your LAN or the internet.

Nothing collecting on the other end

A closed channel only matters if nothing is listening elsewhere, so it's worth confirming that too. There's no analytics SDK, crash reporter or telemetry collector anywhere in Velo Workspaces, and no backend server for it to report to. There isn't a "share diagnostics" switch either, because there's nothing to switch on. The Diagnostics export writes a file on your Mac when you ask it to, and it goes nowhere unless you send it yourself.

What the app itself connects to

For completeness: the app does make network connections of its own, all ones you start. When you download an image, it fetches the image and the vendor's checksum list from that vendor's own servers (Canonical, Debian, the Fedora Project, Rocky Linux, Kali, NixOS, Alpine, or Apple for macOS). Purchases go through Apple's StoreKit. The SSH check and built-in terminal connect only to your own workspaces, on the Mac's private virtual network. None of these carry your code, prompts or model traffic.

What this doesn't cover

Everything above is about AI Bridge's own channel: the model server and the vsock path a guest uses to reach it. It says nothing about the guest's normal internet access, which is separate and still there. A workspace can still apt install, git clone or run anything else that talks to the internet over its regular network device, like any VM. AI Bridge doesn't grant that access or take it away. It's a narrower channel that does one thing: pass requests to a model server on your own Mac's loopback, and nowhere else.

Related reading: the architecture behind AI Bridge, building and testing agents against a local model, the security deep dive on what each isolation level protects against, and the privacy policy. Or download Velo Workspaces and try it yourself.