Are Vibe-Coded Apps Leaking Your Data?
The quiet problem
Building software has never been easier. A business analyst can describe an app over lunch and have it running by the afternoon.
That speed is real, and mostly good. But most of these apps share one trait: the author can't say where the customer data goes once it enters.
Not because they're careless. Because nobody asked them to know.
How the data gets out
Leakage into LLMs rarely looks like a breach. It looks like normal use.
- Prompts carry records. An app sends a full member or customer row to a model to "summarize" it. Account numbers ride along.
- Logs keep everything. Prompt and response logs land in a vendor console or a debug table nobody reviews.
- Keys sit in the code. API keys get hardcoded, committed and shared. Now anyone with the repo can call the model as you.
- Defaults go unread. Retention and training settings differ by tier and provider. The author picked the free one.
- Copies multiply. Exports, caches and vector stores hold the same data in places no inventory lists.
None of this needs a bad actor. It just needs nobody watching.
Nobody can trace the journey
Ask the author three questions. Where did this data come from? Where does it go next? Who else holds a copy?
Most can answer the first. Few can answer the second. Almost nobody can answer the third.
That gap matters most in regulated work. An examiner, an auditor or a member asking about their data doesn't accept "the app handles it." If you can't show the path, you can't defend it.
Start with the data model
You can't protect what you haven't named. A clear data model is the first control, not paperwork.
At minimum, every app touching customer data should answer:
- Which entities it holds (member, account, transaction)
- Which fields are sensitive, and how they're classified
- Which fields are allowed to leave, and to where
- Who owns each entity's definition
When that's written down, a developer can mask a field before it hits a prompt. When it isn't, every prompt is a judgment call made by whoever's typing.
See the whole fabric
A vibe-coded app is never alone. It pulls from the core, calls a SaaS tool, and writes back to something COTS. Each hop is a place data can slip.
| Layer | What it usually looks like | Where data slips |
|---|---|---|
| Internal IT | Core systems, data warehouse, custom apps | Extracts pulled into unvetted tools |
| SaaS | CRM, marketing, LLM APIs | Vendor retention, embedded AI features turned on by default |
| COTS | Packaged software run in-house or hosted | Integrations and exports nobody re-reviews after upgrades |
The app is the new piece. The fabric is the risk. Governing one without the other just moves the blind spot.
Apply the architect confidence model
Knowing a system exists isn't the same as understanding it. The honest question is how confident you are in what you know.
I solved this for SaaS and COTS years back by using an architect confidence model. Architects score that understanding for each part of the tech stack, on three measures from 0 to 4:
- Clarity: do we know what this system holds and does?
- Definition: are its data entities and sensitive fields named and owned?
- Semantic mapping: do we know how its data lines up with the rest of the fabric?
Scores roll up by weakest link, from component to capability to business goal. One poorly understood app pulls the whole capability down, which is exactly the risk a vibe-coded tool creates.
Take a common case. A team vibe-codes a customer onboarding assistant. It reads from the core, writes to the CRM, and sends applications to an LLM for summaries. The architect scores each piece:
| Component | Clarity (0–4) | Definition (0–4) | Semantic mapping (0–4) |
|---|---|---|---|
| Core system | 4 | 3 | 3 |
| CRM (SaaS) | 3 | 3 | 2 |
| Onboarding assistant (vibe-coded) | 2 | 1 | 0 |
| LLM API | 1 | 0 | 0 |
The core and CRM are well understood. The new app and the model call are not. Nobody named which fields go into the prompt, or mapped where the output lands.
Weakest link wins, so the onboarding capability scores 0. The model surfaces the leak risk before anyone has to find it the hard way.
When confidence is too low, the decision is forced to Map First: understand the data journey before you approve, invest in or retire anything. The Discovery Viewpoint is where that understanding gets captured and tested.
Every measure at 0/4. The guidance to the Decision Board is clear: map the data first. That's the right outcome for now, not approve or reject.
What to do Monday
- Inventory the apps. Ask teams what they've built or bought in the last year. Expect surprises.
- Map one journey. Pick the app with the most customer data. Trace it end to end, including every model call, then score how confident you are in that map.
- Publish a minimal data model. Name the sensitive fields and where they may go. One page beats none.
- Set model defaults centrally. Approved providers, approved tiers, no keys in code.
- Decide who decides. Every new app touching customer data needs a named approver and a recorded decision.
The tools will keep getting easier. The accountability won't. That part is still ours.
See where your institution stands.
The self-assessment places you across the six facets of decision governance — about six minutes.