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, vercelOidc(), localDev()]. Walk through what each does to a public production request from a stranger's browser:
appAuthcallsgetCustomerand finds no valid session → returnsnull, falls through.vercelOidc()wants a valid Vercel OIDC token the stranger doesn't have → falls through.localDev()only grants its synthetic principal inside aneve devorvercel devprocess. Production isn't a dev process → 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.
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 credsAnything 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 production policy before you deploy: appAuth is first, authenticated Vercel identity comes next, and the process-only development fallback is last. Do not try to prove this by changing the Host header under eve dev: that process deliberately enables localDev(), regardless of hostname. You'll exercise the real 401 and authenticated 202 against the deployment in 5.2.
Now sweep for secrets you don't want in git:
git grep -nEi '(sk-[a-z0-9]{16,}|(api[_-]?key|secret)[[:space:]]*=[[:space:]]*[^[:space:]]{8,})' \
-- . ':!package-lock.json' || echo "clean"If the sweep finds a real value, remove it from source, rotate it, and put the replacement in Vercel environment variables. If you can't reach a model after linking, run eve link again and confirm the project has AI Gateway access.
Done-When
- You can explain why an unknown production caller falls through every authenticator to
401. - The auth order is
[appAuth, vercelOidc(), localDev()]. - The model credential comes from a linked Vercel project / env, not source.
git grepfor 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:
export default eveChannel({
auth: [appAuth, vercelOidc(), localDev()],
});appAuth admits customers. vercelOidc() covers authenticated Vercel traffic, and localDev() only activates in the dev process. Everything else receives the fail-closed 401. With credentials in the environment, the dispatcher is ready to deploy.
Was this helpful?