Reproduced on the published 0.2.83 image, GPU-less, no Authorization header:

  GET  /v1/models            -> 200    <- open
  POST /v1/chat/completions  -> 503    (no model in the test, so inconclusive)
  GET  /v1/runpod/spend      -> 502

Nothing returned 401, because the front was never an enforcement point: it
answers some /v1 paths from its own registry and proxies the rest, so
whether a request needed a token depended on which component served it. On
a host published through a reverse proxy that is an open relay for the
model list, and potentially for generation.

The front now gates /v1 itself with the same credentials the engine
accepts: the env token a capability image is locked with, the shared
cluster token a head presents, an API token from auth.json, a logged-in
browser session, the in-process broker bridge, and the aisbf relay marker.
Constant-time comparison throughout.

One deliberate difference from the engine's middleware: it does NOT fall
open when no credentials are configured. That fallback is defensible on a
loopback workstation and is precisely what exposed this one, so the front
refuses instead. Readiness and progress endpoints stay exempt — a probe
that 401s is read as "backend down", and surya-ocr's vLLM client probes
{service_url}/health.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>