When AI-added auth middleware locks out public pages

You ask an AI to "add auth protection" or "secure every route." It does. Then a new visitor hits sign-up, login, pricing, or checkout — and gets bounced to login, stuck on a spinner, or hit with a 401. The pages still render in previews, so nothing looks broken from your side.

What happens

Middleware and route guards usually run before the page. An AI edit often widens them too far:

• It wraps the whole app (or every /api/* route) in a session check meant only for the dashboard.
• Sign-up and login now require a session that does not exist yet, so the flow never starts.
• Pricing and checkout need to stay public; locking them kills conversion.
• Payment and webhook API routes must accept provider callbacks without a user cookie. Guarding them drops real payments and renewals.

The UI still loads, so you may not notice until someone tells you they cannot finish.

A quick check after any AI edit near auth

1. Open /signup, /login, /pricing, and /checkout in a private window (no cookies). Each should load and submit without a prior session.
2. Confirm webhook and payment callback URLs return success without a browser session (use the provider's test tools or a simple POST).
3. Read the middleware matcher or guard list. Public paths and webhook routes should be explicitly excluded.
4. If something fails, paste the middleware file into your AI tool and ask: "Keep session required only for authenticated app routes. Leave sign-up, login, pricing, checkout, and payment/webhook APIs public. Don't change anything else."

Catch it without remembering to

You will not retest every public flow after every auth tweak. FlowPatrol runs sign-up, login, and checkout against your live app on a schedule and emails you as soon as one breaks, with a ready-to-paste fix prompt. Run a free scan on the homepage at flowpatrol.app.