Lock the Doors

The dispatcher is about to move from your laptop to the public internet. Before deploying, we'll confirm that only recognized callers can reach it.

The auth walk from 4.3 already decides who gets in. This lesson checks what happens to unrecognized callers and confirms that credentials stay out of source code.

Outcome

You can state exactly what an unauthenticated request to the deployed dispatcher gets, and your model credential and any secrets live in environment variables, not in the repo.

Hands-on exercise

Understand fail-closed. Your auth list is [appAuth, localDev(), vercelOidc()]. Walk through what each does to a public production request from a stranger's browser:

appAuth calls getCustomer and finds no valid session → returns null, falls through.
localDev() only accepts requests to a loopback hostname (localhost, 127.0.0.1). A public request isn't loopback → falls through.
vercelOidc() wants a valid Vercel OIDC token the stranger doesn't have → falls through.

Every entry falls through, so eve returns a 401. Routes reject any request that no authenticator explicitly accepts. Unrecognized traffic is denied by default.

Why localDev() is safe to leave in production

localDev() keys off the request's hostname rather than an environment flag, and a public request never arrives on a loopback host. It keeps local development and the same-origin dashboard working without admitting an outside caller. One caveat from the docs: put a normalizing proxy in front of your origin so a forged Host header can't spoof loopback.

The scaffold ships placeholderAuth() for this reason

A fresh eve project starts with placeholderAuth() in the walk. In production, it returns a clear "auth isn't configured yet" 401 so a half-built app fails closed. You replaced it with real auth in 4.3.

Keep secrets in env. The dispatcher needs exactly one credential to run: a model key. The easy, secret-free path is the Vercel AI Gateway, link a Vercel project and a gateway id like anthropic/claude-opus-4.8 authenticates through OIDC, with no provider key to store anywhere:

npx eve link   # links this directory to a Vercel project and pulls Gateway creds

Anything sensitive your real getCustomer would use (a session-signing secret, a JWT key) belongs in Vercel's environment variables, never in source. Route-auth secrets are re-materialized from env at boot and never baked into the build artifacts.

Try It

Confirm the lock from the outside. With the agent running, send a request that looks like an unauthenticated outsider, no session cookie, no OIDC token, addressed as if from off-box:

curl -i -X POST http://127.0.0.1:2000/eve/v1/session \
  -H 'content-type: application/json' \
  -H 'host: dispatcher.example.com' \
  -d '{"message":"hello"}'

HTTP/1.1 401 Unauthorized
{ "ok": false, "code": "unauthorized" }

Now confirm a real customer still gets in, the demo-pro session from 4.3 works:

curl -i -X POST http://127.0.0.1:2000/eve/v1/session \
  -H 'content-type: application/json' -H 'cookie: shop_session=demo-pro' \
  -d '{"message":"hello"}'

HTTP/1.1 200 OK
{ "sessionId": "...", "continuationToken": "..." }

The stranger receives a 401, while the customer gets in. Finally, sweep for secrets you don't want in git:

git grep -nE "sk-|api[_-]?key|secret" -- . ':!*.lock' || echo "clean"

Production-safe is mostly verifying, not adding

Notice you barely wrote code here. eve's defaults, fail-closed routes, secrets re-materialized from env, OIDC model auth, do the heavy lifting. "Hardening for production" is largely confirming the framework's safe defaults are still in force and that you didn't paste a key somewhere.

If the demo-pro request also gets a 401, your appAuth isn't first in the walk, or getCustomer isn't reading the cookie. If you can't reach a model after linking, run eve link again and confirm the project has AI Gateway access.

Done-When

An unauthenticated, non-loopback request returns 401.
A valid customer session still returns 200 with a session.
The model credential comes from a linked Vercel project / env, not source.
git grep for secrets comes back clean.

Solution

There's no new file here. The solution is the auth walk you wrote in 4.3, now verified as the production lock:

agent/channels/eve.ts (unchanged from 4.3)

export default eveChannel({
  auth: [appAuth, localDev(), vercelOidc()],
});

appAuth admits customers. localDev() and vercelOidc() cover loopback and internal Vercel traffic. Everything else receives the fail-closed 401. With credentials in the environment, the dispatcher is ready to deploy.