Can I launch an app built only with AI? It depends on who will use it
To validate an idea, show it to investors, or test a flow with half a dozen people, you can and should. To put real customers, personal data, or payments inside, not without a security review done by someone who knows the subject.
The reason is simple. AI optimizes for making things work. It delivers the login screen, the sign-up, the order list. What it rarely delivers on its own is the invisible part: who can see what, what happens when someone sends strange data, where passwords and keys are stored.
My position: vibe coding is great for the first draft and dangerous as a final version without review. The most common mistake I see is treating the draft as the product.
What this week's news shows about apps built with AI
A Brazilian software quality and security company, Sofist, published tests run on a restricted-access commercial app built with vibe coding. The screen had no public button to create an account, so it looked closed. Even so, the server accepted direct creation of users that nobody had invited.
There was also a flaw in the multi-factor authentication step. And the detail that stands out most: according to the report, the app had been built by someone who already had security knowledge.
The practical lesson is that hiding a button protects nothing. The server is what protects, and that's exactly where AI tends to leave holes. The same report shows the bright side: where access rules were enforced directly in the database, the attacker got zero records.
The most common holes in AI-generated code
These aren't exotic flaws. They're the same old ones, produced faster than anyone can review them. These are the ones that show up most in security analyses of this type of app:
- Access rules only on the screen: the button disappears, but the API responds to anyone who calls the address directly.
- One customer's data visible to another: the system checks that you're logged in, but not whether the request is yours.
- Keys and passwords inside the code, sometimes visible to anyone who opens the browser.
- Database or admin panel open to the public because of default settings.
- Fields that accept anything, opening the door to command injection into the database.
- Login and multi-factor authentication implemented in a way that can be bypassed.
A 30-minute test you can run yourself
You don't need to know how to code to do the first round of screening. You need two test accounts and some curiosity.
Create user A and user B. With A logged in, open an order or profile and look at the address in the browser: if there's a number or code in it, swap it for one from one of B's records. If B's data shows up, you've found the most classic hole of all.
Then try these checks:
- Open a restricted page in an incognito window, without logging in. It shouldn't load.
- Try to create an account outside the app's screen, if the app is supposed to be invite-only.
- Test password recovery: does it reveal whether the email exists? Does it accept the same link multiple times?
- Type quotation marks and strange symbols into text fields and see whether the app breaks.
- Ask whoever built the app to show you where the integration keys are stored.
Where vibe coding works well and where it isn't worth the risk
It works well for prototypes, demo screens, disposable internal tools with no sensitive data, and proofs of concept. In those cases, speed matters more than hardening.
It isn't worth the risk when there's customers' personal data, billing, health, financial information, or anything that Brazil's LGPD (data protection law) covers. A leak isn't just a technical problem: it creates a notification obligation, damages customer relationships, and can lead to penalties.
There's also an effect that gets little attention. Each round of requests to the AI (add this, change that) touches parts of the code that nobody has reread. The more iterations without review, the harder it is to know what's still standing. Seeing the idea working in a clickable prototype before investing in the real code is a cheap way to separate draft from product, and it's what SKAD does with its R$ 99 prototype.
What to demand before taking an app to production
If your app was born in an AI tool and is about to gain users, you don't have to throw it away. You need a review with clear criteria. Ask, in writing, for these answers from whoever takes over the project:
- Is every permission rule validated on the server, and not just in the interface?
- Does every data query filter by the logged-in user or their company?
- Are secrets kept in protected variables, outside the code and outside the browser?
- Is there a limit on login attempts and an access log?
- Is there a tested backup, with restoration actually verified?
- Was the review done by someone independent of the person who generated the code?
Frequently asked questions
What is vibe coding?
It's creating software by describing what you want in natural language to an AI, which generates the code. In many cases the result is accepted without detailed review, and that's where the risks live.
Are AI-built apps inherently insecure?
Not inherently, but AI's default is to deliver something that works, not something hardened. With a review of access, authentication, and configuration, you can reach an acceptable level.
Can I use an AI-built app only inside my company?
You can, as long as it has no sensitive data and isn't exposed on the internet without a login. An internal tool left open by mistake is one of the most common ways data leaks.
Does an automated security scanner solve it?
It helps, but it catches only part of the problems. Logic flaws, such as one user seeing another's data, often require manual testing by someone who understands the business.
Conclusion
If you already have an AI-built app, run the two-account test today and write down what you find. If any leak between users shows up, stop promoting the app until it's fixed. And if you're still at the idea stage, use AI to validate the concept in a prototype, and only then hire the code that will hold real people's data, with an independent security review included in the scope.