Before you expose a model server

Keep the default boundary private

Bind local experiments to loopback. If another person needs access, prefer an authenticated private network or an authenticated HTTPS gateway with explicit allowed routes.

The vLLM security guide warns that API-key coverage does not automatically protect every management or plugin route. A single API-key flag must not be treated as a firewall for the whole process.

• Expose only the inference routes you intend to support.
• Keep debug, metrics, distributed-worker, and administration interfaces private.
• Apply authentication, request-size limits, concurrency limits, and timeouts at the access boundary.
• Verify unauthorized requests are rejected from outside the machine, not just from localhost.

Treat model access and application access separately

A Hugging Face token lets a server download authorized artifacts. A serving API key controls who can ask that server to generate. They have different purposes and should not be reused.

Keep tokens out of browser bundles, shared URLs, screenshots, source control, and command examples. Scope permissions narrowly. Inspect logging so private prompts and authorization headers are not accidentally retained.

Model loading is a trust decision

Do not enable remote-code execution simply to dismiss a warning. Review the repository, pin a revision, and understand the code that will execute. Runtime caches and plugins should be writable only by trusted processes.

For multi-user deployments, review cache sharing and isolation as well as authentication. Patch the runtime, limit resource consumption, and retain a tested way to stop or roll back the service.