Automated mass-scanning (established)
Scanning the whole internet for new, exposed services is routine and long-standing. Fresh domains and public repositories are probed continuously, not targeted by hand.
The threat model
The AI-agent threat model for vibe-coded apps.
A sober, sourced look at what's actually worth taking from a small app, how automated and agentic attackers changed the economics of going after one, and the specific exposures they probe for — each mapped to a public standard and to a real check you can run.
Reviewed October 23, 2026 · Updated October 23, 2026
Our stance, stated plainly
We sell the scan. So we drew the line between fact and our view.
This is written by Viberrr, an independent security and trust layer for AI-built apps. We make money when people scan, so read the framing with that in mind.
Where something is an established fact, we source it. Where it's our analysis — like the effect of AI agents on attacker economics — we label it as our view rather than reaching for a number we can't stand behind.
We don't rank AI builders and we don't claim any specific builder is insecure. A leaked key looks the same whichever tool wrote it.
The point of a threat model isn't fear. It's a short, honest list of what to check — so the worry becomes a to-do.
What changed
The economics of attacking a small app flipped.
Attacking a tiny app used to cost a person's attention, so most small apps were simply beneath notice. Automation removed that cost. The deeper then-and-now story is on why scan; here's what it means for your model of who's looking.
Agentic amplification (our analysis)
Cheap, tireless AI agents lower the cost and widen the reach of that scanning: what one skilled attacker used to do by hand, a swarm can now attempt across thousands of small apps at once. We present this as our view, not a cited statistic.
Opportunistic, not personal
You don't have to be a target to be hit. Automated attackers don't care who you are — only whether a known exposure is present on your domain or in your repo.
Step one of the model
What you have that's worth taking.
A threat model starts with assets, not attacks. If your app holds any of these — and almost every app holds the first — it's worth an automated attacker's (zero-cost) attempt.
Your users' data
Emails, accounts, messages, uploads, identity documents. The thing a breach actually spills — and the thing that ends up in the news.
Your keys & money
Live API keys (Stripe, OpenAI, cloud) are spendable credentials. A leaked key is someone else's bill, your data, or your account.
Your users' trust
The hardest asset to rebuild. One public incident on a small app can end it before it's really started.
Step two of the model
The exposures an automated attacker probes for.
Not a theoretical list — these are the exact things SafeLaunch checks for, each tied to a public standard so you can verify what it means. An automated scanner is looking for the same six.
Exposed secrets & keys
Live Stripe, OpenAI, Anthropic, AWS, GitHub or Google keys — and Supabase service-role keys — hard-coded in source or committed in .env files. Automated scanners grep public repos and shipped bundles for these patterns constantly.
Open databases & missing access rules
Supabase tables without row-level security, or the service-role master key shipped to the browser. The public key every visitor already holds becomes a key to everyone's rows.
Hidden or malicious code
Obfuscated code tucked far to the right of a line behind a wall of whitespace, or preinstall/postinstall scripts that fetch and run remote code on every build.
Known-vulnerable dependencies
Packages with publicly known CVEs. Attackers match your installed versions against the same vulnerability databases we do — the OSV project — and go straight for the known hole.
Live-site exposure
No HTTPS or HSTS, no Content-Security-Policy, and secret files left downloadable — a reachable /.env or /.git/config on your own domain. Bots probe these exact paths on every new site.
Unmanaged AI data flow
Where user input actually goes (which AI providers, in which countries), model files in formats that can execute code when loaded, and features that feed user text into a prompt without defending against injection.
Our analysis
Why vibe-coded apps are over-represented.
We can't put an honest number on this, so we won't. But the shape of the problem is consistent, and it follows from how these apps get built.
Speed is the whole pitch
AI builders optimise for shipping something that works in an afternoon. Security defaults — access rules, headers, secret hygiene — are the quiet work that gets skipped when the goal is a live demo.
The guardrails are invisible
A non-technical builder can't see that a table has no row-level security or that a key reached the browser. The app looks finished, so it ships. The exposure is real but silent.
Nobody's role is to check
There's no security team on a solo build, and the AI that wrote the code can't neutrally certify it's safe. The one independent step — an outside check before launch — is the one most likely to be missing.
Not hypothetical
What it looks like when an exposure goes unchecked.
Two documented cases, each tracing back to one exposure above that nobody tested before launch. Figures and status are from public reporting and the NVD — see Sources.
~72,000 images exposed from an unsecured bucket
A legacy storage bucket was left reachable on the public internet; private images, including identity photos, were downloaded and spread. Maps to open storage / missing access rules (OWASP A01).
Source: public reporting, July 2025 · Checked Oct 23, 2026
Missing database access rules in AI-generated apps
The NVD entry describes insufficient row-level security in Lovable-generated apps, letting unauthenticated users read or write arbitrary tables. The vendor disputes it, arguing data rules are the customer's responsibility — which is exactly why an independent check on your app matters. Maps to missing RLS (CWE-863).
Source: NVD (disputed) · Checked Oct 23, 2026
Step three of the model
What actually shrinks the attack surface.
You can't stop automated attackers from looking. You can make sure that when they look, there's nothing on the list for them to find. Two steps do most of the work.
- Independent — not the builder certifying its own output
- Cross-builder — the checks don't change with the tool
- Continuous — the seal un-verifies if something regresses
Run the first scan that matters
Before launch, check the running code and the live site against every exposure above. Fix what's critical, re-scan, then ship. This is the step automated attackers are counting on you to skip.
Keep it checked after launch
Your app changes; a passing scan goes stale. Continuous monitoring re-runs the checks and un-verifies the seal the moment something regresses — so the trust signal stays honest.
Sources & citations
Everything load-bearing, linked.
The standards behind each exposure, the database we scan against, and the two incidents. Claims that are our analysis are labelled as such above, not cited here.
- [1]OWASP Top 10
The category mapping behind the access-control (A01), vulnerable-components (A06) and security-misconfiguration (A05) exposures.
Checked Oct 23, 2026
The reference for the AI data-flow and prompt-injection exposures.
Checked Oct 23, 2026
CWE-798 (hard-coded credentials), CWE-863 (incorrect authorization) and CWE-506 (embedded malicious code).
Checked Oct 23, 2026
The database used to match dependencies against publicly known vulnerabilities.
Checked Oct 23, 2026
Insufficient database row-level security in Lovable-generated apps (CWE-863, published 2025-05-29; disputed by the vendor).
Checked Oct 23, 2026
Coverage of the July 2025 Tea incident and the ~72,000 images exposed from an unsecured storage bucket (Tom's Guide).
Checked Oct 23, 2026
Questions
The model, in plain answers.
What is a threat model, in plain terms?
It's a simple, honest inventory of three things: what you have that's worth taking (your data, keys and money), who might try to take it (increasingly, automated and AI-driven scanners rather than a person targeting you), and the specific weaknesses they look for. Naming those three things is most of the work — it turns vague worry into a short list you can actually check.
Is the 'AI agents attacking apps' idea hype?
The underlying fact isn't: automated, internet-wide scanning for exposed services has been routine for years, and new apps are probed within minutes of going live. What we add is an analysis, stated as our view — that cheap, tireless AI agents lower the cost and widen the reach of that scanning. We don't put a fabricated number on it.
Why are vibe-coded apps more exposed than others?
Because speed is the whole appeal, security defaults are the quiet work that gets skipped, and the exposures are invisible to a non-technical builder — a table without access rules or a key that reached the browser looks exactly like one that's safe. And the AI that wrote the code can't neutrally certify that it's secure.
What single step reduces the most risk?
An independent check of the running code and the live site before you launch — specifically for leaked secrets, open databases, missing access rules, vulnerable or hidden dependencies, and an unhardened live site. It's the step automated attackers are counting on you to skip.
Ready when you are
Scan my appFind your exposures before an automated scanner does.
SafeLaunch checks your repo and live site against every exposure above, explains each finding in plain English, and hands you the fix.