Is This App Safe? How to Spot AI-Built Software Before You Hand Over Your Data

A new app appears. The landing page is clean, the branding looks sharp, the signup flow is smooth. You enter your email, your name, maybe your phone number, maybe your card details. You get a welcome email. Everything feels normal.

Underneath, that app design and build might have been generated by AI in a weekend, deployed without a security review, and storing your data in a database that anyone on the internet can query.

This isn’t hypothetical. In 2025, around 13,000 people had their personal information exposed through apps built on a single AI app-building platform; most of them had no idea the services they trusted were AI-generated, let alone insecure. The exposed data included names, emails, addresses, payment records, and in some cases other API keys that opened the door to further compromise.

The uncomfortable reality is that the burden of figuring out whether an app is safe has quietly shifted onto end users. There’s no badge, no disclosure rule, no required security baseline before a service can start collecting your data.

So here’s a practical guide to spotting the warning signs and protecting yourself.

Why End Users Are Now in the Firing Line

How to Determine if an App is Safe

Before AI tools made app and software development accessible to anyone, the path from “idea” to “app collecting your personal data” went through professional engineers, code reviews, and at least some baseline security thinking. That wall is mostly gone.

Today, anyone with a prompt and a credit card can:

  • generate a fully working web app in an afternoon
  • connect it to a database
  • collect signups
  • charge for a subscription
  • start storing real user data

None of those steps require the person to understand authentication, access control, encryption, or how to keep API keys out of public code. And the resulting app can look indistinguishable from one built by a serious team.

The hard part for users is that the surface gives almost nothing away.

Signals That an App Might Be AI-Built and Under-Secured

No single signal is proof. But when several stack up, it’s worth slowing down before signing up.

The Domain and Hosting

  • Hosted on a builder subdomain. URLs ending in .lovable.app, .vercel.app, .netlify.app, .replit.app, .bolt.new, or similar suggest the app may be early-stage or AI-built. Not automatically insecure — plenty of legitimate apps run on these platforms — but worth treating with extra caution before handing over real data.
  • Very new domain. A WHOIS lookup (free at sites like who.is) shows when the domain was registered. A site asking for payment details on a domain registered three weeks ago deserves more scrutiny than one with a five-year history.
  • No clear company behind the product. No registered business name, no physical address, no team page, no LinkedIn presence for the founders. Real software usually has a paper trail.

The Branding and Copy

  • Generic AI-flavoured naming. Names like “[Adjective][Noun].ai” or “[Verb]ly” combined with stock-feeling marketing copy. Not damning on its own, but a pattern.
  • Hero images that look AI-generated. Slightly off hands, oddly perfect lighting, faces with the smooth uncanny look of generated portraits.
  • Feature lists that read like a ChatGPT response. Three-bullet sections, identical sentence structures, every feature described in the same upbeat tone. Real product copy usually has more variation.

The Auth and Account Flow

  • No two-factor authentication option. Any serious app handling personal data, payments, or business information should offer 2FA. Its absence is meaningful.
  • Broken or weird login flows. Forgot-password emails that never arrive, confirmation emails from random Gmail addresses, signup forms that accept obviously invalid input. These often indicate broken auth design underneath.
  • Asks for far more information than the product needs. A note-taking app asking for your date of birth and phone number on signup is a flag. The data is being collected because it can be, not because it has to be.

The Trust Signals That Should Be There

  • No published privacy policy, or a clearly templated one. Look for specifics: what systems store your data, where they’re located, how long it’s kept, who it’s shared with. Generic templates with placeholder text suggest nobody thought hard about this.
  • No security or trust page. Established apps usually have something — even a basic page covering encryption, data handling, and how breaches are reported.
  • No working customer support channel. A support email that doesn’t reply, no live chat, no ticket system. If something goes wrong with your account, who do you contact?

The Practical Defence: Don’t Trust Apps With More Than They Need

Even with the best signal-spotting, you can’t always tell. So the realistic strategy is to assume any app might leak your data, and limit the damage if it does.

1. Use a Unique Password Every Time

This is the single highest-leverage habit a normal person can adopt. A password manager — Bitwarden, 1Password, Apple’s built-in Keychain, or your browser’s manager — generates a unique password per site and remembers it for you.

When (not if) one app gets breached, the leaked password is useless anywhere else.

2. Use Email Aliases

Services like Apple’s Hide My Email, Firefox Relay, SimpleLogin, or DuckDuckGo Email Protection let you create a different email address for every signup. They forward to your real inbox.

The benefit:

  • If one alias starts getting spam or phishing, you know exactly which app leaked your address.
  • You can shut off any alias instantly without affecting anything else.
  • Attackers who buy leaked email lists can’t link your accounts together.

3. Use Virtual Card Numbers for Payments

If you’re entering payment details into something you don’t fully trust, virtual cards are your friend.

  • Revolut, Wise, and most major banks now offer disposable or single-merchant card numbers.
  • In the US, Privacy.com is popular for this.
  • Apple Pay and Google Pay also tokenise your real card so the merchant never sees the actual number.

You can cap the spending limit, lock the card to one merchant, or kill it instantly if something looks off.

4. Be Selective About What You Upload

AI-built apps often store uploaded files in cloud storage buckets that are misconfigured to be publicly accessible. If you wouldn’t be comfortable with a document being viewable by anyone with a guessable URL, don’t upload it to a service you don’t trust.

This applies especially to:

  • ID documents (passports, driver’s licences)
  • Financial records
  • Medical information
  • Anything containing other people’s personal details

5. Watch for Targeted Phishing After Signup

The clearest sign you’ve signed up for a leaky app is a phishing email that’s too well-informed. If you start getting messages that reference:

  • a real order number
  • the actual amount you spent
  • a specific feature of the service
  • your real name combined with details only that service knew

…assume the service has been breached. Change your password there, rotate any payment card you used, and treat any “urgent action required” emails from that service as suspect for the next few months.

6. Check Have I Been Pwned Periodically

haveibeenpwned.com is a free service run by security researcher Troy Hunt. It tells you which known data breaches have included your email address. You can also subscribe to be notified if your address appears in a future breach.

It’s the closest thing to a smoke alarm for your digital life.

7. For Anything Financial or Health-Related, Prefer Boring Established Services

This advice sounds dull, but it’s statistically right. A ten-year-old company with an ugly website is almost always safer than a beautifully-designed app that launched last month — because the older company has had more time, more incidents, and more reasons to take security seriously.

For banking, insurance, healthcare, tax, or anything where a breach would seriously harm you, “exciting and new” is a feature you don’t actually want.

A Reasonable Mental Test Before You Sign Up

When you’re about to hand over your details to a service you don’t know well, run this quick check:

  1. Could I find anyone responsible? Is there a real company behind it, with a name and an address?
  2. Have I heard of this from a trustworthy source, or just an ad?
  3. Does it offer 2FA?
  4. Is it asking for more information than it actually needs?
  5. If this app leaked everything I’m about to give it tomorrow, what’s my exposure?
  6. Is the software or app built by a reputable company? Check the footer (right at the bottom) and see if it states who build it… See image below
Screenshot Of Footer Showing Software Built By Back9 Digital

If you can’t answer those comfortably, you don’t need to refuse, you just need to limit what you give. Use an email alias, a unique password, a virtual card, and the minimum information required.

What Should Change

End users shouldn’t have to be amateur security researchers to safely sign up for a service. The current state of things — where an AI-built app with no security review can collect your name, email, address, and payment details, and the only signal you get is a slightly-too-polished landing page — isn’t sustainable.

Eventually, this will likely shift through some combination of:

  • regulation requiring disclosure of AI-generated software handling personal data
  • platform-level security defaults that make basic mistakes harder to ship
  • consumer trust marks for services that meet a security baseline
  • insurance and liability pressure on businesses that deploy unreviewed AI-generated code

Until any of that arrives, the practical answer is the same as it’s always been with new technology: trust slowly, give up the minimum, and assume that what gets collected will eventually leak.

The good news is that the basic defences, unique passwords, email aliases, virtual cards, and a healthy scepticism — protect you against most of the damage even when an app does turn out to be insecure.

The bad news is that nobody else is going to do this for you.

Frequently Asked Questions

How can I tell if an app was built using AI?

There’s no definitive way, but signals include: hosting on AI builder subdomains (.lovable.app, .vercel.app, etc.), very new domains, generic AI-flavoured branding, AI-generated hero images, and feature lists that read like ChatGPT output. Most importantly: lack of a real company behind the product, no team or contact details, and no published security or privacy practices.

Is it dangerous to sign up for AI-built apps?

Not automatically; many AI-built apps are perfectly safe. The risk is that AI tools make it possible to launch software without the security review that used to happen by default. That means a higher proportion of AI-built apps ship with vulnerabilities like exposed databases, missing access controls, or leaked API keys. The damage usually shows up as data breaches and targeted phishing.

What information is most risky to give to an unknown app?

Anything that’s hard to change or rotate: government ID numbers, full date of birth, home address, real card details (use virtual cards instead), and unique passwords. Email and phone are also valuable to attackers but easier to mitigate using aliases.

How do I know if my data has already been leaked?

Check haveibeenpwned.com — it lists known breaches your email has appeared in. Also watch for unusually well-informed phishing emails referencing specific accounts or transactions. That’s often the first real-world sign that a service you used has been compromised.

What should I do if I think an app I signed up for has leaked my data?

Change the password on that service immediately. Change it on any other service where you reused that password (and switch to a password manager so you never reuse again). If you used a payment card, rotate it or use a virtual card going forward. Watch for phishing emails for several months. If serious data was exposed (ID, financial details), consider a credit monitoring service.

AI Software Security Risks: Why You Should Be Careful With Vibe Coding

AI has changed software development at a pace very few people predicted.

You can now generate websites, apps, automations, and entire software platforms in hours instead of months. At Back9 Digital we use AI ourselves; it’s a genuinely powerful tool when applied with care.

But there’s a growing pattern we’re concerned about: businesses (seemingly) trusting AI-generated software without properly considering what’s running underneath. And in the last twelve months, that concern has stopped being theoretical.

The Real Risk Isn’t That AI-Built Software “Looks AI-Built”

A lot of commentary on AI-generated software focuses on whether products feel generic or visually polished but operationally weak. Those are real observations — but they’re not the issue that should be keeping business owners awake at night.

The real issue is security.

Modern software is deeply connected into the systems businesses depend on every day:

  • customer information
  • payment systems
  • CRMs
  • email platforms
  • operational tools
  • automations
  • business databases

When vulnerabilities exist inside any of those systems, the consequences move from “annoying bug” to “genuine business risk” very quickly.

AI Generates Vulnerabilities Just as Quickly as It Generates Code

AI is excellent at producing software that works.

But working is not the same as secure, and that distinction is where most of the danger sits.

AI-generated code routinely introduces issues such as:

  • exposed API keys
  • insecure or missing authentication
  • weak permissions handling
  • exposed database endpoints
  • missing or misconfigured access control rules
  • poor input validation
  • vulnerable third-party dependencies
  • insecure server configurations
  • cross-site scripting (XSS) vulnerabilities
  • SQL injection vulnerabilities

The dangerous part is that none of this is visible to the average business owner. The app loads, the dashboard works, the forms submit. Underneath, the gaps may already be wide open.

Recent Incidents That Show Why This Matters

If you want to understand why this issue is urgent, three real incidents from the last year tell the story clearly.

1. Lovable + Supabase: AI-Generated Apps Exposed Real User Data (CVE-2025-48757)

This is the case study every business considering vibe coding should know about.

Lovable is a popular AI app-building platform that generates apps backed by Supabase databases. In 2025, security researchers found that a large share of Lovable-generated apps had broken or missing Row Level Security, the rule layer that controls who can read what data in the database.

The result: attackers didn’t need credentials. The public API key already embedded in the app’s frontend code was enough to query the database directly and pull out full user lists, payment records, and even other API keys.

Around 170 apps were affected, exposing data belonging to roughly 13,000 users — about 10% of all Lovable applications scanned.

This wasn’t a Supabase failure. Supabase’s security model works correctly when configured properly. The failure was in the AI-generated code, which produced apps that looked finished but didn’t lock down the database access controls underneath.

It’s a near-perfect example of the risk: software that ships fast, looks polished, and quietly leaks user data.

2. Vercel (April 2026): When Connected AI Tools Become an Attack Path

In April 2026, Vercel, one of the largest hosting platforms for modern web apps; disclosed a breach that began with a compromised third-party AI tool (Context.ai) used by one of its employees.

From there, attackers were able to pivot into Vercel’s internal environment and read environment variables across affected customer accounts that were not flagged as “sensitive”, meaning they were not encrypted at rest. Stolen data was later listed for sale on a hacker forum for $2 million.

The lesson here isn’t that Vercel built insecure software. It’s that environment variables, he same place AI-generated apps tend to dump API keys, database credentials, and third-party tokens, are a high-value target, and a single weak link in the AI tool chain can cascade into hundreds of downstream environments.

3. The Pattern Across Both Incidents

The common thread: AI accelerated the build, but the security thinking didn’t keep up.

In Lovable’s case, the AI generated code that skipped a critical access control layer. In Vercel’s case, the supply chain wrapped around AI tooling created an attack path nobody had stress-tested.

Neither would have been caught by “does the app work?” The damage in both cases was invisible from the surface.

What Exposed API Keys Actually Allow Attackers To Do

When people hear “API key leak”, it can sound abstract. In practice, it usually leads to one or more of the following:

  • Direct database access. Attackers can query, modify, or dump entire tables.
  • Impersonation. Acting as a trusted system to call internal APIs.
  • Infrastructure abuse. Spinning up resources or sending requests on the business’s bill.
  • Lateral movement. Using the leaked key to reach connected systems (email, payments, analytics).
  • Targeted phishing campaigns. Once attackers have customer names, emails, order history, or transaction patterns, they can craft phishing messages that look uncannily legitimate — referencing real orders, real account numbers, real product names. These campaigns convert at far higher rates than generic spam, which is why exposed customer data is so valuable on the criminal market.

That last point is exactly the chain you described, and it’s accurate. A leaked API key can lead to user data exposure, which can lead to highly targeted phishing — and from there to account takeover, fraud, or further compromise.

Why Most Businesses Don’t See the Danger

This deserves its own section, because it’s the heart of the problem.

Most business owners using AI to build or commission software:

  • can’t read the code being generated
  • don’t know what an environment variable is, let alone whether it’s encrypted at rest
  • assume that “the AI wouldn’t generate something insecure”
  • judge the product by what they can see — the UI, the dashboard, the working forms
  • have no internal benchmark for what “secure” even looks like

That’s not a criticism. Software security is a specialised discipline, and historically it sat behind a wall of expert review before anything went live.

AI vibe coding has removed that wall, but it hasn’t replaced what the wall was doing.

AI Doesn’t Understand Consequences

This is the part many businesses overlook.

AI predicts likely code patterns. It does not truly understand:

  • operational security
  • compliance obligations (GDPR, PCI-DSS, HIPAA, NZ Privacy Act)
  • breach recovery planning
  • data privacy implications
  • business continuity
  • infrastructure hardening
  • legal exposure if a breach occurs

It can generate functional code at remarkable speed. It cannot take responsibility for what happens when something goes wrong — and in a breach, the responsibility falls on the business that deployed it.

Speed Is Creating False Confidence

One of the biggest risks with AI development is how quickly businesses can move from idea → prototype → live product.

That speed creates a false sense of confidence. Launching software fast is not the same as launching software safely. Security reviews, dependency audits, permissions checks, environment hardening, and proper architecture still matter, arguably more, because the cost of skipping them is now lower in the short term and higher in the long term.

How To Use AI Safely In Software Development

We’re not anti-AI. Far from it. Used well, AI is one of the most useful tools to enter the industry in years. Used carelessly, it’s a liability waiting to surface.

The practical baseline we recommend:

  • Never deploy AI-generated code without human review — particularly anything touching authentication, database access, payments, or user data.
  • Treat every AI-generated environment variable as if it could leak. Use platforms’ “sensitive” or encrypted-at-rest options. Rotate keys regularly.
  • Verify access control at the database layer, not just in the app code. For Supabase-style setups, that means actually testing Row Level Security policies, not just enabling them.
  • Run dependency and secret scanning in CI/CD. Tools like GitGuardian, Snyk, and GitHub’s built-in scanners catch a lot of low-hanging fruit.
  • Test from an attacker’s perspective. A simple curl against your public API endpoints will tell you more than most automated reports.
  • Engage proper engineering oversight for anything connected to real user data, payments, or critical workflows.

Final Thoughts

AI is going to play a huge role in the future of software development. That’s not in question.

What is in question is whether businesses will treat AI-generated code with the same scrutiny they’d apply to anything else running their operations. The pattern of recent incidents; Lovable, Vercel, and the broader rise in AI-related supply chain attacks, suggests many won’t, until something forces them to.

Software that looks good on the surface can still leak customer data, expose credentials, and become the launch pad for targeted phishing campaigns against the very people who trusted the business with their information.

In an environment where anyone can generate working software in an afternoon, the real differentiators become security, stability, and trust.

That’s the bar worth building to.

Frequently Asked Questions

Is AI-generated software secure?

AI-generated software can be secure — but only when it is properly reviewed, tested, and engineered. Left unchecked, AI routinely produces code with exposed API keys, weak access controls, and vulnerable dependencies.

What are the biggest AI software security risks?

The most common risks include:
exposed API keys and environment variables
insecure or missing authentication
missing database access controls (e.g. Row Level Security)
vulnerable third-party packages
weak permissions handling
targeted phishing campaigns built from leaked customer data

Can exposed API keys lead to phishing attacks?

Yes. If attackers gain access to customer information through exposed keys or misconfigured APIs, that data is often used to build highly targeted phishing campaigns that reference real orders, accounts, or transactions — making them far more convincing than generic spam.

Is AI bad for software development?

No. AI is an incredibly powerful development tool. The risk comes from skipping the security review and engineering oversight that used to be built into the development process by default.

Why should businesses be concerned about AI-generated code?

Because most business owners can’t see the security gaps that AI-generated software often contains. The product looks finished, the dashboard works, customers can sign up — and yet the database might be queryable by anyone with the public API key. Recent incidents like CVE-2025-48757 (which exposed user data across 170+ Lovable-built apps) show this isn’t theoretical. Without proper review, the first sign of a problem is often a breach notification.