You already shipped and now you're worried: a 60-minute containment plan

If you have already shared your vibe-coded app with real users and you are now concerned about security, the first move is not to panic or to rebuild. It is to contain. In most cases: restrict access or take the app private, rotate any API keys you suspect might be exposed, and check who has been accessing what. This article walks through that sequence step by step. An hour of deliberate work now is worth more than three hours of reactive scrambling later.

Before you start: the right frame

Something prompted you to search for this. Maybe you read about exposed vibe-coded apps. Maybe someone mentioned a security issue. Maybe you noticed something in your app that seemed wrong. Whatever it was, the fact that you are here is a good sign — you are taking this seriously before a problem forces your hand.

The goal of the next 60 minutes is not to make your app perfectly secure. It is to reduce immediate exposure, understand what your current state is, and identify what needs to happen next. Most things can be fixed. The ones that cannot be fixed in an hour can at least be contained while you find help.

Work through these steps in order. Each one is a discrete action you can complete and check off.

The 60-minute plan

Minutes 0-10: Restrict access

Action: Make it harder for an unknown person to access your app while you work through the rest of this.

If you are not sure whether your app is publicly accessible, open it in a private / incognito browser window without logging in. If you can see anything other than a login screen, the app is publicly accessible.

Minutes 10-25: Rotate API keys

Action: Find and rotate any keys that might be exposed.

Open your app in your regular browser. Open developer tools (right-click, Inspect, then the Network tab). Reload the page and use the app for 60 seconds — log in, trigger the main functions. Search the network requests for the strings key, token, secret, sk-, pk_live, and Bearer.

For every key you find that appears in the results, use this quick-reference to decide what to do:

After rotating each key: place the new key only in your builder's secrets manager or server-side environment — not in any frontend file.

If you are not finding anything alarming in the network tab: that is good, but continue the rest of the steps anyway. The network tab check is fast; the other checks are also worth doing.

Minutes 25-40: Check who has been accessing what

Action: Look at the activity logs for your most sensitive services.

If you see activity that looks unfamiliar — requests you did not make, charges you did not initiate, volume that does not match your usage — note it and move on to the next step rather than investigating now. Forensics can come after containment.

Minutes 40-55: Run the two-account data isolation test

Action: Verify whether one user can see another user's data.

If you have users — even a small number — this is the most important functional check.

Create two test accounts using email aliases ([email protected] and [email protected] work fine). Log in as User A, create a record, and note its URL or ID. Log out. Log in as User B. Try to navigate to User A's record.

If User B can see User A's record, you have a data isolation issue that is currently affecting your real users. This requires a code fix — it cannot be addressed through configuration alone. Note it as the top priority for the repair phase, and consider whether you need to take the app private while it is fixed.

If User B cannot see User A's record, that particular resource type is protected. Test any other major resource types your app manages.

Minutes 55-60: Make a short list of what to do next

Action: Write down three things — what you found, what you fixed, and what still needs attention.

You do not need to resolve everything in the next hour. You need to know what you found so you can communicate it clearly to a developer, to AgentC, or to yourself in a follow-up session.

Useful format:

• What I did in the last hour: (took app private / rotated X key / checked logs)
• What I found: (list any keys that were exposed, any unusual log activity, any data isolation failures)
• What still needs attention: (ranked — most urgent first)

The most common ranking after this exercise:

1. Any key that was exposed and has not yet been rotated — address this before anything else.
2. Any data isolation failure — take the app private or restrict new users while this is fixed.
3. Any unusual activity in service logs — understand what happened before re-opening the app to users.
4. Any Supabase tables with RLS disabled — enable RLS and add policies before re-opening.

When to call for help

Do this containment work first. Then, if any of the following are true, the next step is getting a developer or security reviewer on the call:

• You found keys that were exposed and you cannot determine whether they were used by anyone else.
• You found data isolation failures and you have real users whose data may have been accessible to other users.
• You found unusual activity in your service logs that you cannot explain.
• Your app handles payments and you are not certain the payment integration is correctly configured.
• Your app handles health, legal, financial, or regulated data.

These situations do not mean your app is irreparably broken. They mean the repair requires more than a solo walkthrough, and getting the right help in the right sequence will save time and prevent mistakes.

What to ask an expert

After completing this plan, bring these items to a review conversation:

1. Here is what I found in the network tab — are there any keys I missed or misidentified?
2. Here is what I saw in the service logs — does this look like unauthorized use?
3. Here is the result of the two-account test — what is the scope of the data isolation issue?
4. What is the right order of operations to fix what I found without making things worse?

If you want AgentC to work through the next steps with you — identifying what needs to be fixed, in what order, and how to verify that each fix is complete — the right starting point is a demo conversation. We meet you where you are, without judgment, and tell you what is urgent, what can wait, and what does not need to change.

Related guides in this series

• Is your AI-built app safe to put in front of customers? (the pillar guide) — the full triage
• Did the AI put your API keys in the wrong place? How to check and what to rotate
• Can someone see another user's data in your AI-built app?
• How to tell if your Supabase database is exposed (without being a developer)
• What should you ask an expert to audit in your AI-built app?

Frequently asked questions

Should I tell my users if I found a problem?

That depends on what you found. If you found a key that was exposed but see no evidence it was used by anyone else, disclosure to users is a judgment call. If you found that one user's data was accessible to other users, disclosure to affected users is appropriate and in many jurisdictions legally required — the specific requirements depend on your location, your users' locations, and the type of data. Get legal advice if you are uncertain. Do not let disclosure questions stop you from doing the containment work first.

I cannot take the app private — users depend on it. What then?

Complete the key rotation steps regardless of app availability. If your Supabase tables have RLS disabled, enable it on each table (this does not require taking the app offline). If you have a data isolation failure, consider whether you can temporarily disable the specific features that expose the data while the fix is prepared, rather than taking the whole app offline. Prioritize the highest-severity findings first.

My app has no users yet but I shared the link publicly. What is my risk?

Without users and without sensitive data, the primary risk is API key exposure — someone using your keys to rack up charges on your paid services. Complete the key rotation steps. If you have a Supabase database, verify RLS. If the app has no user-submitted data and no active API keys with meaningful permissions, the remaining risk is low until you add those elements.

How long does it take to actually fix the things I find?

Simple fixes — rotating a key, enabling RLS on a Supabase table — take minutes. Fixes that require code changes — adding object-level authorization checks, adding server-side authentication middleware, adding rate limits — can take hours to days depending on the size of the codebase and how many endpoints need to be updated. A developer who is familiar with your stack can usually scope the work after a 30-minute conversation about what you found.

Can I use the AI to fix the problems I found?

Yes, with verification. AI app builders and AI code generators can make the changes you describe. The important step is re-running the relevant test after the fix — the two-account test for data isolation, the network tab check for API keys, the Supabase dashboard check for RLS. Verification is what confirms the fix was applied correctly and completely, not just that the code looks different.

About this guide

Written by Seth Tucker, founder of AgentC Consulting. Seth spent approximately five years as a security engineer on election infrastructure used by roughly one in three American voters, holds SOC 2 Type 2 and ISO 27001 experience, and now helps non-technical founders and operators build, review, and trust AI-built applications.

Last updated: June 2026. Sources cited throughout reference original research, vendor documentation, and public reporting.