Beyond Mock Data: Building Authentication, Databases and Permissions with AI

A prototype can show a private workspace without protecting anything. Once real accounts and records are involved, the product must enforce who can see and change each piece of data. AI can draft schemas, permission matrices and test cases, but a generated login form is not a security boundary.

Designers and developers need a shared model of access before they connect the interface to real data. This is part of the experience: permission failures, expired sessions and revoked access all change what people can do and what the product should explain.

Distinguish identity from authority

Authentication establishes who is making a request. Authorization decides what that identity may do. A signed-in person is not automatically entitled to every record, and hiding a button does not prevent a direct request to the server.

Consider an illustrative shared workspace. An owner can manage members. A member can edit documents. A viewer can read documents but cannot change them. The model also needs to account for a person who has been removed, someone with an expired session and a visitor who was never invited.

Ask AI to turn these rules into an access matrix. Rows represent actions; columns represent identities or roles. Review the matrix with both disciplines. The designer checks whether the states and explanations make sense. The developer checks whether each decision can be enforced at the trusted application or data layer.

Model the data around the rules

A workspace ID on a record is not sufficient protection by itself. The system must verify membership and the required role when a request reaches protected data. Do not rely on an ID being difficult to guess or on the client supplying the correct owner.

Supabase's Row Level Security documentation explains how database grants and row policies work together. Grants govern whether a role can perform an operation; policies constrain the rows it can affect. The documentation also warns that privileged server credentials can bypass row-level security and must not be exposed to clients.

The general lesson applies beyond one platform: enforce authorization where the caller cannot rewrite it. Treat generated policy code as security-sensitive work requiring knowledgeable review, not as a configuration detail to approve by appearance.

Test denied actions as deliberately as allowed ones

For the workspace example, verify that a member can update an authorized document. Then verify that a viewer cannot, a stranger cannot and a removed member cannot. Attempt to target a record belonging to another workspace directly rather than only navigating through the interface.

Check that denied writes leave the original record unchanged. An empty response alone may not prove the expected protection. Similarly, test reads for unintended data exposure rather than accepting that the page displayed a friendly error.

Ask AI for missing permission cases, but compare its suggestions with the access matrix. Do not weaken a policy just because a generated test fails. The test or fixture may be wrong, and the intended rule should remain the reference point.

Design honest recovery states

Permission errors need product decisions. When access is revoked while a person is editing, should the draft remain locally available? Can the person request access? Would explaining that a record exists disclose information they should not know?

Design and engineering should agree on these trade-offs before writing error copy. Preserve work only where storage and privacy constraints allow it. Distinguish signing in again from requesting a higher permission; sending someone through another login cannot fix an authorization denial.

AI can propose wording and state variations. It should not decide the organization's access policy or invent a recovery action that the system cannot support.

Checklist before connecting real accounts

• Define actions and roles in a reviewed access matrix.
• Separate authentication from authorization.
• Enforce access outside client-controlled UI logic.
• Keep privileged credentials out of browsers and prompts.
• Test cross-account reads and writes, including revocation.
• Verify denied operations leave data intact.
• Design recovery without leaking protected information.

Moving beyond mock data means accepting responsibility for real boundaries. Designers help make those boundaries understandable. Developers make them enforceable. AI can assist both, but neither a convincing interface nor a passing happy-path demo proves that the product is safe.