Vibe-Coded It? Here’s the Checklist Before It Touches Customer Data
You asked Claude to build you a booking form. Or a customer portal. Or a simple app to manage your job quotes. It worked. Clients can log in, see their stuff, submit requests. You shipped it.
Now: do you know where their passwords are stored? Who can see the database? What happens if the server goes down tonight?
Vibe coding, building apps and websites by chatting with AI tools like Claude or ChatGPT, has put real software in the hands of people who’ve never written a line of code. That’s genuinely useful. It’s also created a wave of small business apps handling customer data with the security posture of a sticky note.
A 2026 GitGuardian report found that Claude Code-assisted commits exposed hardcoded secrets (API keys, passwords, database credentials) more than twice as often as human-written code. A separate analysis found that AI-assisted teams were shipping code four times faster, and ten times as many security flaws. And last year, Football Australia left AWS access keys sitting in their website’s source code for over 700 days before anyone caught it.
If your AI-built app touches customer names, emails, phone numbers, payment details, or booking history, you need to run this checklist. Not because you’re paranoid, because the Privacy Act is no longer just for big companies.
The Privacy Act angle you probably missed
From 1 July 2026, a large group of small businesses that previously sat under the $3 million turnover exemption have been pulled into the Privacy Act. Real estate agents, accountants, conveyancers, and lawyers are now covered regardless of size. And the government has agreed in-principle to remove the small business exemption altogether, which would catch the roughly 2.3 million businesses currently sitting outside it.
From 10 December 2026, any business using AI or automated systems to make decisions about customers must say so in their privacy policy and explain how it works. If your AI-built app makes decisions that affect people, who gets a quote, who gets approved, who gets flagged, that’s an automated decision, and silence about it is a compliance failure.
Get this wrong and you’re looking at civil penalties starting at $62,600 per offence, scaling to $50 million or 30% of annual turnover for serious breaches. The OAIC is currently running a privacy policy compliance sweep. They’re checking whether what your policy says matches what you actually do.
The checklist
1. Check how passwords are stored
Open your codebase (or paste it into Claude) and ask: “Are passwords stored as plain text or using a weak hash like MD5?” Passwords should be hashed with bcrypt, argon2, or scrypt, full stop. If your AI-built app is storing plain-text passwords in a database, anyone who gets access to that database has everyone’s credentials. This is the one that gets businesses sued.
2. Hunt for hardcoded secrets
Search your code for strings like api_key =, password =, SECRET, TOKEN. AI coding tools have a well-documented habit of hardcoding credentials directly into source files instead of pulling them from environment variables. A 2026 scan of 500,000 code samples found over 400 exposed API keys and access tokens in vibe-coded repositories. Credentials hardcoded into code get committed to version control and stay there, often for years, even after you think you’ve fixed it.
3. Test your login flow end-to-end
Can you access admin pages without being logged in? Try it. Paste your app’s admin URL directly into a browser that’s not logged in. One of the documented vibe coding incidents of 2025 was a platform where the authentication check had inverted logic, logged-out users got access, logged-in users got blocked. AI doesn’t unit-test its own output. You have to.
4. Check what your database exposes by default
If you’re using Supabase, Firebase, or any cloud database, check your Row Level Security settings. The Moltbook incident, 1.5 million API keys exposed, came from missing RLS on a Supabase project that an AI tool set up. Cloud databases often default to “open” for development convenience. That setting doesn’t change itself when you go live.
5. Verify your privacy policy actually describes what you do
If your AI-built site has a contact form, a booking system, or any login, you’re collecting personal information. Your privacy policy needs to describe what you collect, why, where it’s stored, and how people can request deletion. “We take your privacy seriously” is not a privacy policy. The OAIC is comparing what policies say against what businesses actually do. Fix the gap before they find it.
6. Confirm backups exist and test one
Ask your hosting provider: what’s the backup schedule? Where are backups stored? How do you restore? Many AI-generated deployment setups skip backup configuration entirely. If your server dies tonight, could you be back up by morning? If you don’t know the answer, the answer is probably no.
7. Lock down who can access the admin panel
Your WordPress dashboard, your app’s admin section, your database console, who has credentials? Check for accounts created during testing that were never removed. Change default admin usernames. Turn on two-factor authentication for anything that gives access to customer data. This takes 20 minutes and stops the most common attacks cold.
8. Set up basic monitoring
You want to know when your app goes down, when logins fail repeatedly (a sign of a brute-force attack), and when large amounts of data are being exported. Free tools like UptimeRobot handle the uptime side. Most cloud providers have logging built in, you just need to turn it on and know where to look.
9. Add a data retention policy
The Privacy Act requires you to destroy or de-identify personal information you no longer need. If your app has been running for a year and you’ve got customer records from people who haven’t been back in 11 months, when do you delete them? Write down the answer. That’s your data retention policy. Put it in your privacy policy too.
The weekly caretaker routine (30 minutes, every Friday)
Security isn’t a one-time audit. These checks take half an hour a week and catch 80% of problems before they become incidents:
- Check failed login attempts, a sudden spike means someone’s trying to get in
- Verify backups ran, most failures are silent until you need a restore
- Review new user accounts, look for anything created that you don’t recognise
- Check for software updates, plugins, dependencies, packages; update anything with a security patch
- Scan for exposed files, try accessing
yourdomain.com/.envandyourdomain.com/config.phpin a browser; if you can read them, so can anyone else
Set a recurring calendar block. Call it “site caretaker.” Do it before you knock off for the week.
📖 More deep dives: News Deep Dives
📊 Compare AI tools side by side | 💼 Free resources & AI prompt packs
