A working app demonstration can leave basic questions about customer access unanswered. Before you invite people to rely on an AI-built app, check who can see private information and who can change it, because the visible screens give you only part of that answer.
AI helping to write the code does not make the app unsafe on its own. We would still check the behavior directly, since a convincing explanation from the same tool tells you what the tool believes about the code, and GitHub’s responsible-use guidance for Copilot agents calls for human review and testing of generated work.
The following exercises are for an app you own or are authorized to test. Use a separate environment and accounts that hold test information. An owner can define the expected rules and inspect the results, while an engineer should handle the request-level checks and repairs.
Write the customer boundary in a small table
Start with a feature that handles private information, such as a customer document or a saved quote. Decide who may view it and who may change it.
Signing in establishes who a person is. The app also needs to decide what that person is allowed to do, which engineers call authorization, and a login screen can work perfectly while that second decision is missing from one particular request.
Fill in the rules before testing:
| Person using the app | Read the test document | Change it | Remove it |
|---|---|---|---|
| The customer who owns it | Yes | According to the product rules | According to the product rules |
| A different customer | No | No | No |
| An authorized staff member | Defined by staff role | Defined by staff role | Defined by staff role |
| A signed-out visitor | No | No | No |
If customers can share a document on purpose, add that case to the table. Test each role with its own account, because a convenient administrator account used for demonstrations can hide problems that ordinary customers would run into.
The OWASP authorization guide recommends checking permissions on every request and denying access by default where permission has not been granted. Your table turns that principle into the rules of your own product.
Test beyond the buttons on the page
Create two customer test accounts with clearly different records. Have the engineer confirm that each can use its own records and that each one is blocked from the other’s private material.
The check should include the server requests behind the interface. Hiding a delete button from a customer is useful interface behavior, and the server must also reject a deletion that customer is not allowed to perform.
Repeat the relevant checks while signed out and with the staff roles you use. If the app has exports or file downloads, include those paths too, since a protected page with an open download still exposes the same information.
For an app using Supabase, its Row Level Security documentation explains database rules that restrict which records a request can access. An enabled rule gives the engineer something to test, and the test still has to cover the combinations your product allows and rejects.
Keep the result specific. “Customer B could read Customer A’s test document through the download request” is a finding someone can reproduce, while “Security seems weak” gives the team nothing to fix or verify.
Distinguish a public identifier from a private credential
A browser receives code and information that a visitor can inspect. The engineer should review the built website for credentials that grant private access, including settings that slipped in during the build.
A value called a key can be public by design. Supabase’s API key documentation distinguishes publishable keys from privileged secret keys, and public keys depend on appropriate access rules, while a privileged key must never be delivered to visitors.
Ask for a credential inventory listing the provider, the job each credential performs and where it is stored. Keep the credential value itself out of the document, and record who can revoke it and which environment it belongs to.
If a private credential was exposed, deleting it from the latest source file leaves the job half done. The operator needs to revoke or rotate it at the provider and check where it was used, because the old value may remain in an earlier build or in the repository history.
Also check what access the coding tool has. A preview exercise should never need permission to delete a live database or deploy straight to production, so give the tool access that fits the task and check the target before running a change.
Try the same important action twice
Customers can press a button again when a page feels slow, and external services can retry their messages. The app needs a defined result when a request to create something arrives more than once.
Choose one important action in the test environment, such as creating a reservation or submitting an order. Ask the engineer to repeat the same logical request and show the resulting records.
Write the expected outcome first. A repeated reservation request should produce one appointment even when the first response was delayed. Some actions are meant to create a new record each time, so the rule must follow what the customer intended.
Then interrupt or delay a connected service in a controlled test. Check whether the app tells the user that work is pending, failed or complete. A cheerful success message for a request that was discarded can confuse people more than a clear failure with a next step.
For payment-related behavior, use the payment provider’s test environment and have the engineer check the provider’s confirmed result. A customer landing on a success page should never be the only evidence the app uses to grant a paid entitlement.
Review what an AI feature is allowed to decide
If the app itself uses AI, keep generated text apart from actions that affect an account. A model can help interpret a request, and the application still needs to enforce who may perform the proposed action and which values are allowed.
For example, an assistant helping with a booking should use the available slots and the business’s rules. A sentence saying a time is open gives no permission to reserve a slot the scheduling system has rejected.
Create a short set of test requests that includes an ordinary request and one the app must decline or hand to a person, and keep the expected outcome in the test record. Include a request with missing information so the team can see how the app asks for clarification.
If the proposed action involves another customer’s record, the same access boundary must hold. The permission checks you tested earlier apply to requests made through a friendly conversation the same way they apply to the page.
Check a failed release before you need to recover one
A return to an earlier code version may leave a database change in place. Ask the engineer to explain what a particular planned update changes and how recovery works if the new version cannot operate correctly.
Run any restore exercise separately from the live service. Check the data and files the app uses, because backup coverage differs by provider. Supabase’s backup documentation, for example, says database backups do not restore the actual files held by its Storage service.
Our website handover exercise covers the account and recovery record. An app with private accounts needs the engineer to extend that exercise to its access rules and to whether the recovered records still agree with each other.
Leave the review with evidence and decisions
Use one row per finding, with the behavior observed, the expected result and the person responsible for the repair. Add a link to the test that shows the fix.
| Finding | Evidence needed before closing it |
|---|---|
| One customer can reach another’s test record | The same request is rejected after the repair |
| A private key reached the browser | The key is revoked and the new build omits its replacement |
| A repeated request creates duplicate work | Repeating the request produces the intended single outcome |
| An AI action bypasses a business rule | The rule is enforced for that action and role |
| Recovery omits required files | A separate restore demonstrates that the files are available |
Keep a customer-data exposure at the top of the list, above any cosmetic improvement. Tie launch decisions to the impact of each finding and the evidence still missing.
If you own the app and want a shorter list to start from, our owner’s checklist for AI-built apps covers accounts, customer data, breakdowns and costs. This exercise should leave you with a shorter record: the important behaviors you tested, the ones that failed and the repairs needed before customers use them.