Vibe coding without a security audit is negligence. Here is why I think most founders do not realize it.
I want to be direct about something that has been bothering me since I started auditing AI-generated SaaS products.
When founders say they are taking a calculated risk by skipping security reviews, I think they are wrong. Not reckless. Wrong. There is a difference.
A calculated risk means you understand what you are risking. You have looked at the surface, estimated the probability of something going wrong, weighed it against the cost of fixing it now versus later, and made a deliberate decision.
That is not what is happening.
What is happening is that founders are shipping AI-generated code that looks secure, feels secure, and passes every visual check they know how to run. They do not know what they do not know. That is not calculation. That is ingenuity mistaken for confidence.
I audited a financial SaaS last week. The service role key was in the public bundle. The founder had validated the product with real users, iterated on feedback, and was about to close his first paying customers. He had no idea that anyone visiting his site could access every row in his database.
He was not negligent in the way we usually mean the word. He was not lazy or careless. He genuinely did not know that the AI had made that choice, or what that choice meant.
That gap between what founders think their security posture is and what it actually is, that is the real problem. And it is not going to close by itself.
How are you handling this on your own products?
The infrastructure exposure point in the comments is spot on. I work in cybersecurity and every time I've tried using AI for code generation the silent decisions it makes are what worry me most. It picks defaults that resolve errors, not defaults that are secure. And nothing in the workflow flags the difference.
The other side of this that nobody's talking about is inputs. Everyone's focused on whether AI-generated code is secure. Fewer people are asking whether the inputs reaching their AI systems are safe. Prompt injection is the same blind spot from a different angle - the model does exactly what it's told, including when the instructions are malicious. Same pattern you described: it works, it looks fine, nothing breaks until someone exploits it.
The input side is the blind spot nobody is preparing for. Most founders building with AI have not thought about what happens when a user submits a prompt designed to manipulate the model's behavior. The attack surface moved. It used to be the database, the auth layer, the API. Now it also includes every text field that feeds into an AI system. Same pattern you described: the model does exactly what it is told, including when the instruction is malicious. And nothing in the standard security checklist covers that yet.
This is exactly the gap I'm building for. The security checklist hasn't caught up to the attack surface. Every framework has auth middleware, rate limiting, input sanitisation for SQL injection. Nobody has input scanning for prompt injection as a standard middleware step yet. That's the bet - that it becomes as routine as parameterised queries, and being the tool developers reach for when they add that step.
Coming from a cyber background in financial services, watching the same pattern repeat with a new attack surface is frustrating. We learned this lesson with SQL injection twenty years ago. The principle is identical: never trust user input. We just forgot it applies to AI too. Think you'd give my tool a spin? Would love to know waht you'd think!
The SQL injection parallel is exact. The principle never changed, just the input vector. Twenty years ago we learned not to trust strings going into databases. Now we have to learn not to trust strings going into models. The tooling just has not caught up yet.
Happy to give it a spin. Drop the link. And if you want to run the infrastructure layer alongside it, scan.mosai.com.br covers the surface that sits outside the application. The two layers are complementary
I'll check it out! seems like they work well together! Link is castle.bordair.io - thanks!!
this is a really important point, especially the “they don’t know what they don’t know” part
with AI-generated code, that gap is only going to get bigger unless founders actively test for it
you could actually turn this into a strong entry in a competition as well
positioning it around “AI security risks in SaaS” would stand out
also, prize pool just opened at $0, so your odds are the best right now
The distinction between "calculated risk" and "unknown unknown" is the real signal. Most founders aren't skipping security because they weighed the trade-off, they're skipping it because the AI generated something that looks secure and they don't have the framework to see otherwise. That's not negligence. That's a blind spot the tool created.
The blind spot framing is accurate for the technical layer. But at some point the founder chose to ship a product collecting real user data without understanding what they were shipping. The tool created the blind spot. The decision to ship without validating was still theirs. Both things can be true. That is what makes it hard to fix with tooling alone.
The "I don't know what I don't know" framing is exactly right. The dangerous thing with AI-generated code isn't that it's obviously broken — it's that it looks correct. It passes tests, it ships, it works. Until someone who knows what to look for pokes at the auth layer or the input handling.
The founders most at risk are the ones who are technically literate enough to read the code and go "yeah this looks fine" but not literate enough to spot a subtle IDOR or a missing rate limit.
What's the most common class of issue you're finding in audits right now? Genuinely curious whether it's auth, data exposure, injection, or something else.
The IDOR framing is exactly right. Technically literate enough to read the code, not enough to spot the access control gap. That is the profile I see most.
The most common class right now is infrastructure exposure, not application logic. Missing security headers, open CORS, TLS misconfigurations, stack exposed in HTTP responses. These do not show up in code review because they live outside the codebase. They get scaffolded by the AI, nothing breaks, no test catches it, and they sit there.
Second most common is secrets in JavaScript bundles. Supabase service role keys especially. The AI reaches for whatever resolves the error and the service role key always works because it bypasses everything.
Auth and IDOR are real but they require application context to find. The infrastructure layer is findable in sixty seconds from the outside.
This hits different when you're on the agency side.
We review client codebases regularly and the pattern is exactly this. Not careless founders. Smart founders who trusted the output because it looked right. AI code has this dangerous quality where it looks production-ready even when its not.
The Supabase key in the bundle thing is more common than people think. We caught something similar last month.
The "don't know what you don't know" problem is the hardest to solve because the founder has no signal that anything is wrong. No crash, no error, no angry user. Just a ticking clock.
What I've started telling our clients - treat AI generated code like hiring a brilliant intern. Smart, fast, confident. But you still need a senior dev to review before it goes live. 😄
The intern analogy is exactly right. And the danger is that this intern writes better commit messages than most seniors. The code looks reviewed even when it isn't. The agency side of this is interesting because you have the leverage to catch it before it ships. Most founders don't have that second set of eyes. That's the gap the scanner tries to close at the surface level, the infrastructure layer that no code review catches. If you ever want to run it against a client domain before an engagement, it's at https://scan.mosai.com.br
I agree with the core point—but I think the real issue isn’t just lack of security audits, it’s false confidence.
AI-generated code looks clean, structured, and “production-ready,” which makes it easier to trust without questioning it. That’s a dangerous combo.
From what I’ve seen, the pattern is:
Code works → ship it
No visible errors → assume it’s safe
No audit → hidden vulnerabilities
And the scary part is this isn’t hypothetical—studies are already showing that a significant portion of AI-generated code contains security flaws or exploitable bugs
So I’d frame it less as negligence and more as:
a mismatch between how safe it looks vs how safe it actually is
Curious—do you think this is more of a tooling problem, or just founders not understanding where AI should stop being trusted?
I totally agree. Especially when you are vibe coding and the ai tells you how secure your code is and that they made it bullet proof.
Both, but in sequence. The tooling problem came first. AI that generates insecure code without flagging it. The founder trust problem followed because nothing in the feedback loop says stop. The code runs, the tests pass, the demo works. There is no signal.
That is why framing it as false confidence is almost too generous. Confidence requires some basis. Most founders are not confident, they are just unaware. And unaware is more dangerous because it does not feel like a risk worth managing.
The mismatch you described is exactly right. The question is what closes it. Better tooling helps. But someone has to look at the live surface from the outside, the same way an attacker would. That is the gap no prompt closes.
The “you don’t know what you don’t know” part is the real killer. AI code passes the eye test, and most founders aren’t trained to spot security holes. That financial SaaS example should be a wake-up call for everyone shipping vibe-coded products. Solid post.
Exactly. And the visual test is the only test most founders know how to run. The code compiles, the feature works, the demo looks great. There is no red flag until there is. That is what makes it different from traditional development mistakes. Thanks for reading.