Securing Vibe-Coded Internal Apps: A Practical Guide

By Lazar Milicevic · Published October 8, 2026 · 10 min read

Somewhere in your company, someone built an internal app last month with an AI tool. It reads customer data, it has a public URL, and nobody in charge of security knows it exists. This guide covers how to find those apps, what usually breaks in them, and how to fix them without shutting down the speed that made them useful.

How big is the problem, really?

The honest answer: the data is mostly vendor-sourced and skews toward mid-sized companies, but the direction is consistent across independent sources. Treat the numbers as signals, not precise measurements.

Start with the caveat. The article that inspired this post is sponsored content from Retool, written by its CEO, and published by VentureBeat. Retool sells a governance platform, so its surveys serve its business. Here is what they report, attributed accordingly:

• In a Retool survey of 307 CIOs, CTOs and CISOs, only 5% said they were very confident they had full visibility into all internal tools running across their organization.
• In the same survey, 93% were at least somewhat concerned about vibe-coded internal tools running in production, and 38% ranked them among their top operational risks.
• Only 8% described their governance as strong, and only 4% said they had governance covering AI-generated code regardless of how it was written.
• In Retool's separate Build vs. Buy survey of 817 Retool customers and builders, 60% said they had built something outside IT's oversight in the past year.

Two limits matter. These respondents work at companies with 50 to 1,000-plus employees, so a five-person shop is not represented. And builders surveyed were already Retool customers. If you're a solopreneur or a small team, read these as "what happens as you grow," not "what is happening to you today."

Independent evidence points the same way. In May 2026, security firm RedAccess found 380,000 publicly accessible assets built with Lovable, Base44, Replit and Netlify. Roughly 5,000 of them (about 1.3%) held sensitive corporate information. VentureBeat reports that several of these platforms make apps publicly accessible by default unless users switch them to private, and many get indexed by search engines.

That default is the heart of it. This is the same failure pattern as the open storage bucket: not malice, not sophisticated hacking, just a convenient default that nobody reviewed.

What actually breaks in AI-generated apps

Most failures are boring and repeatable: missing access control, exposed secrets, and databases reachable without authentication. The code often works perfectly. It just works for everyone, including people who shouldn't see it.

The evidence:

• Broken access control is still the #1 web risk. OWASP Top 10:2025 keeps Broken Access Control at A01:2025, and Server-Side Request Forgery was merged into it. Its core prevention advice is to deny by default, except for public resources. AI tools tend to do the opposite, because "make it work" and "make it open" look identical during a demo.
• Model quality isn't fixing it. Veracode's 2025 GenAI Code Security Report tested more than 100 LLMs across Java, JavaScript, Python and C#, and found 45% of AI-generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities. It also reported that larger or newer models did not produce more secure code than smaller ones. A later update cited by the Cloud Security Alliance found the pass rate unchanged at roughly 55%. Figures vary across secondary sources, so go to Veracode's own reports if you need exact numbers.
• Public vibe-coded apps leak real things. In October 2025, Escape.tech scanned 5,600 publicly available vibe-coded apps and found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets and 175 instances of personal data exposure.
• Database rules get skipped. CVE-2025-48757 describes insufficient Row-Level Security policies in Lovable-generated sites through 2025-04-15, allowing remote unauthenticated attackers to read or write arbitrary database tables. The supplier disputes the CVE, so read the NVD entry yourself. A third-party write-up citing researcher Matt Palmer's scan reported that 170 of 1,645 Lovable apps (10.3%) had exposed databases. That comes from a blog citing the researcher, so treat it as indicative.

Gartner's "Predicts 2026," as reported by VentureBeat, forecasts that by 2028, prompt-to-app approaches adopted by citizen developers will increase software defects by 2,500%. That is a forecast, not a measurement. I include it for direction only.

The pattern across all of these: the tool optimizes for "it runs," and nothing in the loop asks "who is allowed to use it?"

Step 1: Find what already exists

You can't secure what you can't see. Only 5% of surveyed leaders said they had full visibility. For a small team, you don't need a platform to fix that. You need an afternoon and a spreadsheet.

Do these in order:

1. Ask, without blame. Post in your team channel: "List every tool, dashboard, or script you built with an AI builder (Lovable, Replit, Base44, Cursor, Claude, anything). No consequences, I just need the list." If people fear punishment, they hide things.
2. Check billing. Search your card statements and accounting software for the builder platforms and hosting providers. A $20/month charge is often the only trace of a live app.
3. Check your domains and DNS. List every subdomain you own. Forgotten tools.yourcompany.com records often point at a prototype.
4. Search for yourself. Search your company name plus terms like "dashboard," "admin," or "portal" and see what a stranger finds. Search for distinctive strings from your own data.
5. Record each app. One row per app: owner, URL, what data it touches, who uses it, auth method, hosting platform, last change.

A minimal inventory looks like this:

- app: lead-tracker
  owner: sam@yourcompany.com
  url: lead-tracker.example.app
  data: [customer_email, deal_value]
  users: sales team (4)
  auth: none            # red flag
  public: true          # red flag
  platform: AI app builder
  last_change: 2026-09-12

Anything with auth: none and customer data goes to the top of the fix list.

Step 2: Triage by data, not by app

Rank apps by what they can leak, not by how polished they look. A rough three-tier sort is enough:

Tier 1 apps that are publicly reachable are the equivalent of an open bucket. Take them offline first and ask questions after. A broken internal tool for a day is cheaper than a data exposure.

Step 3: Fix the five failure points

Nearly every vibe-coded app review comes back to the same five checks.

1. Authentication in front of everything. Don't let each app invent its own login. Put it behind your identity provider (Google Workspace, Microsoft Entra, Okta) with single sign-on. If the platform has a "make private" toggle, use it. Verify by opening the URL in a private window while logged out.

2. Authorization that denies by default. Authentication says who you are; authorization says what you can touch. Write the rule down per role: who can read, who can edit, who can delete. Then enforce it on the server or database, never only in the UI. A hidden button is not a permission.

3. Database-level rules. If your app uses Supabase or a similar backend, Row-Level Security must be on, with explicit policies. Test it like an attacker would: take the public API key out of the browser and query tables directly.

# Replace with your project URL and the anon key visible in your app's JS
curl -s "your_project.supabase.co \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

If that returns customer rows, anyone on the internet can read them. Run it against your own apps only, and fix it before you do anything else.

4. Secrets out of code. AI tools love pasting API keys into source files. Scan for them with a secret-scanning tool (detect-secrets and gitleaks are two common open-source examples; follow each tool's official documentation for installation and usage), rotate any key that was ever committed or shipped to the browser, and move the rest to environment variables or a secrets manager.

Rotation matters more than scanning. A key that appeared in a public app should be treated as compromised, even if you've since deleted the file.

5. Logging you can read. If something goes wrong, you need to answer "who accessed what, when." At minimum, log authentication events and every read or write of Tier 1 data. Logs nobody checks are barely better than none, so pick one person to review them weekly.

Step 4: Put a review gate between "built" and "live"

The real fix isn't a one-time cleanup. It's a lightweight process so the next app doesn't repeat the problem. Heavy approval workflows fail, because people route around them. Keep the gate small enough that it takes minutes.

A workable gate for a small team is a single checklist, completed by the builder and spot-checked by a second person:

## Internal app launch checklist
- [ ] Added to the inventory (owner, data, users)
- [ ] Sits behind SSO; logged-out access verified in private window
- [ ] Roles defined; server/DB enforces them (not just UI)
- [ ] Database policies tested with direct API calls
- [ ] No secrets in code or browser bundle; keys rotated if ever exposed
- [ ] Auth and data-access events are logged
- [ ] Not indexable by search engines (private by default confirmed)
- [ ] Second person reviewed: ______  Date: ______

Two rules make this stick:

• No second-person review, no production URL. The reviewer doesn't need to be a security expert. They need to run the checklist and try to break it.
• Make the safe path the fast path. If setting up SSO takes a day, people will skip it. Prepare a template: a pre-configured project with auth, logging, and private-by-default already wired in. Then "build a new tool" starts from something secure.

Retool's sponsored piece argues that security should be enforced at the platform and data layer rather than app by app, citing row- and column-level data controls, query-level audit logging, SSO, SCIM and group-based RBAC. The principle is sound, whichever vendor you use or whether you build it yourself: centralize the controls so that individual builders cannot forget them. Those specific features are Retool's own product claims, so evaluate any platform against your own needs.

Step 5: Decide what to keep, rebuild, or retire

Not every vibe-coded app deserves saving. After triage and hardening, sort what's left into three buckets:

• Keep: the app does one clear job, has a named owner, and passed the checklist. Schedule a quarterly re-check.
• Rebuild: the idea is valuable but the foundation is shaky (no auth model, data sprawl, hardcoded everything). Use the prototype as a spec, then rebuild with proper structure. This is often faster than patching.
• Retire: nobody uses it, or an off-the-shelf SaaS tool does the job. Delete the app, revoke its keys, remove the DNS record, and cancel the billing. Dead apps with live credentials are pure liability.

One more habit worth adopting: every app gets an owner and an expiry review date. Orphaned tools are where old credentials and forgotten public URLs accumulate.

What not to do

A few reactions make things worse:

• Banning AI builders outright. People are already building outside IT's oversight, and that is my interpretation of the pattern, not a finding of any survey: bans tend to reduce visibility rather than increase it. Give people a sanctioned path instead.
• Relying on the AI to secure its own output. Asking the same tool to "make this secure" can help catch obvious issues, but Veracode's findings suggest you shouldn't treat it as a guarantee. Use it as a first pass, then verify with real tests.
• Trusting "private" settings you haven't tested. Check from the outside, logged out, every time.
• Treating survey percentages as your personal odds. The numbers above come from specific samples, many of them vendor-commissioned and weighted toward larger companies. Use them to justify an audit, not to predict your exact exposure.

Where this fits in practice

The pattern I see most often is a team that built something genuinely useful with an AI tool and now depends on it, with no one having looked at how it's secured. My day-to-day work is practical AI automation for solopreneurs and small teams, and this kind of cleanup, getting an AI-built tool from "it runs" to "it's safe to rely on," is a natural extension of it. The approach in this guide, without throwing away the speed that got these tools built in the first place, is the one I'd follow myself.

If you have internal apps you aren't sure about, start with your inventory (even a rough one) and work through the checklist above, highest-risk apps first.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.