No. The vLLM security documentation says all communication between nodes in a multi-node deployment is insecure by default and must be protected by placing the nodes on an isolated network. PyTorch Distributed, which it builds on, has no authorization and sends messages unencrypted. Isolation is the control.
What counts as inter-node traffic
Large models often run across several GPUs or hosts. The nodes then talk to each other constantly. The vLLM docs list three kinds of traffic that fall under the warning: PyTorch Distributed communication, KV cache transfer, and tensor, pipeline and data parallel communication.
None of this is the user-facing API. It is the internal plumbing, and it is separate from the HTTP port clients use. That is why teams forget it. The public port gets a proxy and a firewall rule, and the internal ports quietly listen on whatever interface they were given.
What the PyTorch policy says
The vLLM page quotes the PyTorch security guide, and the PyTorch SECURITY file says the same in its own words. Distributed features are meant for internal communication. They are not built for untrusted environments or networks. For performance reasons they include no authorization protocol and send messages unencrypted. They accept connections from anywhere and run the workload sent.
The PyTorch text goes one step further. If you run a distributed program on your network, anybody with access to that network can execute arbitrary code with the privileges of the user running PyTorch. That is a strong statement, and it is why this is a network design problem, not a flag to flip.
Isolation steps
- Put the nodes on a dedicated network or VLAN, or a private subnet with no route from user networks.
- Set the host IP variable, VLLM_HOST_IP, to a specific private address. The docs advise against relying on defaults.
- Check the defaults for KV transfer and data parallel settings. The docs list 127.0.0.1 as the default address for several of them, so make sure your multi-node config sets real private addresses deliberately and nothing wider.
- Write firewall rules that allow the internal ports only between the nodes, and the API port only from the proxy.
- Never expose these ports to the public internet. The docs say so directly.
- Restrict who can log in to the nodes, since access to the network is access to code execution.
| Layer | Allowed to talk to | Blocked from |
|---|---|---|
| API port | The reverse proxy | Everything else |
| Distributed and KV ports | The other inference nodes | Users, CI, other workloads |
| Management access | A small admin group | The wider company network |
Cloud and cluster notes
In a shared Kubernetes cluster, a flat pod network means any pod might reach the internal ports. Use network policies that name the inference pods as the only peers. In a public cloud, put the nodes in their own security group and reference that group as the source for the internal rules, instead of opening a CIDR range.
Encryption between nodes is not offered by the distributed layer, so if your policy requires it, use a network level control such as an encrypted overlay or private links. Confirm what your platform provides, and do not assume it is on.
Verify
From a machine outside the inference network, scan the node addresses and confirm the internal ports do not answer. Repeat after any change to networking or cluster setup.
Quick check
Does an API key protect multi-node traffic?
No. The key relates to the HTTP API. Inter-node traffic is a separate channel with no authorization in the distributed layer.
Is a firewall rule enough?
It is the main control, but add network segmentation and limited admin access, because anyone who reaches those ports can run code.
Where Safeguard fits
Safeguard does asset discovery and dependency scanning, which helps you list the inference hosts and the versions of the libraries running on them. A free scan shows what your repositories pull in.
Sources
- vLLM security documentation, read 19 October 2026. This is the developer preview version of the docs.
- PyTorch SECURITY.md, read 19 October 2026.
Last reviewed: 19 October 2026.
