No. According to vLLM's own security documentation, the API key setting protects endpoints under a few path prefixes, such as /v1. Other inference and operational endpoints on the same HTTP server do not check it. Treat the key as one layer, and put a reverse proxy with an endpoint allowlist in front.
What the docs say the key covers
The vLLM project documents this limit plainly. The API key option, set with a flag or the VLLM_API_KEY environment variable, enforces a bearer token for endpoints under /v1, /v2, /inference and /cohere. That includes chat completions, completions, embeddings, the models list and several others.
The same page then warns not to rely on the key alone. Many other endpoints share the server and do not enforce it. The project describes this in a section called API Key Authentication Limitations, in its developer preview docs. Check the page for the version you run, because endpoint lists change between releases.
Endpoints outside the key
The docs list three groups that need no token even when a key is set.
| Group | Examples named in the docs | Why it matters |
|---|---|---|
| Inference outside the prefixes | /invocations, /pooling, /classify, /score, /rerank | Same inference as the protected paths, no credential |
| Operational control | /pause, /abort_requests, /update_weights | Denial of service, or changing model behavior |
| Utility | /metrics, /tokenize, /health, /version, /load | Information about the model, queue and cache |
The docs call out /invocations as particularly concerning, because it gives unauthenticated access to the same inference capability as the protected paths. They also state that an attacker who can reach the HTTP server could pause generation or abort in-flight requests without a token.
How to close the gap
Follow the project's own advice, in this order.
- Do not expose the server port to untrusted networks. Bind it to a private interface and let only the proxy reach it.
- Put a reverse proxy in front, such as nginx, Envoy or a Kubernetes gateway, and allowlist exactly the paths your users need. Block everything else by default.
- Do authentication, rate limiting and logging at the proxy as well, so a new endpoint in a later release does not silently become public.
- Keep the API key on as a second layer for the paths it does cover.
- Never turn on development mode or profiler endpoints in production. The docs say so in capital letters.
A minimal allowlist idea, in nginx style, looks like this.
location = /v1/chat/completions { proxy_pass http://vllm_backend; }
location = /v1/models { proxy_pass http://vllm_backend; }
location / { return 404; }
The last line is the point. Deny first, then add what you can justify.
Test it from the outside
After you configure the proxy, call the public address with no token and try a few paths from the table above. You want a 401, 403 or 404 for each. Repeat this test after every upgrade of the inference server, since the endpoint list can grow. Also scan the host for open ports, because the internal ports for multi-node traffic are a separate exposure.
Where the server sits next to other services in a cluster, a network policy that allows only the proxy as a client is a good second fence.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an API scan reports endpoints that answer without credentials.
Quick check
Is setting the API key enough for a public vLLM server?
No. The project's own docs say not to rely on the key alone, because several inference and control endpoints sit outside the paths it protects.
Which endpoints should a proxy expose?
Only the ones your clients call, usually a small set under /v1. Everything else should return an error at the proxy.
Does this apply to other inference servers?
The habit does. Read each server's security page, list its endpoints, and test them without a token.
Where Safeguard fits
Safeguard can inventory the dependencies and assets in your AI stack and apply policies and gates in CI, so an inference server version with a known advisory is flagged before it ships. You can try a free scan to see what it finds in a repository.
Sources
- vLLM security documentation, read 19 October 2026. This is the developer preview version of the docs.
Last reviewed: 19 October 2026.
