Your Website Doesn’t Care That AI Built It

Using AI for your small business or non-profit site is fine. Shipping it without a second set of eyes is where people get hurt.

I build with AI all the time. I lean on it for music, for automations, for the boring scaffolding that used to eat my evenings. So this isn’t a “stop using AI” lecture. It’s the opposite. AI is one of the best things to happen to a small business or non-profit that can’t afford a developer on staff.

But I’ve also been the person standing in the smoking crater after something went wrong on a live site. I’ve rolled out web application firewalls, rotated credentials that leaked, and gone line by line through code looking for the password somebody left sitting in plain text. And I can tell you the gap that gets people isn’t between “good people” and “careless people.” It’s between it works and it’s safe. Those are two different things, and AI is fantastic at the first one while staying completely silent about the second.

The quiet way trouble gets in

Here’s the pattern. Someone on your team — maybe you — wants a contact form, or a chatbot, or a quick automation that pushes new sign-ups into your email list. They ask an AI tool. The AI delivers something that works on the first try. It goes live. Everyone’s thrilled.

What nobody clocked is that the form now writes to a database with no access controls, or the chatbot widget phones home to a service nobody vetted, or the automation quietly wired your member list to a third party. Each piece felt like a small win. Each one is also a door you didn’t know you left open.

This isn’t me being dramatic. BleepingComputer ran a piece this month — sponsored by the automation platform Tines — covering a panel of security leaders from Jamf, ASOS, and Datadog on exactly this problem. They cited a scan from a firm called RedAccess that found roughly 380,000 publicly accessible assets built on popular “vibe coding” platforms with no security review behind them. Around 5,000 of those were leaking sensitive corporate information. That’s not a hypothetical. That’s stuff sitting open on the internet right now because somebody shipped what worked and never asked what it touched.

Why “just ban it” never works

The instinct, especially at a non-profit board level, is to write a policy. No AI tools without approval. Done. Except it isn’t done, because that’s not how people behave. One of the panelists put it bluntly: employees trying to get their job done are the most persistent threat you have, not because they’re malicious, but because they will route around any obstacle you put between them and finishing their work. Block the obvious tool and they’ll find a quieter one you can’t see at all.

Their better answer, and it’s the one I keep coming back to: make the safe path the easy path. Don’t be the gatekeeper everyone sneaks past. Be the hub everyone actually wants to use because it’s less hassle than going rogue. For a small org, that doesn’t mean a security department. It means a short, sane set of habits that take less effort than cleaning up a breach.

Five checks that fit on an index card

1. Someone who didn’t build it looks at it before it goes live. The builder is the worst person to catch the builder’s blind spots. This is the single highest-leverage habit on the list, and it costs you one conversation. Even a knowledgeable friend or a consultant doing a one-hour review beats nobody.

2. Know what data your site actually touches. Names, emails, donor records, payment info, member health details — write down what flows through your site and where it lands. The security folks call this data classification. You can call it “knowing what you’d have to apologize for if it leaked.” Anything with personal info is the high-stakes pile. Treat it that way.

3. Don’t connect what you can’t explain. Every plugin, widget, and integration is a relationship with someone else’s code. If you can’t say in one sentence what it does and why it’s worth the access it’s asking for, it doesn’t earn a spot.

4. Keep a one-line list of what you’ve added. The ASOS leader called this a use-case registry. For you it’s a spreadsheet, honestly — one row per AI-built thing: what it is, who made it, what it’s for, what data it sees. When something breaks, you can trace it back to a person and a purpose instead of staring at a mystery.

5. Hunt for the secret hiding in the code. This is the one that bites hardest. AI tools love to leave API keys, passwords, and access tokens sitting right in the code where anyone who views the source can grab them. Before anything ships, search it for the obvious words — key, secret, password, token. If you find one in plain text, stop and fix it before you do anything else.

The point isn’t fear

I want you using these tools. A non-profit that builds its own donor thank-you automation instead of paying for an enterprise suite is doing something genuinely good with limited money. A small business that spins up a smart contact form over a weekend is exactly the kind of scrappy I respect.

The only thing I’m asking is that you put one thin layer of judgment between “the AI made it” and “it’s live and handling real people’s information.” That layer is cheap. The alternative shows up as 5,000 exposed databases in a security report, and you do not want your org to be a line item in next year’s version of that number.

Source: Figures and panelist insights referenced here are drawn from “Vibe coders are gonna vibe code: How CISOs are tackling code sprawl,” published by BleepingComputer on June 15, 2026 (sponsored content by Tines), featuring Mario Villatoro of Jamf, Indu Sajeev formerly of ASOS, and Matt Muller of Datadog. The 380,000 exposed-asset figure is attributed in that article to a report from RedAccess. All commentary, framing, and recommendations above are my own.