A few months ago, I was in a conversation with a mid-sized company that was genuinely proud of what they had built over a weekend.
One of their operations managers used a low-code platform to spin up an internal app that connected their CRM, order system, and a lightweight AI tool to answer customer questions. It worked. It was fast. It made people more efficient almost immediately.
Two weeks later, their IT security team flagged something that brought everything to a halt.
Customer data was being sent to a third-party AI service with no clear controls, no agreement in place, and no visibility into how that data was being stored or used.
The issue was not malicious intent. Nobody involved even knew what questions to ask.
The platform made it so easy to build that it removed the friction that usually forces people to think about security in the first place.
That is the real risk of what people are now calling ‘vibe coding’.
What Vibe Coding Actually Means for Security
Vibe coding is the idea that you can build applications by stitching together tools, prompts, and integrations without deeply understanding the underlying code.
Platforms like Bubble, Zapier, and Make have made this approach accessible to almost anyone in a business.
From a speed perspective, it is incredible.
From a security perspective, it is a black box.
When you are not writing code, you are also not seeing how authentication is handled, how data is stored, or what happens behind the scenes when an API call is made.
Most of these platforms abstract complexity by design, which means the person building the app is operating on trust rather than understanding.
I have seen teams assume that because a platform is enterprise-grade, everything built on top of it is secure by default.
That is not how it works.
Security is not inherited automatically. It has to be intentionally designed.
The Five Biggest Security Risks
Let’s break down where things actually go wrong, because this is not theoretical. These are patterns we see repeatedly.
1. Exposed API Keys
In one case, a team embedded an API key directly into a workflow to pull customer data from their CRM. That key ended up being visible in a client-side request.
Anyone with basic technical knowledge could have accessed it.
This is one of the most common issues outlined in OWASP’s API security guidance.
2. Data Sent to Public AI Models
Teams often connect applications to AI services without realizing where that data goes.
If you are sending sensitive customer or financial data into a public model, you may be exposing it beyond your control depending on the provider’s policies.
I have seen this happen with internal support tools that were quietly logging real customer conversations.
3. Inadequate Access Controls
Low-code apps often default to broad access permissions because it makes collaboration easier. Everyone’s an admin!
The problem is that “easier” usually means “less secure.”
I worked with a client where internal tools gave full visibility into customer accounts to anyone with a login, regardless of role. Don’t believe me? Check out this scan of over 5000 publicly available Vibe-coded applications that exposed over 2000 vulnerabilities.
4. No Audit Trails
When something goes wrong, you need to know who did what and when.
Many vibe-coded applications have little to no logging, which makes incident response extremely difficult.
That becomes a serious problem when you are trying to meet frameworks like those defined by National Institute of Standards and Technology.
5. Third-Party Integrations You Do Not Control
Every integration you add introduces another layer of risk. Vibe-coded apps often just grab a random published library with no review or evaluation of whether it’s kept up to date, secure, or what happens to the data you pass to it.
Most teams do not evaluate the security posture of third-party services, and they definitely do not monitor them over time.
We have seen cases where a single compromised integration became the entry point into a much larger system.
Why IT Does Not Know
This is where things become a larger organizational problem.
Most of these applications are built outside of IT.
They are created by operations teams, marketing teams, or even individuals trying to solve a problem quickly.
That is what we call shadow IT.
These tools do not go through security reviews. They are not version-controlled. They are not documented.
In many cases, IT only finds out they exist when something breaks or when a security alert is triggered, and they need to clean up the mess.
From the builder’s perspective, they are being efficient.
From the organization’s perspective, they are creating a risk that no one is tracking.
We have walked into environments where dozens of these tools are running in parallel, all connected to core systems, and nobody can clearly map how data flows between them.
That is not a technology issue. That is a governance issue.
What Actually Happens When Things Break
Let’s walk through what this looks like when it goes wrong.
An application exposes an API key or sends sensitive data to an unsecured endpoint.
Someone gains unauthorized access, and data starts getting pulled out of the system.
At that point, you are dealing with data exfiltration.
If that data includes customer information, financial records, or regulated data, you are now in violation of compliance standards like HIPAA or PCI-DSS.
That triggers reporting requirements, potential fines, and legal exposure.
But the real cost is not just regulatory.
It is the time spent investigating what happened.
It is the effort required to rebuild systems that were never designed properly in the first place.
And it is the loss of customer trust, as customers expect you to handle their data responsibly.
We have seen companies spend months recovering from issues that started with what they thought was a harmless internal tool.
Some firms dangerously rely on talent placed by placement firms as the basis for their entire platform. Check out what happened to the Tea chat app, where a broken authentication system allowed any user to read all users’ chats.
In some cases, those tools were built in less than a week.
If you want a deeper look at how this plays out in real environments, we discuss it in our perspective on hidden system risks and technical debt on Seisan’s blog, as well as in our breakdown of modern delivery challenges and governance gaps.
The Right Way to Use These Tools
Low-code and AI tools are not the problem.
How they are used is the problem.
These platforms are incredibly effective for internal prototypes, workflow automation, and non-sensitive use cases.
They allow teams to move quickly and validate ideas without heavy upfront investment.
The problem arises when they are used to handle sensitive data or critical business processes without oversight.
There needs to be guardrails.
That means security reviews before deployment.
It means clearly defined access controls and role-based permissions.
It means understanding what data is being used and where it is going.
Frameworks such as those from the National Institute of Standards and Technology provide a strong foundation for thinking about this at the organizational level.
Speed is valuable, but not at the expense of control.
Building Secure Solutions That Actually Scale
There is a reason enterprise systems take longer to build.
They are designed with architecture, security, and long-term maintainability in mind.
When you build solutions that you can actually audit, monitor, and evolve, you reduce the risk of surprises later.
You also give your business a foundation it can scale on.
Cutting corners here does not save money.
It just shifts the cost to a later point, usually when the stakes are much higher.
Don’t Let Speed Become a Liability
Vibe coding feels fast because it removes friction.
The problem is that it also removes visibility.
Security does not go away just because you cannot see it.
It becomes something you discover after the fact.
At Seisan, we spend a lot of time helping companies move quickly without putting themselves in a bad position later.
If you are thinking about how to balance speed and security in your own environment, it is worth having that conversation early rather than after something breaks. You can learn more about how we approach secure, scalable delivery on our services page or contact us to start a discussion.
