The Hidden Cybersecurity Cost of SMB-Built AI Apps
Somewhere right now, an employee at a small or mid-sized business is finishing up an internal app they built on their work laptop over the past two weekends. They're not a developer. They've never been a developer. But they have a real problem they're trying to solve, the kind of problem that's been on their plate for months, and they've been told by every IT person they've ever worked with that fixing it is on the roadmap. Someday.
So, they open an AI coding assistant, type in what they need, and start shipping. By Sunday night, the app works. They demo it Monday morning. Their coworkers love it. Their boss loves it. By Friday it has quietly become part of how the team operates.
The owner doesn't know it exists. The IT provider doesn't know it exists. And nobody, including the person who built it, has any idea whether it's secure.
This is happening in thousands of small and mid-sized businesses every week.
What is vibe coding, and why is it a security risk?
Vibe coding is a workflow where someone — usually not a professional developer — prompts an AI coding assistant, accepts the code it produces, and ships it without close review. The term was coined by Andrej Karpathy in early 2025. The security risk is structural: vibe-coded apps typically skip every safeguard of a software development lifecycle — no code review, no security scan, no authentication standards, no logging, and no monitoring — while still handling real business and customer data. Most leadership teams have no inventory of these apps, which means the company is carrying unmanaged risk it cannot see, price, or insure.
The patterns are remarkably consistent. An operations employee at a manufacturer builds something that pulls live data from the company's ERP and pushes it to coworkers, running on infrastructure that was never intended for what it's doing. A compliance professional at a services firm spins up a web-hosted tracker for client progress and accidentally exposes an AWS API key in the process. A startup founder ships a customer-facing app built with an AI assistant, hardcodes secrets in the wrong place, and watches attackers run unauthorized charges through it before he can rotate the keys. That last one cost the founder around $2,500 in Stripe fees and hit roughly 175 of his customers before it was caught. He wrote about it on Medium afterward. His own words were that he didn't blame the AI. He trusted it too much.
There's a name for what these stories have in common. Andrej Karpathy coined "vibe coding" in early 2025 to describe a workflow where you prompt an AI, accept what it produces, and ship. It was meant partly as a joke and partly as a real observation about how software was starting to get made. A year later, it's no longer a joke. It's how a large and growing share of internal business applications now get built, by people who aren't engineers, in companies that have no idea any of this is happening.
The productivity gains are real. A salesperson who couldn't write a for-loop a year ago can ship a working customer portal in an afternoon. That's genuinely impressive, and it's genuinely useful. I'm not here to argue against it.
But the way most SMBs are doing this right now, the speed comes with a tab that gets paid later. Sometimes the tab is $2,500 in Stripe fees. Sometimes it's a breach notification letter going out to clients. Sometimes it's the quiet erosion of trust as customers slowly notice that something feels off. Often, the tab is invisible until it isn't.
This paper is about that tab. What's on it, who pays it, why most SMBs can't see it coming, and what to do before it comes due.
The New Developers in Your Company
Two or three years ago, if a small business wanted an internal app, the options were narrow. Hire a developer. Pay a consulting firm. Buy off-the-shelf software and live with its limitations. Beg the one technical person on staff to build something on the weekend. Most often, the answer was the fourth option, and most often, the app never got built.
That bottleneck is gone.
The people writing software inside SMBs today are not, by and large, developers. They're operations managers, customer success leads, finance directors, marketing coordinators, compliance specialists, salespeople, HR generalists, and executive assistants. Many of them couldn't have explained the difference between a backend and a frontend two years ago. A few of them still can't. It doesn't matter. They have AI coding assistants, they have a clear problem to solve, and they have enough English-language fluency to describe what they want.
Walk into a 200-person company today and ask around. You'll find an HR coordinator who built a resume screener that uses an AI model to rank applicants. A finance analyst who built a tool that pulls accounting data and emails a daily P&L summary to leadership. A sales operations person who built a small customer portal so prospects can check their proposal status without bothering anyone. A customer success rep who built a chatbot that answers tier-one support questions. A marketing director who built a landing page generator that spins up a new microsite from a Google Sheet.
None of these people consider themselves developers. They consider themselves problem solvers. The apps work. The business benefits. Everyone is happy.
And then there's where these apps actually run. The honest answer is "wherever was easiest." A lot of them get deployed to free or low-cost hosting platforms with a one-click button. Some run on a laptop under someone's desk. Some live on a shared drive and get launched manually when somebody needs them. Some are quietly running on a server that was originally provisioned for something else two years ago and was never decommissioned. Some sit in a cloud account that was opened with a personal credit card and never moved to the company's actual governance.
In a real software company, none of this would be acceptable. There would be a software development lifecycle, often abbreviated SDLC, which is just a fancy way of saying "the steps we follow when we build software so we don't ship something broken or dangerous." That lifecycle would include design review, code review by another engineer, automated tests, a security scan, a deployment process with rollback, and ongoing monitoring after the app is live.
In a typical SMB, with a typical vibe-coded internal app, exactly zero of those things happen.
The person who built the app reviewed it themselves. The person who tested it was them, or maybe a coworker who clicked around for five minutes. The security scan never ran. There's no deployment process to roll back to. Nobody's monitoring it. If something breaks, the first sign will probably be a customer complaint, an angry email from a vendor, or a phone call from someone whose card got hit with fraudulent charges.
Here is the part that should make any owner or operator a little uneasy. Most leadership at these companies, including the CEO, the COO, and the head of IT if they have one, has no idea how many of these apps exist. There's no inventory. There's no asset list. There's no map. The HR coordinator's resume screener has never been mentioned in a leadership meeting. The salesperson's customer portal has never appeared on an architecture diagram, because there is no architecture diagram. The chatbot is running on someone's personal Replit account, and the only person who knows the login is the person who built it.
This isn't a small problem. It's a structural one. You can't secure what you don't know exists. And right now, in most SMBs, leadership doesn't know what exists.
The Vulnerability Inventory
If you brought a competent security person into the room and asked them to audit a typical vibe-coded SMB app, you would not be in the room very long before they started taking notes with both hands. The failures stack up fast. Some are old problems coming back in new clothes. Some are entirely new categories born from the way AI assistants generate code. All of them are predictable enough that, after seeing a few dozen of these apps, you can usually guess what's wrong before you finish reading the first file.
Start with secrets. An API key, a database password, a service account token, the credentials that let an app authenticate to whatever it talks to. In well-built software, secrets live in dedicated services, get rotated regularly, and never appear in code. In vibe-coded software, secrets routinely live in the frontend of the app, in plain view, embedded in JavaScript that anyone on the public internet can download and read. They live in source code that gets committed to a public GitHub repository. They live in environment files that get accidentally uploaded with the rest of the project. The Medium case mentioned in the opening, the one that cost the founder $2,500 in Stripe fees, was at its core a secrets exposure problem. The AI didn't know any better. The person who shipped the code didn't know to check. The app worked. The keys were exposed. The damage followed.
Authentication is the next reliable failure. A surprising number of internal vibe-coded apps simply have no login. The reasoning, if anyone bothered to articulate it, is that the app is for internal use, the URL is obscure, nobody outside the company would ever find it. This is called security through obscurity, and it has been a known anti-pattern in cybersecurity for roughly forty years. Obscure URLs get discovered by automated scanners constantly. Internal networks get penetrated. Employees leave with the URL still in their browser history. When auth does exist on these apps, it's often homegrown, copied out of the AI's first suggestion, and tends to fail in interesting ways. A common pattern: the login form looks real, but the backend doesn't verify the password against anything. Whoever knows the URL gets in.
Then there are the old vulnerabilities the security community thought it had mostly wrestled to the ground. SQL injection, where a user types a malicious string into a form and the app dutifully runs it as a database command. Cross-site scripting, where an attacker plants code in one part of an app and the browsers of other users execute it. Insecure direct object reference, where changing a number in a URL lets you see someone else's data because the app didn't bother to check whether you were allowed to. These are not new problems. They appear on the OWASP Top Ten, which is a widely used list of the most common web application vulnerabilities maintained by a nonprofit and used as a baseline in security audits around the world. Mature software companies spend real engineering time defending against them. AI coding assistants will happily generate code that contains all three, because the model was trained on a lot of code, and a lot of code on the internet has these flaws.
There is also a newer set of failures specific to apps that integrate AI features themselves. Prompt injection is the headline one. An attacker types text into a field that the app feeds into a language model, and the text is crafted to override whatever the developer told the model to do. Suddenly the customer support chatbot is happily sharing internal pricing notes, or generating a refund authorization it had no business issuing, or describing the contents of a database the user should never have seen. There are also data leakage issues that nobody thinks about until it's too late. The "free" AI tool the developer used to help write the code probably had a data policy that allowed the provider to retain prompts. If sensitive customer data was pasted in during development, or if the live app sends customer data to the model at runtime, that data is now somewhere it shouldn't be. Nobody is going to send a letter explaining this.
The last failure is the quietest one, and in some ways the worst. Most vibe-coded apps have no logging. No record of who used them, what they did, when they did it. No alerts when something looks wrong. No record of failed login attempts. If an attacker exploits the app today, the company will find out about it, if at all, when something visible breaks downstream. A customer complains. A bank declines a charge. A regulator calls. By that point, the attacker has had days, weeks, or months of free access, and there is no log file that can be used to reconstruct what they did. The company can't tell its customers what was taken, because the company doesn't know.
The Compliance and Liability Picture
Most SMB owners think about compliance the way they think about a tax audit. Something that might happen, that they're probably mostly fine, that they'll deal with if it comes up. This stance has worked, more or less, for a long time. It will not survive contact with AI-generated apps.
The reason is simple. Compliance frameworks were written to govern a world where software was built by people who knew what they were doing, following processes, with documented controls. The frameworks assume that if data flows through a system, somebody has thought about who's allowed to see it. They assume that if a system processes regulated data, the controls in the framework have been applied to that system. None of this is true for vibe-coded apps. The data flows are real. The apps are real. The compliance gap is real. The only thing missing is the part where anyone goes looking.
For SMBs in the defense industrial base, this matters acutely. The Cybersecurity Maturity Model Certification, known as CMMC, governs how defense contractors handle controlled unclassified information, or CUI. If a salesperson at a defense contractor builds an AI-assisted tool that touches CUI, even tangentially, that tool is in scope for CMMC. It needs to meet the same access control, audit logging, configuration management, and data protection standards as everything else the company runs. In practice, none of those standards have been applied. The tool is invisible to the company's compliance program. When the assessor shows up, the tool either gets discovered, which is bad, or stays hidden, which is worse if it ever leaks data later.
The same pattern plays out in healthcare. The Health Insurance Portability and Accountability Act, HIPAA, doesn't care whether the app that handles protected health information was built by a senior engineer or a billing coordinator with an AI assistant. The legal obligation is the same. The penalties are the same. The investigation, if there's ever a breach, will not be sympathetic to the explanation that a non-technical person built it.
In payments, the Payment Card Industry Data Security Standard, PCI DSS, applies the moment an app touches cardholder data. PCI has detailed, specific, frequently audited requirements for how that data is stored, transmitted, and protected. A vibe-coded checkout flow that lives outside the company's PCI-scoped environment is, technically, a serious violation. It may also be why the company's processor terminates them after a breach, regardless of any other facts.
For service businesses, SOC 2 reports are increasingly demanded by enterprise customers as a condition of doing business. SOC 2 audits assess whether a company's controls over its systems are working as described. If a SOC 2-audited company is running vibe-coded apps that handle customer data and aren't reflected anywhere in the control environment, the audit either misses them, which exposes the company's customers, or catches them, which exposes the company.
And then there's cyber insurance, which is where this story is going to get loud first. Underwriters are not waiting for regulators. They are already asking pointed questions in renewal applications. Do you have an inventory of applications that handle sensitive data? Do you have a software development lifecycle? Do you review code before it goes into production? Do you have controls around the use of AI tools by employees? Most SMBs answer these questions optimistically, which is a polite way of saying the answers do not reflect reality. When a claim happens, and the carrier's forensic team finds that the breach happened through a vibe-coded internal app that nobody declared, the coverage conversation gets uncomfortable. Misrepresentation in an insurance application is grounds to deny a claim. It is also grounds to rescind the policy entirely.
The legal exposure outside of insurance is its own conversation. Breach notification laws in nearly every state require companies to notify affected individuals when their personal data is exposed. The clock starts when the company learns of the breach. If the company can't determine what data was in the app, what was accessed, or when, it ends up notifying everyone, conservatively, which is expensive and damaging on its own. If the breach involved regulated data, federal and state agencies get involved. If customers feel the company was negligent, lawsuits follow. None of these processes care that the original app was built in a weekend by an enthusiastic operations person.
The hard truth is that a vibe-coded app sitting on a company's network is a compliance liability the company hasn't priced. The cost shows up later, when the bill comes from somewhere unexpected, in a form that doesn't look like a tech expense at all. It looks like legal fees. Insurance denial. Lost contracts. Regulator letters. The tab the opening referenced is, increasingly, this.
The MSP Blindspot
Most SMBs do not run their own security. They outsource it. They have a managed service provider, an MSP, that handles their IT. They might have a managed security provider, an MSSP, layered on top, watching for threats. They have endpoint detection and response, EDR, running on their company laptops. They have a security information and event management platform, a SIEM, ingesting logs from their sanctioned systems. They have a stack. They have coverage. They have, on paper, a security program.
None of this stack sees the vibe-coded app.
EDR runs on the company laptop. It watches the operating system, the running processes, the file system. It is excellent at catching ransomware, suspicious binaries, and known attacker tooling. It is not designed to watch an externally hosted web application that an employee built in a weekend and deployed to a third-party platform. From the EDR's perspective, the employee opened a browser and went to a website. Nothing to see.
The SIEM is no better off. A SIEM is only as good as the log sources feeding it. The MSP set up log forwarding from the company's firewalls, its identity provider, its sanctioned cloud accounts, its endpoint agents. The vibe-coded app sends no logs to the SIEM, because the person who built it didn't know what a SIEM is, and even if they did, plumbing logs into one is harder than the rest of the build combined. As far as the SIEM is concerned, the app does not exist. As far as the MSSP analyst watching the SIEM is concerned, the app does not exist.
This is shadow IT, but with an upgrade. The old shadow IT problem, the one MSPs have been managing for two decades, was about employees signing up for cloud services without telling anyone. Dropbox accounts. Personal Gmail. Slack workspaces. The fix was a combination of policy, training, and tooling that could detect unsanctioned SaaS usage. That tooling, broadly called cloud access security brokers, exists and works reasonably well.
The new shadow IT is different. It isn't a sanctioned SaaS product being used outside policy. It's net-new software, written by an employee, hosted somewhere the company doesn't have any visibility into, doing things the company doesn't know about. There is no SaaS product to detect. There is no vendor to bill. There is no domain to flag. The app might be hosted on a free tier of a platform that thousands of legitimate companies also use, which makes detection by network traffic basically impossible.
For the MSP or MSSP serving the SMB, this is a structural problem, not a vendor failure. The tools available to them are not yet designed to find these apps. The contract scope they were hired under probably doesn't include "discover undocumented internal software written by non-technical employees." When a breach happens through a vibe-coded app, the SMB will look at its MSP and ask why they didn't catch it. The MSP will look at the contract and ask how they were supposed to. Both will be right. Neither will be helpful.
The honest answer is that the security model most SMBs are running was built for a world where the only people writing software were people who knew they were writing software. That world is over. The model needs to catch up. It hasn't yet. Until it does, the gap between what the MSP can see and what the company is actually running will keep getting wider.
What To Actually Do About This
The instinct, when faced with this picture, is to ban it. Issue a policy. Tell employees they're not allowed to build internal apps with AI assistants. Make them request approval from IT for any new tool. Reset the universe to its old, slower, safer state.
This instinct will fail. It will fail for the same reason every blanket ban on useful technology has ever failed. The productivity benefit is too obvious, the cost of compliance is too high, and the enforcement mechanism does not exist. The HR coordinator will keep using the resume screener. The salesperson will keep using the customer portal. They'll just stop telling anyone. The shadow gets darker.
The better path is to govern the activity, not forbid it. Five practical controls, in roughly this order, will close most of the gap.
1 Inventory
You can't secure what you don't know exists, and the first job is finding out what exists. This is mostly a non-technical effort. Send a short survey to every team asking what internal tools and apps they use, who built them, what data goes into them, and where they run. Be explicit that the goal is not to get anyone in trouble. The goal is to understand. The response rate will be imperfect. Some apps will stay hidden. That's fine for the first pass. The act of asking, repeatedly, over time, surfaces more than the act of mandating ever will. Network traffic analysis and outbound DNS logging can supplement the surveys and catch apps the surveys miss.
2 Classification
Once you know what exists, sort the apps by two dimensions. How sensitive is the data they touch, and how exposed are they to the outside world. A spreadsheet automation that runs on someone's laptop and only handles internal calendars is in a very different category from a customer-facing portal hosted on the public internet that processes order data. Most companies will end up with three or four bands of risk, and most apps will land in the lower bands. The ones that land in the upper band are where the limited security attention should concentrate first.
3 Paved Roads
Make it easier for employees to build apps the safe way than the unsafe way. Sanction one or two AI coding platforms that meet the company's basic standards. Provide a sanctioned hosting environment with single sign-on, secrets management, basic logging, and TLS already configured. Make secrets management as easy as pasting a value into a UI. The principle, borrowed from larger software companies, is that you should never ask employees to be security experts. You should give them rails so that doing the right thing is the path of least resistance. Most vibe-coded security disasters happen because the unsafe path was the easy path. Change that, and you eliminate most of the problem before it starts.
4 Review
Apps that handle sensitive data or are exposed externally get a lightweight pre-production review. Not a six-week audit. A short checklist. Are secrets in the right place. Is authentication working. Are obvious OWASP issues absent. Is logging on. This review can be handled by an internal security team if one exists, by the MSP if scope is expanded to include it, or by a third-party vendor for the relatively rare upper-band apps. The point is that something other than the builder's own optimism checked the app before it went live.
5 Monitoring
The sanctioned hosting environment should be sending logs into the company's existing SIEM. Authentication failures, unusual traffic patterns, and runtime errors should generate alerts. If a customer-facing app starts behaving oddly at three in the morning, somebody other than the customer should know. This is the same operational discipline that mature software companies apply to their own products. It is not optional for SMBs running their own internal software, however casually that software came into being.
None of these five controls require enterprise budgets. The total annual cost of implementing all five, for a typical SMB, is well under what a single breach would cost. The bigger barrier is cultural. Leadership must acknowledge that the company is now, in part, a software company. That acknowledgment does not come naturally to a 60-person manufacturer or a 30-person law firm. But the software is being shipped. The data is moving. The exposure is real. The only question is whether it gets managed deliberately or whether it gets discovered the hard way.
Where This Goes Next
The pace is going to accelerate. The AI assistants that produce code today are already being outclassed by agents that produce, deploy, and operate code with minimal human intervention. The operations coordinator who took two weekends to build their first internal app a year ago will, sometime in the next twelve months, be able to ship a similar app in an afternoon, without writing or reviewing any code at all. They will describe what they want. The agent will build it, host it, and hand them a URL. The flaws in the result, if any exist, will be invisible at a level the person who ordered the app could never have caught, even with effort.
Regulators are starting to notice, but they are slow. Cyber insurers are starting to notice, and they are faster. State attorneys general are starting to notice. Industry-specific frameworks like CMMC will, eventually, address AI-generated code explicitly. By the time the rules are clear, most SMBs will already have years of unaddressed exposure on their networks. The companies that put governance in place now will be ready when the formal expectations arrive. The companies that don't will spend the back half of the decade in a permanent state of remediation.
There is a separate question about what happens to the workforce. As AI assistants get better, the line between a developer and an everyday business user keeps eroding. Some companies will treat this as a liberation, dissolving formal engineering teams in favor of empowered domain experts. Others will recognize that the role of the engineer is changing, not disappearing, and that the value of someone who understands what the AI just produced is going up, not down. Both bets are being placed right now. The companies that bet wrong will learn about it through breach disclosures.
What is clear is that the small and mid-sized business is now, whether it wants to be or not, a software company. The software is being built inside its walls, by its own people, with tools that did not exist three years ago. The data flowing through that software is the company's, and its customers'. The liability for what happens to that data is the company's, regardless of who wrote the code or what the writer's job title was.
The companies that internalize this will treat AI-assisted internal software the way they treat any other operational capability that touches sensitive data. With deliberation. With visibility. With controls. They'll capture the productivity benefits without quietly trading them for tail risk they never priced.
The companies that don't will find out what's on the tab.
Frequently Asked Questions
What is vibe coding?
Vibe coding is a workflow where someone prompts an AI coding assistant, accepts the code it produces, and ships it without close review. The term was coined by Andrej Karpathy in early 2025. It has rapidly become a common way for non-developers — operations managers, HR coordinators, salespeople — to build working internal business applications.
Why are vibe-coded apps a security risk?
Because they skip the software development lifecycle entirely: no code review, no security scanning, no authentication standards, no logging, and no monitoring. Common failures include exposed API keys and secrets, missing or broken login systems, classic OWASP Top Ten vulnerabilities like SQL injection, prompt injection in AI-powered features, and zero audit trail when something goes wrong.
Are employee-built AI apps a compliance problem?
Yes, whenever they touch regulated data. An AI-built tool that touches CUI is in scope for CMMC; one that handles patient data falls under HIPAA; one that touches cardholder data falls under PCI DSS; and undeclared apps undermine SOC 2 audits. Cyber insurers are also asking about application inventories and SDLC controls in renewal applications — an undeclared, vibe-coded app behind a breach can become grounds to deny a claim.
How can a company find the shadow AI apps it doesn't know about?
Start with a non-punitive survey asking every team what tools they use, who built them, what data they touch, and where they run — then repeat it regularly. Supplement with network traffic analysis and outbound DNS logging to catch what surveys miss. Once apps are found, classify them by data sensitivity and external exposure, and focus security attention on the highest band.
Should companies ban employees from building apps with AI?
No — bans push the activity underground and make the visibility problem worse. The more effective approach is governance: maintain an inventory, classify apps by risk, provide a sanctioned "paved road" platform with SSO, secrets management, and logging built in, require a lightweight pre-production review for higher-risk apps, and feed runtime logs into existing security monitoring.
Notes
The startup case referenced in the opening was originally documented by the writer CodeRonin on Medium in March 2026, in a piece titled "When Vibe Coding Costs Real Money: A Startup Lost $2,500."
The term "vibe coding" was coined by Andrej Karpathy in early 2025 to describe a workflow of accepting AI-generated code without close review.
The OWASP Top Ten, referenced in the vulnerability inventory section, is published and maintained by the Open Worldwide Application Security Project.