AI can write your login. Should it own your auth?
AI assistants are great at generating a working login endpoint. The risk isn't the code they write, it's everything nobody prompts for. Here is where that gap is, what the research says, and where AI fits best.
Open your editor, type “add user registration and login to this API”, and wait.
A few minutes later you have a users table, a password hash, a /login endpoint that returns a token, and middleware that checks it. The tests pass and the demo works. That’s real progress, and we use AI assistants this way every day.
This post isn’t about whether to use AI for code. It’s about one specific area, authentication, where “it works” and “it’s done” are unusually far apart, and about how to get the speed of AI without inheriting that gap.
The part you prompt for, and the part you don’t
A generated login flow handles the path you described: a user exists, types the right password, gets a token. That’s the path you’ll test and demo.
Production auth is mostly the paths nobody describes:
- Wrong passwords, at scale. Lockout, backoff that grows with each failure, per-client rate limits. Without them, a login endpoint is an open invitation to guess passwords.
- Account enumeration. “User not found” and “wrong password” need to look identical to the caller.
- Revocation. When a user changes their password because they suspect a compromise, every older session should stop working. With stateless tokens that needs a deliberate design.
- Refresh tokens. Rotated on every use and revocable one by one.
- MFA. TOTP enrolment, single-use recovery codes, and a recovery path that doesn’t become the easiest way in.
- Password reset. Short-lived, single-use, and not a way to check which emails are registered.
- Hashing that ages well. Parameters change over the years, and you can’t ask every user to reset.
- Erasure and audit. Delete a user for GDPR while keeping an audit trail that still makes sense.
An assistant can help with every item on that list, if you ask. The catch is that you need to know the list to ask for it.
What the research says
Two findings are worth knowing before you hand auth to a prompt.
Models are fluent, not cautious by default. Veracode’s 2026 GenAI Code Security Report tested more than 100 models on coding tasks with known security pitfalls. Syntax was close to perfect, but on average only about 56% of the generated code passed the security checks, barely changed from the year before. Coding-specialised models did no better than general ones. Importantly, the prompts contained no security guidance, which is exactly how most of us ask for code. (SD Times, summary)
Confidence goes up faster than security. A Stanford user study (Perry, Srivastava, Kumar and Boneh) gave developers security-related tasks with and without an AI assistant. The group with the assistant wrote less secure code on average, and was more likely to believe their code was secure. The encouraging part: participants who trusted the AI less and put more effort into their prompts produced fewer vulnerabilities. (paper)
Neither finding says “don’t use AI”. Both say that the default interaction, a short prompt and a passing test, isn’t enough for security-sensitive code.
Why auth makes this gap expensive
Most bugs announce themselves. A broken checkout throws an error and a user reports it.
Auth gaps are quiet. Missing lockout doesn’t throw. An enumeration leak doesn’t throw. A token that survives a password change doesn’t throw. Everything keeps working for your users, and for anyone trying to get into their accounts. The people most likely to find these gaps aren’t the ones who open tickets.
And even when the code is solid, someone has to own it: the next dependency CVE, the security questionnaire from an enterprise customer, the erasure request, the hashing upgrade in three years. Then the same again for the next service, because the internal tool and the partner API got their own quick login too. That’s how a company ends up with five users tables written five different ways (we wrote about that in Your API shouldn’t own its users).
AI made each new copy faster to start. It didn’t make any of them cheaper to keep correct.
Where AI fits best
None of this means keeping AI away from auth. It means pointing it at the right layer:
- Prototypes, demos and learning. A generated login is a great way to understand the moving parts or to unblock a demo that will never store a real password.
- Integration code. Calling an auth service, handling its responses, wiring tokens into middleware. Well-defined contracts are where assistants shine.
- Reviewing with a checklist. If you do build auth yourself, give the assistant the list above and ask it to check each item explicitly. The Stanford results suggest that kind of deliberate prompting makes a real difference.
What it’s less suited to is being the only author and reviewer of the credential store for real users.
One service, built once
That’s the idea behind P’adentro: a self-hosted auth backend that your APIs call over plain HTTP with a tenant API key. Lockout, rate limiting, enumeration-safe login, PASETO access tokens, rotating refresh tokens, TOTP with recovery codes, Argon2id with migration from existing hashes, and erasure that keeps the audit log intact, built and reviewed once and shared by every service you run. It sits on your infrastructure, next to your Postgres and Redis.
Your assistant can write the integration in a few minutes. That’s a great use of it.
Get early access
P’adentro is in private beta, and we onboard each team by hand. If you’re about to add login to another service, we’d like to hear from you.
Ready to stop building auth yourself?