Replit lets you move from a prompt to a running app quickly. Before publishing, inspect what the Agent built and which production resources it can reach. A successful preview is one test of behavior; it does not establish correct access control.
1. Separate credentials from public configuration
Replit’s Secrets documentation distinguishes sensitive credentials from non-sensitive configurations. Secrets become environment variables, and the docs note that Secrets are unavailable to Static Deployments.
Keep provider keys and database credentials in the appropriate secret settings. Then inspect every place the generated code reads them. Environment storage cannot protect a credential that your code returns to the browser or embeds in a frontend bundle.
For each credential, record its owner, purpose, environment and rotation path. Use test credentials while testing integrations. If a key appeared in a prompt, source file or public bundle, rotate it with the provider and investigate the exposure.
2. Review the published environment
Inventory the framework, server handlers, database, authentication provider and external services. Compare the production settings with the editor environment; verify rather than assume they match.
Use a fresh browser session against the published hostname. Confirm that an internal app requires authentication and that public registration matches your intent. Check the permissions of project collaborators separately from the permissions of your app’s users.
3. Test authorization with two users
Create test users A and B with synthetic data. Save one record as A, then try to read, edit, export and delete it as B by changing the request identifier. Repeat for uploads and download links.
The server or database must reject each unauthorized operation. A hidden button or frontend route guard does not establish this boundary. Include a signed-out request and a lower-privilege user in the same test.
4. Exercise errors and external calls
Temporarily use a controlled failing upstream in your test environment. An AI API failure, rejected payment webhook or unavailable database should produce an honest failure response and a useful redacted log.
Check that user-provided fields cannot set roles, prices or ownership. Validate webhook signatures in the server path before mutating data. Add a regression test for the exact failure you reproduce.
5. Scan the repository you will ship
Sync or export the current source, then run:
npx @neuralaxis/vibedoctor scan --fullVibeDoctor analyzes the repository; it does not sign into Replit or validate live database permissions. Read scanner completeness before interpreting findings. Follow the report’s recovery instructions for any missing engine, and verify repairs against the published app.
Finish with the AI app security test and production readiness checklist. Keep the test evidence and repository revision together so the next Agent change does not silently undo the fix.