Trusting User-Agent Is Not Cron Auth

At a glance, this looked like a solved problem. Our agent routes supported both manual triggers and Vercel Cron. The manual path used `Authorization: Bearer $AGENT_SECRET`. The cron path accepted requests that looked like they came from Vercel. That sounded reasonable. It was not.

The real problem was not that cron auth was different from bearer auth. We already knew that. The real problem was that some privileged routes were still treating a truthy `x-vercel-cron-auth-token` header, or even a `User-Agent` containing `vercel-cron`, as evidence of trust. That is not a security boundary. That is just a string match.

Why This Was More Serious Than the First Cron Bug

We had written earlier about the operational trap: Vercel Cron does not send bearer auth, so routes that only accept `Authorization` silently reject scheduled work. That is an execution problem. This bug lived one layer deeper. Here the route did execute. It just accepted the wrong proof of identity.

That distinction matters. A broken cron route creates absence. An overly trusting cron route creates exposure. In our case, the affected routes were not harmless health checks. They were privileged agent endpoints capable of triggering paid image generation, creating products, and querying prompt history.

The Security Smell Was Hiding in Plain Sight

The vulnerable pattern looked innocent because it grew out of operational debugging. We had learned that Vercel sends an `x-vercel-cron-auth-token` header. We had also seen cron-related user agents in traffic. Somewhere along the way, "recognize cron-shaped requests" drifted into "trust cron-shaped requests." That is exactly how these mistakes happen.

export function validateAgentRequestAuth(request) {
  const isVercelCron =
    request.headers.get('x-vercel-cron-auth-token') ||
    request.headers.get('user-agent')?.includes('vercel-cron')

  if (isVercelCron) {
    return null
  }

  const authHeader = request.headers.get('authorization')
  if (authHeader !== `Bearer ${process.env.AGENT_SECRET}`) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
  }

  return null
}

The bug is obvious once you slow down enough to name the real question: what exactly are we trusting here? Not a validated secret. Not a signed identity. Just request shape. That means any caller who can send headers can impersonate the cron path.

The Fix Was Small. The Discipline Around It Was Not.

The code change itself was straightforward. Stop trusting user-agent strings. Stop trusting the mere presence of a cron header. Only treat a request as cron when the token matches a secret you control.

export function validateAgentRequestAuth(request) {
  const cronSecret = process.env.CRON_SECRET
  const cronAuthToken = request.headers.get('x-vercel-cron-auth-token')
  const isVercelCron = Boolean(cronSecret) && cronAuthToken === cronSecret

  if (isVercelCron) {
    return null
  }

  const authHeader = request.headers.get('authorization')
  if (authHeader !== `Bearer ${process.env.AGENT_SECRET}`) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
  }

  return null
}

But this was not the kind of fix you just push and hope. Scheduled agents are a live production system. If you harden auth carelessly, you can lock your own cron jobs out and silently break operations. So the real work was not just the patch. It was the rollout.

What Production-Safe Remediation Actually Looks Like

1. 1Create a real cron secret. Not a placeholder, not an assumption, an actual high-entropy secret stored in Vercel.
2. 2Preserve the manual path. AGENT_SECRET still needs to work for explicit human-triggered runs.
3. 3Test negative cases first. No auth should fail. Spoofed User-Agent should fail. Wrong cron token should fail.
4. 4Use a low-risk route for smoke testing. We validated against the prompt-history endpoint instead of triggering paid image generation just to test auth.
5. 5Verify both positive paths. Valid bearer auth should succeed. Valid cron-secret auth should succeed.

That sounds procedural. It is. But that procedure is the point. The local bug exposed a larger systems issue: teams are often good at patching the vulnerability and weak at protecting the production behavior they are about to change.

The Production Test We Actually Cared About

The decisive question was not "does the helper function look better now?" It was "can we prove the trust boundary changed without accidentally firing expensive jobs?" That is why we used a shared auth-protected read route as the smoke test.

• No auth: 401
• Spoofed User-Agent: vercel-cron: 401
• Wrong cron token: 401
• Valid bearer auth: 200
• Valid cron token: 200

That matrix matters because it proves two things at once: the bypass is closed, and the legitimate production paths still work. Security fixes that only prove the first half are unfinished.

The Broader Pattern

This was not just a Vercel detail. It is a common failure mode in AI systems and operational tooling more broadly. A route starts life as a convenience endpoint. Then it grows teeth. It can trigger jobs, spend money, mutate data, or expose internal artifacts. But the auth assumptions stay stuck in the earlier phase, when the route was treated as low stakes.

That is why so many security problems do not look like classic "hacks" in the code. They look like drift. A debugging shortcut becomes a compatibility rule. A compatibility rule becomes an implicit trust model. And nobody notices until the endpoint is important enough that the mistake becomes expensive.

What I Would Generalize From This

• Name the trust boundary explicitly. Ask what exactly proves identity for this route.
• Do not let operational heuristics become security logic.
• Test negative paths as seriously as positive ones.
• Use the cheapest safe endpoint you can find for production auth smoke tests.
• Treat rollout and rollback as part of the fix.

The better question is not just whether your automation works. It is whether you are clear about what is allowed to invoke it, why, and how you would prove that in production without guessing. That is probably worth a broader advisory on AI-agent trust boundaries, because this pattern applies to far more than cron.