Directing & Auditing an Agent That Builds Auth
Directing and auditing an agent that builds auth is the practice of giving a coding agent an explicit security specification for identity, sessions, permissions, and recovery, then reviewing the generated system for failures that would let users impersonate, persist incorrectly, expose secrets, or access data they do not own.
Authentication work is easy to under-specify because the visible feature is usually just registration, login, and logout. The real system is a security boundary around account creation, identity proof, session storage, route access, password or magic-link recovery, revocation, and user-owned data. A coding agent will often optimise for a working demo unless the prompt states which behaviours are forbidden, such as plaintext passwords, local-storage admin flags, or checks that exist only in the browser.
A good direction prompt describes the product rules, data model, trusted components, protected routes, session mechanism, roles, and database access rules. It should ask the agent to implement and demonstrate the path through registration, login, logout, recovery, route protection, role checks, and error handling. The audit then traces where identity is established, where authorisation is enforced, how sessions are created and invalidated, and what stops one authenticated user from reading or changing another user’s records.
The trade-off is that this slows down apparent progress. You are not merely accepting generated code because the happy path runs in the UI; you are forcing the agent to expose assumptions and produce verifiable controls. It also requires judgement, because the right mechanism depends on the stack, hosting model, identity provider, database, and threat model. The common misunderstanding is that hiding buttons or routes is security. It is not, unless the server or database rejects forbidden operations too.
Engineers meet this when using coding agents to scaffold user systems in frameworks with managed auth, API routes, server actions, row-level database policies, or custom session code. The review usually happens in pull requests, local threat-modelling notes, acceptance tests, and manual endpoint checks. The useful questions are concrete: can I call this endpoint without the UI, can I swap another user’s identifier, where are secrets stored, and can stale or stolen sessions still work?
Common questions
- What should I put in the prompt before asking an agent to build auth?
- Name the user flows, protected resources, session approach, roles, data ownership rules, and unacceptable shortcuts. Include acceptance checks for registration, login, logout, recovery, route protection, role enforcement, session expiry or revocation, and secrets handling. Ask the agent to explain which layer enforces each rule, not just to generate screens.
- How do I audit whether the generated auth is actually safe?
- Act like a hostile client. Ignore the UI and inspect the server routes, database rules, middleware, token handling, and session storage. Try unauthenticated requests, changed user identifiers, downgraded roles, replayed tokens, and direct database-facing operations. The key test is whether forbidden actions fail outside the browser as well as inside it.
- Is client-side route protection enough?
- No. Client-side checks improve navigation and user experience, but attackers can bypass them by calling endpoints directly or modifying requests. Authorisation must be enforced in a trusted place, usually server code, database policies, or an identity-aware backend service. The client may reflect permissions, but it should not be the source of truth.