Five checks before using an AI built app at work
Check access, validation, data, secrets and recovery before an AI built app handles live business work.
Read the short answer
The short answer
A working AI generated prototype still needs checks for authorisation, input validation, data handling, secrets and recovery. Review the behaviour behind the screen before giving it customer information or permission to act.
Signing in is not the same as permission
A login page does not prove that one user is prevented from viewing another user’s records. Check permissions at the server and data layer, including direct requests outside the visible interface.
Decide what each role may read or change. Test those rules with users who should be refused access as well as users who should succeed.
Validate the request on the server
A form may look restrictive while its endpoint accepts almost anything. Check required fields, permitted values and the operations a request can trigger. Error handling should avoid leaking credentials or unnecessary record details.
A useful test includes missing, malformed and oversized input. It also checks what happens when the user repeats a submission.
Know where information is stored
Identify the database, file storage and services that receive data. Check ownership, access and retention. A temporary development database is not an appropriate assumption for durable customer records.
Document which environments contain live data. Avoid copying it into public demonstrations or sending it to an AI tool simply to diagnose a fault.
Keep secrets outside public code
Review API keys, service tokens and database credentials. A secret in browser code can be read by a visitor. A secret committed to a repository may need rotation even after it is removed.
Use the hosting platform’s appropriate secret configuration and limit permissions. Record who can rotate credentials and which services depend on them.
Prove recovery and ownership
Know how to restore the application and its data. Check backups, deployments and the people responsible for updates. A demo working on one developer’s machine is not evidence that a business can recover it after a failure.
A review should finish with findings, proposed repairs and the tests that support release. Some apps need a small correction; others need a rebuild. Specialist custom application work can be discussed with VibeZero after the scope is clear.
A useful test for an internal request app
Imagine an app that stores leave requests. A staff member should see their own request, while a manager should see only the records they are authorised to approve. Test changing a record identifier in a direct request, not only clicking the buttons that the interface provides.
Also test a repeated approval and a rejected request. The result should match the business rule without creating duplicate actions or revealing another person's information. OWASP guidance treats permission checks on each operation as a separate concern from whether someone has signed in.
What should a release review leave behind?
Ask for a record of the reviewed version, the tests performed and the remaining findings. Each finding should explain its effect, the proposed repair and how the repair will be checked. A screenshot of a completed form is evidence of the screen, not of the whole application.
Before release, identify who owns the repository, hosting account, database and external services. Keep a deployment and recovery note with the business. If the app still needs a person watching every action, treat that as a limitation to resolve before relying on it for unattended work.
Sources and further reading
These links take you to the publisher's guidance. Product details and requirements can change, so check the current source before making a change.
Content reviewed on 7 October 2026. This guide is a starting point. The scope of a support job depends on your systems, access and business requirements.