Guide
How to run vibe-coded software safely
Before an AI-built app holds customer records or runs a business process, check what happens when someone uses it in a way you did not expect. Test access, data changes and external actions, then establish how you would recover a mistake.
Short answer
Use a private test environment and synthetic records to check permissions, invalid input and repeated actions. Keep live credentials out, review dependency findings and verify a recovery procedure. Hosting safeguards reduce risk but do not establish that the application behaves correctly.
Separate hosting safeguards from application checks
AI-built business applications need both. A managed platform can operate the database, isolate workloads and capture backups. If you run your own server or assemble these services separately, name an owner for each responsibility and check the configuration.
AppHaven handles these production concerns around the application, including private access and separate virtual machines for branch deployments. Your team still needs to test whether a booking can be duplicated or one customer can read another customer’s invoice.
Begin with what the app can affect
Write down the records it stores and the actions it can trigger. An invoice viewer has a different risk from an app that sends invoices, changes bank details or charges a card. Include integrations even if your agent added them as a small convenience.
For each action, name who may perform it and how you would notice a mistake. This gives the review a concrete target. “Check security” is too vague to tell you whether a user can download somebody else’s invoice.
Try these cases in a preview
| Try this | Check this |
|---|---|
| Use two accounts with different permissions | Each user sees only permitted records, including through direct API requests. |
| Send the same payment or booking request twice | The application does not charge twice or create duplicate bookings. |
| Submit missing, negative or unusually long values | The server rejects invalid input without corrupting existing data. |
| Call a debug or export URL while signed out | No private data is returned. Remove development-only endpoints. |
| Trigger an application error | The response and logs do not expose credentials or sensitive records. |
| Run a migration on older test records | Existing records remain usable and the migration finishes as expected. |
Keep the preview’s external effects separate
A separate database protects the data inside that deployment. It does not prevent a preview using a live email key from emailing a customer, or a live payment key from making a charge.
Use sandbox accounts for integrations and synthetic recipients. If you cannot isolate an integration, disable its side effects in the preview and test the integration through a separate controlled procedure. Do not infer isolation from a different URL alone.
Close the most common gaps
Keep private apps private
Leave the AppHaven login gate enabled for team apps. Review every public path exception and authenticate webhook requests separately.
Check permissions on the server
Hiding buttons helps the interface; it does not restrict an API. Make permission checks part of each protected read and write.
Remove exposed secrets
Inspect the diff, build context and logs for secrets. If a real key was committed or exposed, rotate it with the provider. Deleting the line does not revoke the key.
Review dependencies
Check new packages and vulnerability findings. A scanner identifies known issues; it does not audit business logic or automatically prove an upgrade is compatible.
Enforce release review
Protect the production branch and review changes before deployment. Keep the agent’s diagnostic access separate from credentials that can release code.
Act on security scanning results
AppHaven checks built images and declared dependencies for known vulnerabilities, then re-checks production nightly. The vulnerability-management guide explains findings and fixes. Use that feedback to update affected dependencies or the base image, then test the change in a preview.
A scan does not prove that invoice permissions or booking rules are correct, and it does not automatically fix your code. On any platform, decide who reads the findings, applies fixes and verifies the resulting app.
Use AppHaven to reduce the work around those checks
The app and each preview run in separate virtual machines. Private apps have managed sign-in in front of them, and production has backups with database recovery history. These are useful safeguards you do not have to implement inside every new app.
A virtual machine boundary does not make the application immune to compromise. A signed-in user can still exploit a missing permission check, and malicious code can still misuse credentials available to its own process. AppHaven’s security documentation explains the platform boundary; keep application tests focused on what happens inside it.
Finish with a recovery exercise
Choose a disposable test dataset and rehearse a restore through your provider’s documented process. On AppHaven, agree the exercise with support. Check what would be recovered, how long it takes, and who would make the decision during an incident.
Record the procedure alongside the app. Include external effects such as payments and email, which cannot be undone by restoring the database. The release guide includes an example recovery request.
Common questions
Is a login gate enough to make the app safe?
It restricts entry to private apps. It does not replace record permissions, input validation, safe file handling or protection against unwanted actions by signed-in users.
Should I let an agent inspect logs?
Read-only access can help diagnosis. Logs may contain sensitive information, so limit access, avoid logging secrets and tell the agent not to reproduce private records in its response.
Put hosting safeguards around your app
Evaluate AppHaven’s hosting safeguards alongside the application checks in this guide.