Someone at your company has already built something with AI. Maybe it is a spreadsheet macro that pulls your sales numbers. Maybe it is a small web app that tracks inventory. Maybe it is a script that emails a report every Monday morning.
They did not ask permission, because it did not feel like the kind of thing you ask permission for. It took them twenty minutes and it works.
This is vibe coding: using an AI coding tool to build software without knowing how to program. It is genuinely useful, and I am not here to tell you to ban it. I am here to tell you where it goes wrong, because the failure mode is quiet and it does not look like a security problem until it is one.
Why this is happening now
On the Apple App Store, 560,000 apps were added in the first half of 2026, almost as many as in all of 2025, according to TweakTown. More than 1.3 billion people now use AI in some form, roughly 15 percent of the global population, per DataReportal.
A meaningful share of those people have figured out that the same tool that writes an email can write a program.
The security picture has not kept pace. Apiiro found that AI coding assistants help developers produce four times as much code while introducing ten times the vulnerabilities. In testing reported by Help Net Security, 45 percent of code generated by large language models contained vulnerabilities matching the OWASP Top 10, the standard list of the most serious web application security risks.
Those numbers describe professional developers using these tools. The person in your accounting department is not a professional developer.
The three places it shows up in a small business
1. Credentials pasted into things that were never meant to hold them
This is the one I see most and it is the one that costs the most. To make a tool talk to your accounting software, your email, or your payment processor, it needs a key. The AI will happily write code that includes that key directly in the file.
That file then gets emailed to a coworker, saved to a shared drive, uploaded to a free hosting service so it can run somewhere, or pushed to a public code repository. The key goes with it. A key that reaches the public internet should be considered compromised within hours, not days.
2. Tools that quietly become load-bearing
A script someone wrote in an afternoon starts running your weekly invoicing. Nobody documented it. Nobody else knows how it works. Then that person leaves, or the script breaks on an edge case it was never designed for, and the business finds out how much it depended on something it never formally adopted.
This is not a security problem in the classic sense. It is a continuity problem, and it will hurt you sooner than a breach will.
3. Business data going somewhere you did not approve
To get useful output, people paste in what they have. Customer lists. Invoices. Patient names. Employee records. Depending on the tool and its settings, that data may be retained, used for training, or stored in a jurisdiction that matters for your compliance obligations.
Most people doing this have no idea it is a question worth asking.
A short policy you can adopt this week
You do not need a formal program. You need four rules that fit on one page and that people will actually follow.
Rule 1: Nothing that touches a customer, a payment, or a password goes live without a second set of eyes. Build whatever you want. Before it connects to a real system with real data, someone else looks at it.
Rule 2: Keys and passwords never go in the file. They belong in a password manager or in the environment the tool runs in. If your staff do not know what that means, that is the training gap to close first, and it is a thirty minute conversation.
Rule 3: Tell people what data is allowed to leave. Write down which categories of information may be pasted into an AI tool and which may not. Customer records, financial data, and anything covered by a regulation you are subject to should be on the “no” list unless you have specifically approved the tool.
Rule 4: Keep a list. One shared document with every AI-built tool in use, who made it, what it connects to, and what breaks if it stops working. This costs almost nothing and it is the single thing most likely to save you.
The checklist
Before an AI-built tool touches anything real:
- Does it store a key, token, or password anywhere in its own files?
- What systems can it reach, and what is the worst thing it could do to them?
- What data goes into it, and where does that data end up?
- Who besides its author understands it?
- What happens to the business if it stops working on a Tuesday?
- Is it running somewhere you control, or on a free service you have never evaluated?
If you cannot answer four of those six, the tool is not ready.
The honest version
Security has to become as accessible as building. The same agents that write the code need to audit it. Platforms hosting these tools need to scan them before they go live. And the person building an inventory tracker needs to understand that “it works” and “it is safe” are different claims.
None of this means stop. The productivity is real, and the small businesses that figure out how to do this safely will run circles around the ones that ban it outright and then discover their staff did it anyway without telling anyone.
It means slow down at exactly one point: the moment the tool stops being a toy and starts touching something that matters.
Where to go next
The free Small Business Security Checkup scores your Governance and Training practices along with five other areas, including whether you have clear rules for AI tools and unapproved cloud services. It runs in your browser, collects nothing, and gives you a report you can keep.
If you would rather talk it through, that is what IT Wes is here for.
For the longer argument behind this guide, see my articles The Democratization of Software and When AI Gets Hands.