DP
Devon Park
5 hours ago
Agent rewrote my auth middleware and I almost shipped it
War story from last night.
I pointed Cursor at a Next.js app and asked it to "clean up the auth layer." It confidently replaced my session checks with a shiny new middleware that looked fine in the diff. Tests still passed because they mocked the happy path.
Caught it when I tried logging in with an expired cookie — the new code treated missing claims as anonymous success and issued a fresh session. One more merge and that would have been in prod.
I still vibe-code most days. But I'm done accepting multi-file auth/payment diffs without a human walkthrough of every branch. Anyone else baking that into their workflow, or am I just scarred?
5 comments
Join the discussion
Log in to comment.
Not scarred — that's the correct default for auth/payments.
I've seen the same pattern: agent "simplifies" claim checks by collapsing null and valid into one path, and unit tests never hit the expired-cookie case because fixtures always inject a perfect JWT. Diff review alone is weak here; you need a couple of adversarial cases in CI (expired, missing claim, wrong audience) that hit the real middleware, not mocks.
Rule I use: any PR that touches session issuance gets a forced human walkthrough plus those three cases green. Vibe coding elsewhere is fine. Auth is not elsewhere.
Yeah, and this is why I still keep a local model in the loop for review, not for rewriting security code.
Cloud agents are great at generating plausible middleware. They're bad at remembering that "missing claim" is not the same as "anonymous visitor." I run the agent's patch through a second pass with a dumb checklist: where do we reject, what happens on null, what gets logged. If the agent can't explain those three in plain English, the patch doesn't land.
Also: if your tests mock auth so hard that expired cookies never reach the code, the tests are lying. That part is on us, not the model.
Same failure mode bit us on NestJS last month. Agent swapped a Redis session lookup for an in-memory Map "for speed" and the tests kept using a fresh Map each suite. Prod shared state across requests. We didn't catch it until a user got someone else's cart.
Now any PR that touches auth gets a required checklist in the template: expired token, missing claim, wrong audience. No checkbox, no merge. Sounds boring. Boring is the point.
honest question — do you keep a separate "security agent" with a locked system prompt for review only, or is it just you + a checklist?
i tried a second Cursor agent with "find auth regressions, do not rewrite" and it still suggested "simplifying" the null branch. ended up writing the three cases by hand in ~20 min. maybe the agent should only propose tests, not patches, for auth.
oof yeah. i let an agent touch Firebase Auth rules once and it opened read access "temporarily for debugging". caught it in the PR because the rules file was in the diff and i almost skimmed past it.
now i literally put AUTH in the PR title if anything auth-related changed so reviewers slow down. works better than i expected lol