Auth Gates Must Guard the Work

Security checks are not enough if protected work can start before they run. Routes that call paid or sensitive external services need authorization before key reads, request processing, external calls, and mutations.

The surface problem

The simple version of the problem sounds familiar: add authentication to a couple of routes.

That description is technically true, but it is too shallow. It makes the work sound like a guard can be placed anywhere in the handler as long as the handler eventually rejects an unauthorized request.

That is not the real boundary.

The real problem

The real problem is whether an unauthenticated request can reach paid or sensitive work before the system proves the caller is allowed to invoke it.

For modern product teams, that work may include:

• reading a provider key or other sensitive configuration
• parsing user-provided content that should only be processed for an authenticated user
• fetching user-scoped records
• calling an AI or external API provider
• creating a mutation, job, message, or billing-relevant action

If any of that can happen before authorization succeeds, the route still has a boundary-ordering problem.

Why ordering matters

An auth check is only a boundary when it stands in front of the thing it protects.

A late check can make the response look right while the internal path remains wrong. The caller may still receive a 401, but the system may already have read sensitive configuration, processed private input, called a paid service, or taken another action that should have been unreachable.

This is especially easy to miss in AI-enabled routes because the external call is often hidden behind a helper, model SDK, parser, or generation function. The visible handler can look small while the actual cost and data boundary sits one call deeper.

The related-route trap

Security patch work also needs a same-vulnerability-class check.

When one route has the wrong ordering, nearby routes often carry the same assumption. The exact code may differ, but the failure mode is shared: auth failure gets treated as a recoverable local state, a preview exception is broader than expected, or an empty fallback lets execution continue toward the protected service.

The important question is not only, "Did we fix the named route?"

It is also, "Where else can an unauthenticated request reach the same kind of work?"

What good proof looks like

For this class of change, a passing happy-path test is not enough.

The useful proof has two parts:

1. unauthorized requests receive the expected rejection
2. unauthorized requests do not reach the downstream service, SDK, mutation, or other protected seam

That second assertion matters. It proves the old path is blocked before the expensive or sensitive operation begins.

A practical test shape is:

• send an unauthenticated request
• assert the response is a clear authorization failure
• assert the external service seam was not called
• assert no fallback swallowed the auth failure and continued
• keep preview or internal exceptions explicit and bounded

This turns the security requirement into observable behavior rather than a code-reading claim.

Operational security is a separate track

When the work involves an exposed or at-risk provider key, repository proof is not enough.

The code can prove the new ordering. It cannot prove that an old key was revoked, a production environment was updated, a preview environment was rotated, or provider usage was checked for misuse.

That evidence has to come from the operator or provider dashboard.

Treat that as a separate acceptance track, not as a footnote:

• new key generated
• relevant environments updated
• old key revoked or deleted
• usage and spend reviewed
• no secrets committed
• residual risk accepted by the right human owner

The pull request can be technically correct and still not be ready until the operational track is complete.

The reusable lesson

Auth gates must guard the work, not just the route.

For any route, action, job, or workflow that invokes paid or sensitive external work, define the protected seam and put authorization before it. Then prove the sequence with a negative test that checks both the rejection and the absence of downstream calls.

The boundary is not the line of code that says "auth."

The boundary is the point where the system cannot continue without permission.