Is Your Insurance Agency's Vibe Coded Website Leaking Data?

The shortcut that's tempting right now

AEP is three weeks out, your marketing budget already went to ads, and someone on your team just watched a video of a stranger building a working app in four minutes by typing into a chat box. It's a real capability, not a trick. You can describe a quote form, a client portal, or a referral tracker, and watch it get built in front of you, for free or for a handful of dollars a month. Compared to a multi week build with a developer, or a monthly retainer, the chat box looks like the obvious move.

That instinct isn't wrong about the technology. It's wrong about what the technology is actually handing you when it finishes. A finished looking app and a safe app are not the same claim, and the gap between them is exactly where the research below sits.

What's actually running behind the screen

"Vibe coding" is the practical term for building software by describing what you want in plain language and letting an AI assistant write and run the code. Lovable, one of the larger tools in this category, describes its own output plainly in its documentation: it creates "a working application that includes frontend, backend, database, authentication, and integrations," all backed by editable code.¹ That's not a static page. It's a full application stack, generated in one pass, usually by someone who isn't reading the code it produces.

That matters because of what each of those four pieces means in practice. The frontend is what a visitor sees. The backend and database are where the actual data lives, every name, phone number, and answer a form collects. Authentication decides who's allowed to see it. When a human developer builds this stack by hand, each piece gets reviewed before it ships, and the database's access rules get set on purpose. When a chat prompt generates all four at once, the access rules are whatever the tool's default happened to be, and the only check on that default is whoever was chatting, usually once, usually under deadline, usually not a security engineer.

The database layer is the part worth sitting with. Modern app builders typically wire the generated backend to a managed database service, the kind that ships with "row level security," a setting that controls which rows of a table a given visitor is allowed to read or write. Row level security has to be configured. It isn't automatically locked down the moment a table exists, and a tool optimized to get you to a working demo as fast as possible has every incentive to leave that step for later, because a demo that works feels like success even when the data behind it is sitting wide open.

Why the code is usually insecure by default

This isn't a knock on any one platform. It's measured, repeatedly, across the entire category. Veracode's 2026 GenAI Code Security Report, published July 28, 2026, is the clearest single data point: testing code generation tasks across more than 100 large language models, the company found an average security pass rate of 56%, "barely changed from 55% in the first report."² Put plainly, 44% of the code these models generated contained a detectable, exploitable vulnerability, and that rate hasn't moved in a year of model improvements. The pass rate wasn't even across vulnerability types. Cryptographic implementations passed 87% of the time and SQL injection defenses passed 83% of the time, both reasonably strong. Cross site scripting passed only 15% of the time, and log injection only 12%, meaning those two categories failed in the large majority of tasks tested.²

GitGuardian's research looks at a different layer of the same problem: not whether the logic is secure, but whether the credentials the code needs to run, API keys, database passwords, tokens, end up exposed in plain text. The company's fifth annual State of Secrets Sprawl report found 28,649,024 new hardcoded secrets added to public GitHub commits in 2025 alone, a 34% increase over 2024 and the largest single year jump the company has recorded.³ The AI specific finding is the sharper one: commits made with AI coding assistants leak secrets at roughly twice the rate of the GitHub wide baseline, and credentials tied specifically to AI services were exposed 1,275,105 times, up 81% year over year.³ An assistant that writes fast, working code has no built in reason to also remember that a key belongs in an environment variable instead of directly in the file it just generated.

It helps to know why those two categories specifically fail so often. A model generating a contact form or a quote request page is optimizing for one thing: does the form submit and does the data show up where it's supposed to. Cross site scripting happens when user submitted text gets displayed back on a page without being neutralized first, so a malicious script typed into a name field runs in another visitor's browser instead of showing up as plain text. Log injection is the same idea applied to a server's internal logs. Neither failure stops the form from working in a quick test. The page still submits, the email still arrives, the demo still looks finished. The flaw only shows up when someone deliberately tries to break it, which is exactly the step a chat prompt has no reason to take on its own and a rushed human reviewer, if there even is one, is the most likely step to get skipped.

What's already happened to other builders

None of this is theoretical. Escape, an application security research firm, published a methodology study on October 29, 2025, describing a scan of 5,600 publicly available apps built on five vibe coding platforms, Lovable, Base44, Create.xyz, Vibe Studio, and Bolt.new.⁴ Across 14,600 total assets, the scan found more than 2,000 vulnerabilities, more than 400 exposed secrets, and 175 separate instances of exposed personally identifiable information, including medical records, IBANs, phone numbers, and email addresses.⁴ The researchers describe these numbers as a conservative lower bound, since the scan ran in passive mode rather than actively probing every endpoint it found.

What ties these numbers together isn't that any one of them is catastrophic by itself. It's that they describe the same mechanism from four different angles: the code that gets generated commonly has a flaw (Veracode), the credentials it needs commonly leak (GitGuardian), the databases it creates commonly ship open (Escape), and when any of that turns into an actual breach, the average cost is higher than it's ever been measured.⁵ IBM and the Ponemon Institute's 2026 Cost of a Data Breach Report puts the global average cost of a breach at $4.99 million, a 12% increase over the prior year and a record high, driven in part by higher detection, escalation, and lost business costs.⁵ That figure covers breaches of every kind, not only ones that started with a vibe coded app, but it's the number that gives the other three their stakes.

If you're an FMO or IMO running several agencies under one umbrella, this risk doesn't stay contained to whoever built the tool. A single downline agent chat prompting a lead capture page for their own book, without telling anyone above them, is exactly the pattern security researchers call "shadow AI," software built and deployed outside any formal review, often by someone with no reason to think they've done anything risky. The tool works, it collects leads, and it keeps running quietly until someone finds it the hard way. An agency's own website being built correctly doesn't protect against a downline office doing this independently, which is one more reason a quick, periodic check across every site in a network is worth the hour it takes.

The specific risk when client data is involved

For most small businesses, an exposed database is a privacy and reputation problem. For an insurance agency, it can also be a HIPAA problem, and that changes the legal footing entirely. Under 45 CFR 164.502(e), a covered entity, which includes an agency handling health related client information, may disclose protected health information to a business associate and allow it to handle that information only after obtaining "satisfactory assurance that the business associate will appropriately safeguard the information."⁶ That assurance has to be "documented through a written contract or other written agreement," what the industry shorthand calls a Business Associate Agreement.⁶

Here's the practical question that rule creates: does the chat based app builder your assistant used last week publish a Business Associate Agreement that covers a live, client facing application collecting health or coverage information? If you don't know the answer, you don't have a BAA, and if you don't have a BAA, that tool has no business ever touching a real client's health information, regardless of how well its database rules are configured. A locked down database solves the security problem. It does not solve the contractual requirement, and an agency that skips this question isn't taking on vague risk, it's operating outside a specific, named federal rule.

How to check your own site in ten minutes

You don't need to hire anyone to find out whether a tool your agency is using, or considering, has an open database. Here's the actual method, the same kind of check a security researcher runs first.

1. Open developer tools and watch the network traffic

In Chrome or Edge, right click the page and choose Inspect, then open the Network tab. Reload the page. Look through the requests for a domain you don't recognize, especially one ending in a managed backend service's domain, such as supabase.co or firebaseio.com. That request is the app talking to its database.

2. Open that request's URL directly

Copy the full request URL into a new browser tab. If the access rules are configured correctly, you should get an authorization error or an empty, permission denied response. If you instead see actual rows of data, names, emails, form submissions, the table is open to anyone who finds that URL, no login required.

3. Check whether a BAA exists, in writing, before any client health data goes in

Email or chat with the platform's support and ask directly whether they offer a Business Associate Agreement for your plan. If the answer is no, or it's unclear, treat that as a firm no for any tool that will touch protected health information, regardless of how the database check above comes out.

4. Run your page through PageSpeed Insights

Page speed isn't a security check, but it's a five minute way to see how much of the page's load is the generated app's own runtime versus actual content, and it tells you whether the tool is costing you visitors before the security question even matters.

How we build it differently

We build insurance agency websites on Astro, which ships zero JavaScript to the browser by default and renders server first, letting a page opt into client side code only where it's actually needed.⁷ That's the opposite architecture from a vibe coded app. There's no live database sitting behind your public marketing pages for a stranger's URL guess to reach, because the pages are prebuilt HTML, not a running application waiting for a request. Where a site genuinely needs a database, a real quoting tool pulling live federal rate data, a lead form, a client portal, that piece is built and reviewed on purpose, with access rules set before anything goes live, not left on whatever default a chat prompt happened to produce.

Our builds score 90+ on Lighthouse performance on both mobile and desktop, and a number of pages score 100, built to clear Google's own Core Web Vitals thresholds of 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint, and 0.1 for Cumulative Layout Shift, measured at the 75th percentile of page loads.⁸ That's achievable because the page that ships is the finished page, not a framework booting up in the visitor's browser. Every build also ships a schema stack built to match what's on the page, and llms.txt, sitemap.xml, and robots.txt that regenerate themselves with the full URL the moment a new page publishes.

On the compliance side specifically, anything we build that touches real client data runs through infrastructure covered by a signed Business Associate Agreement, on your own AWS or Azure account rather than a shared backend with access rules we didn't choose. That's not a feature we bolted on. It's the baseline requirement for building anything an insurance agency can legally put a client's information into. Per the live pricing page, verified today, Digital Foundation starts at $84 a month, billed annually, for the website itself, with Starter, Pro and Scale adding a monthly, weekly or daily publishing cadence on top; anything beyond the standard build that touches client data gets scoped under a signed BAA as part of that project.⁹

What changes for your agency

The point of fixing this isn't a vague sense of being more secure. It's specific things that stop being true about your site.

When vibe coding is actually fine

None of this means the tools are bad or that you should never touch one. For a genuinely low stakes job, a quick internal calculator only you use, a mockup to show a designer what you mean, a one off script that never sees a client's name, vibe coding is often the fastest, most reasonable way to get it done, and the security research above doesn't really apply, because there's no sensitive data in the loop for a default access rule to expose.

The line is simple to draw even if it's easy to cross by accident: the moment a tool collects a client's name, phone number, date of birth, or anything health or payment related, or represents your agency to the public, it has moved into the exact profile Escape, GitGuardian, and Veracode's research describes. At that point, the ten minute check above isn't optional caution, it's the minimum before that tool goes live.

Questions agencies ask