Your AI-built app passes login. Can it keep accounts apart?

You can create an account, sign in, and open your dashboard. That is a convincing demo. It leaves another question unanswered: what happens when a signed-in user asks for somebody else's record?

A prototype built with AI tools needs this check just as any other app does. In Auth0's terminology, authentication establishes who the user is; authorization determines what they may access. A successful login proves only the first part.

A two-account test

Use a test environment you control and create two ordinary accounts, A and B, with no sharing relationship. Give each a private record containing a different, recognizable piece of test data. The example below describes expected behavior, not results from a client system.

Ask the developer to repeat the second request directly against the application's server, outside the dashboard navigation. They should test the same permission boundary when a record is edited, exported, or deleted. An interface can hide an action while the server still accepts it.

OWASP documents this failure as broken object-level authorization. The record identifier might appear in a URL or in a request body. Making it difficult to guess does not replace checking whether this user may perform this action on this record.

What a useful repair should demonstrate

The access decision belongs in trusted server-side enforcement. Depending on the application, it may consider record ownership, organization membership, a role, or an explicit sharing rule. Comparing two user identifiers is not a complete permission model for every product.

OWASP recommends denying access by default and validating permissions on every request. Make the two-account scenario an automated test that runs when the application changes, so a later feature cannot quietly reopen the same path. Keep the permitted request in the test too; blocking all requests would hide the defect by breaking the product.

Passing this check does not make the app ready for every production workload. It establishes one necessary boundary. If it fails, fix that boundary before introducing real private data. The finding should guide a review of the affected data paths; it does not, by itself, tell you whether the rest of the prototype needs replacing.