Setting Up Authentication: Letting AI Build the Login While You Decide Who Gets to Do What

Your app needs users to log in. It’s holding real accounts now, real people with real stuff they expect only they can see, so at some point you have to put a door on the thing. Say you’re building a tool that lets small book clubs run private discussion boards for each group. So you ask your AI assistant to set up authentication, and it does, fast. A minute later there’s a sign-up form, a login page, passwords getting hashed and stored properly, sessions that keep people logged in, maybe a password reset email. You make an account, log in, log out, log back in. It works. You’ve got a door, it locks, and you feel like you handled the security part.

And “the security part” is where the quiet trouble is, because a login form is only half of what “authentication” was actually asking for. AI built you a way to prove who someone is. What it didn’t build, because you didn’t tell it to, is any real sense of what each of those someones is allowed to do once they’re inside. By default everyone who logs in gets treated more or less the same, which feels fine until a member of one book club can read another club’s private thread, or a regular member can delete the whole board, or a logged-in stranger can edit a post that isn’t theirs. Nothing crashed. The door locks beautifully. It just lets everyone who walks through it go anywhere, because you asked for a lock and got a lock, and never said who was supposed to be allowed where.

What this job actually is

Setting up authentication is two jobs that hide inside one word. The first is the mechanism of proving identity: the sign-up and login flow, hashing passwords so they’re never stored in plain text, managing sessions so people stay logged in safely, handling the password reset, maybe wiring up “sign in with Google” so people don’t have to make yet another password. This is well-trodden, security-sensitive, easy-to-get-subtly-wrong plumbing, and it’s exactly the kind of thing you should not hand-roll from scratch. AI is genuinely good at it, because it’s a solved problem with established patterns, and AI knows those patterns and the libraries that implement them safely. Handing AI the identity plumbing is smart; hand-building your own password hashing is how you end up with a breach.

The second job is deciding what each identity is allowed to do: who can see what, who can change what, who can delete what, and where the walls between users actually go. That’s authorization, and it’s the half people forget because logging in feels like the whole task. It’s a judgment call about the structure of your app: which users are peers, which have power over others, what data belongs to whom, and what would be a genuine disaster if the wrong person could reach it.

Here’s the distinction that matters: AI can generate the login mechanism, but deciding who’s allowed to do what is yours. A working login is not a security model. The value of authentication shows up the moment someone tries to reach something that isn’t theirs, and whether your app stops them depends entirely on rules you defined about who can do what, not on how cleanly the login page renders. AI can build a flawless sign-in and still leave every door inside the house wide open, because it doesn’t know which users should be walled off from each other or what’s catastrophic for the wrong person to touch, and it can’t know any of that unless you tell it.

How to delegate the mechanism

So lean on AI for the part it does well, which is the identity plumbing, and lean on it hard, because this is one of the places where rolling your own is actively dangerous. The move that makes this delegation good is being clear that you want the identity mechanism built on established, trusted tools, and that you’ll be supplying the permission rules separately rather than letting the login flow imply them.

Ask AI to set up the authentication flow using a well-established library or service rather than inventing anything, to hash passwords with a standard, current method, to manage sessions securely, and to handle the boring-but-critical pieces: password reset, protection against someone hammering the login with guesses, and not leaking whether an email is registered. Ask it to keep the identity layer cleanly separated from your permission rules, so that “who is this person” and “what is this person allowed to do” are two distinct things you can reason about on their own. That separation is what lets you hand AI the login while keeping the permission decisions in your hands.

What you don’t do is ask “set up authentication for my app” and treat the login form that comes back as the finished job. That open phrasing gets you identity and nothing else, because with no permission rules to work from, AI builds the part it can and quietly leaves everyone equally powerful. Keep the ask on mechanism, and keep it explicit about scope. Build me a secure login on trusted libraries, wire up reset and session handling, keep the identity layer separate from permissions, and stop there; I’ll bring the rules about who can do what. You’re asking AI to build the door and the lock. Deciding who gets which key is the part you keep.

The judgment you keep

Who’s allowed to do what is the call, and it’s yours because it turns on something AI can’t see: the actual structure of trust in your app, which users are walled off from each other, and what would be a disaster for the wrong person to reach.

This is hard because the permissive default feels harmless, especially early. When it’s just you and a few test accounts, everyone being able to do everything looks like nothing’s wrong, because you’d never do the malicious thing yourself. The judgment is in imagining the users you don’t control: the member of one group who gets curious about another group’s data, the ordinary user who stumbles onto an admin-only action, the person who realizes they can edit a URL and reach someone else’s records. You have to decide, deliberately, where the walls go and what each kind of user can and can’t touch. For the book club app, the load-bearing rule might be that a member of one club can never see or post in another club’s board, full stop, and that only the club’s organizer can remove members or delete threads. Those aren’t features AI would infer from “set up authentication”; they’re decisions about who your users are to each other.

AI can’t make this call because it doesn’t know your app’s trust structure or what’s sacred inside it. It can build the login and even add a generic “admin versus user” split if you ask, but it can’t feel that letting one club read another’s board is a betrayal while letting anyone edit their own profile is fine, because that weighing depends on what your users expect to be private and what they’re trusting you to wall off. Get this wrong and the failure is quiet and awful: nothing crashes, no error fires, and one day a user reaches something that was never meant for them, and you find out when they tell you, or worse, when they don’t. The permission rules are where authentication stops being a login page and becomes actual protection, and drawing them is the part only you can do because only you know who’s supposed to be kept apart from whom.

Before you ship this job

Here’s what good delegation looks like, and the line it can’t cross.

The sample prompt. Something real you might send:

I’m building ChapterHouse, an app where small book clubs run private discussion boards, one per club. My main user is someone like Delia, who organizes a twelve-person neighborhood club and needs her group’s board to be genuinely private to that group. Set up the authentication mechanism for me, and use well-established, trusted libraries rather than building any of the security-sensitive parts from scratch. Specifically: a secure sign-up and login flow, passwords hashed with a current standard method, secure session handling so people stay logged in safely, a password reset flow, protection against repeated failed login attempts, and don’t leak whether a given email is already registered. Keep the identity layer (who someone is) cleanly separated from permissions (what they’re allowed to do), because I’m going to define the permission rules myself. Don’t build out any who-can-do-what logic yet or assume everyone has the same access; just give me a solid, secure login and the clean separation, and I’ll bring the rules for who can reach what.

Use this and you get a secure, trustworthy front door. Copy it as-is and you’ve built ChapterHouse’s login while skipping the part that was yours: the walls between one club and another. Delia’s private board is only private because of permission rules that live in your head, not in the login form. Your app’s walls sit somewhere else entirely, and the door only protects anything once you’ve decided who’s allowed through which parts of it.

The part you can’t hand off is the permission model: who can see, change, and delete what, and where the walls between your users go, judged against which access in the wrong hands would be a genuine disaster for your specific app.

How to check AI did its part: don’t test the login by logging in successfully; test it by trying to reach something you shouldn’t. Make two accounts that should be walled off from each other (two members of different book clubs, say), log in as the first, and deliberately try to reach the second one’s private data: open their board, edit their post, delete their thread, poke at the URL to reach records that aren’t yours. The right result is that every one of those attempts gets refused. If you can reach another user’s stuff just by being logged in, then what you built is identity without protection, and the wall you were counting on isn’t there no matter how smooth the login felt. A door that lets everyone go everywhere once they’re inside isn’t secured; it’s just greeted.

What you get for doing it this way

Go back to that smooth login flow and the feeling of having handled security. The difference between building a login and building a security model is the difference between an app that knows who its users are and one that actually keeps them where they belong. When you let AI build the trusted identity plumbing and you decide the permission rules yourself, you get a front door built on solid, proven foundations and walls inside that actually hold, so a curious or careless user can’t wander into something that was never theirs to see.

AI can build you a secure, standards-based login faster and more safely than you could hand-roll one, and you should let it. Who’s allowed to do what once they’re through that door was always going to be your call, because only you know which of your users must be kept apart and what it would cost you if they weren’t. That’s the job: let AI build the lock, then decide for yourself who gets to go where.