AI-Built MVPs: Review Login Before Launch
Review authentication in an AI-built MVP. Check token handling, server authorization, environments, recovery, and account removal before launch.
Retrospective series date: 2026-10-05. This label describes the series order, not a historical publication.
AI coding agents can create a login screen before the team has defined access policy. Review the full account journey before real customers use it.
This checklist applies to generated code and human-written code. The examples show review patterns, not a complete authentication implementation.
Trace one request from browser to data
Identify the session or token. Find the server check that validates it. Then find the check that permits access to the requested record.
Do not accept a protected route because its button is hidden. Call the endpoint directly without a valid session.
Use the JWT validation guide when tokens carry the authenticated context.
Check the object-level decision
A common defect checks that a user exists but not whether they own the record.
The following pure function illustrates a restrictive ownership rule. A real application must validate its inputs and obtain the actor from a trusted server context.
type Actor = { userId: string; organizationId: string };
type RecordOwner = { userId: string; organizationId: string };
export function canReadOwnRecord(
actor: Actor | null,
record: RecordOwner,
): boolean {
return actor !== null
&& actor.userId === record.userId
&& actor.organizationId === record.organizationId;
}Review three cases: the owner in the same organization, another user, and the same user in another organization. Only the first should pass.
This example is not a general role model. Collaboration products may allow other access through explicit membership and policy.
Inspect token handling
Search the generated application for tokens in URLs, logs, analytics, and browser storage.
Check that the server validates the token's issuer, audience, signature, and expiry. Do not trust decoded claims before verification.
An ID token describes an authentication result. It is not interchangeable with an API access token. Read the token comparison.
Review secrets and environments
A public client cannot keep an embedded secret. Check browser bundles, public environment variables, and repository history.
Separate test and production credentials. Check redirect URLs and issuer configuration for each environment.
If a secret was exposed, remove it and rotate it through the provider's procedure. Deleting the visible line does not invalidate the old value.
Test the failed journeys
| Case | Expected result |
|---|---|
| No session | Protected request is denied |
| Expired token | Request is denied or follows the documented renewal flow |
| Wrong organization | Private record is denied |
| Revoked membership | Intended access stops |
| Reused recovery link | Link cannot recover the account again |
| Unapproved redirect | Authorization request is rejected |
Record the observed response and side effects. A denied response should not leave the requested write completed.
Review account linking
Do not merge accounts because two untrusted inputs contain the same email string. Confirm the provider's verification and linking requirements.
Ask the agent to show the linking policy and tests. A generated explanation is not evidence that the code implements it.
Make review part of the release task
Ask the coding agent for the files responsible for session validation, authorization, recovery, and revocation. Inspect those files yourself.
Keep the findings in a release record. Assign owners and retest fixes. Use the startup technology worksheet for the wider launch.
Contact the NamoID team
NamoID can help you review the customer-authentication boundary and choose an integration approach.
Contact our team in Slack. Share your framework and a sanitized description of the flow. We can help identify the next review step.
Do not paste production tokens, passwords, or private keys into a community message.