vLLM Authentication Needs an Endpoint Exposure Record

Configured bearer authentication applies to selected path prefixes. The same HTTP server can expose inference and operational endpoints outside those prefixes. I want to make that route boundary visible because a valid credential answers a narrower question than a production security review usually asks.

TL;DR

• vLLM's bearer credential protects selected /v1, /v2, /inference, and /cohere routes. Other routes on the same server are outside that check.
• Put vLLM behind a reverse proxy that exposes an explicit route allowlist and blocks every other inference endpoint and every utility or operational endpoint.
• Treat the shared vLLM credential as server authentication, then make natural-person identity and per-route authorization separate acceptance tests, with independent evidence.
• Host isolation and model trust are deployment controls outside request policy. Runtime hardening and direct-route prevention are too.

vLLM serves more than the OpenAI-compatible paths

The current vLLM online serving documentation lists OpenAI-compatible completions and chat, responses and embeddings, plus audio and model-discovery routes. That process can also expose Anthropic and Cohere interfaces; custom scoring and pooling routes; Prometheus metrics and health checks; SageMaker-compatible endpoints and tokenizer functions; plus optional development controls. An older openai_compatible_server documentation route now points to this broader online-serving page.

That breadth changes the authentication review. A test against /v1/chat/completions proves the behavior of one protected route. It says nothing about /invocations, /pooling, /metrics, or an enabled operational endpoint. A screenshot of one 401 Unauthorized response is therefore a weak production artifact.

I would reject a launch review that labels the whole server "authenticated" after testing only /v1/chat/completions. Put the observed route inventory on one sheet, including optional routes enabled by flags or environment variables. The crossed-out rows matter as much as the green ones.

The built-in credential has a path-prefix boundary

The current `vllm serve` CLI reference says --api-key requires one of the configured credentials in the request header. Its warning is precise: the check covers endpoints under /v1, /v2, /inference, and /cohere. Other endpoints on the same server are unauthenticated, including /invocations, which exposes the same inference capabilities as /v1.

The vLLM security guide expands that route list. It identifies unprotected inference routes such as /generative_scoring, /pooling, /classify, /score, and /rerank. Utility routes include /tokenize, /detokenize, /metrics, /health, and /version. Several operational controls also are outside the bearer check when their associated features are enabled.

The built-in credential protects only the documented prefixes. Production acceptance must test the negative space around those prefixes and confirm that an alternate route cannot reach inference or change server state.

An endpoint exposure record makes the perimeter testable

Build one endpoint exposure record per deployed vLLM service and environment. Generate the route inventory from the running application after startup, then compare it with the routes exposed by the ingress or reverse proxy. Record these fields:

• Route and method: Preserve the exact path and HTTP method. Record the vLLM feature or flag that registered it.
• Function: Label inference and model management; utility and health; metrics and development; profiling or operational control.
• Built-in credential status: Mark the path's --api-key coverage and retain an accepted or denied test result.
• External policy: Name the reverse-proxy allowlist rule and caller class. Record the rate limit and route-specific authorization decision.
• Network reachability: List the permitted source network and service. Include the blocked direct vLLM address and port.
• Evidence: Preserve the test request ID and configuration revision. Add the timestamp and expected status, then the observed status and evidence-store reference.

The vLLM security guide recommends a reverse proxy such as nginx, Envoy, or a Kubernetes Gateway. Its job here is explicit route allowlisting and rejection of every other endpoint. It also provides additional authentication and rate limiting, with request logging. Default exposure has no place in the record. Every reachable row needs a named reason.

Retest after any vLLM upgrade or feature change. A newly registered route can alter the perimeter without changing the model name or the client code.

Bearer authentication and caller identity are different records

A shared vLLM credential proves that the caller possesses a configured bearer secret. It does not identify the employee who initiated a request. It also cannot distinguish two agents using the same deployment credential or establish a task delegation. Those identities must arrive from an upstream application or identity-aware proxy.

The credential sprawl guide covers ownership, storage, rotation, and revocation for the secret itself. Keep that inventory beside the endpoint record, but do not use it as a substitute for request identity. A credential named production-chat still compresses every caller behind that integration into one credential.

For each allowed route, define the accepted principal type and the trusted issuer of that identity. Record the workload identifier. Record the identifier for a user or agent. Add tenant and role context where policy needs them. Preserve the authentication time and a request correlation identifier. Reject user-supplied identity headers at the public edge. Construct or validate identity context after authentication at a trusted boundary.

Natural-person identity needs an explicit delegation when a service or agent acts for a user. The post-authentication gap guide explains why session login alone cannot prove who authorized a later model call.

Per-route authorization needs its own decision

Authentication says the caller presented an accepted credential. Authorization grants a principal access to an operation on a route for a model under the current policy. vLLM's path-prefix credential check does not express those business decisions.

Create separate tests for chat completion and embeddings, reranking and audio transcription, plus model-management operations that the deployment exposes. Give each route an allowed principal set and model set. Add request limits and data-class rules where required. Preserve the policy version and reason code with each decision.

The per-role AI policy guide provides the identity-to-policy pattern. Apply it before a permitted request reaches vLLM. A valid deployment credential can then coexist with a denied route decision, which is the expected result when an authenticated workload asks for a model or operation outside its authority.

Test at least one accepted request and one denied request for every exposed route class. Then attempt the same inference through /invocations and each applicable non-prefixed alternative. The reverse proxy should block those paths before vLLM processes the payload.

Independent evidence cannot come from the credential alone

An access log can show that the server received a request. A credential check can show that one configured bearer value was accepted. An independent decision record needs more: verified principal and route; requested model and data class; policy version and result; reason code and destination; timestamp and correlation ID.

Keep that record outside the vLLM process and outside the calling application. This avoids asking either component to attest to its own behavior. Join the record to vLLM telemetry with a correlation identifier. The CLI supports response X-Request-Id headers when --enable-request-id-headers is set, which gives the two evidence stores a practical join field.

The LLM inference gateway guide describes this decision-and-evidence boundary. vLLM telemetry still owns token generation and latency, plus queue and GPU behavior. The independent request record owns who was allowed to send which routed model call under which policy.

Deployment controls are separate

The vLLM security guide says inter-node communications are insecure by default and are confined to an isolated network. It recommends firewall rules that expose only the API server port and keep PyTorch distributed and KV-cache transfer ports away from untrusted networks. Those controls protect the serving perimeter below the authenticated HTTP route.

Model provenance and trust are separate as well. The official vLLM GitHub security policy directs deployers to the security guide and PyTorch's security guidance for the threat model. Platform and infrastructure owners manage container hardening and package patching; GPU isolation and file permissions; model loading and plugins; media-fetch controls and runtime process privileges.

Direct-route prevention is also an infrastructure control. If a workload can reach the vLLM service address while bypassing the approved proxy, the endpoint record should fail. Network policy must close that path. DeepInspect records no decision for traffic it never receives.

DeepInspect

DeepInspect applies only when an authenticated HTTP model call is deliberately routed through its proxy. At that boundary, it can evaluate application-supplied identity and role context; the requested vLLM route and model; data classification and the current policy. It can then allow or deny the request and preserve a per-decision record independent of the calling application and vLLM process.

Existing teams own vLLM bearer configuration and reverse-proxy route exposure; host firewalls and inter-node isolation; model trust and plugins; container hardening and direct-path blocking. DeepInspect sees none of the calls that bypass its route. Book a technical deep dive at deepinspect.ai.