The appointment

The story starts the way the worst ones do: with someone enthusiastic. Swiss engineer Tobias Brunner, writing on his blog tobru.ch in late March 2026, recounts going to a medical appointment where a staff member mentioned, more or less in passing, that they had watched a video about how easy it is to build software with AI now. The practice had decided not to buy one of the proven, boring, regulated patient-management systems that exist precisely because patient data is sensitive and heavily governed. Instead, someone at the practice had used an AI coding agent to build their own.

They built a custom patient-management web app. They imported their existing patient records into it. They added a feature to record conversations during appointments and send the audio off to AI services for automatic transcription and summaries. And then they put the whole thing on the public internet, where Brunner - a security professional who happened to be a patient - could reach it.

He looked. It did not take long.

Thirty minutes to everything

Within roughly half an hour, Brunner had full read and write access to every patient record in the system. Not "found a worrying misconfiguration." Full read and write access to all of it.

The reasons read like a checklist of every foundational web-security control, each one absent:

• The whole app was effectively one client-side file. Structure, styling, and logic all lived in JavaScript that runs in the visitor's browser. There was no meaningful server-side application enforcing anything.
• All access control was client-side. The checks that were supposed to decide who could see what ran in the browser - which means the user controls them. Anyone can open developer tools and ignore a rule that exists only in code running on their own machine. Client-side authorization is not authorization; it is a polite request.
• The backend database had no access control configured at all. No row-level security, the per-record permission model that decides which user may touch which row. Nothing. Brunner's description was that the data was "literally one curl command away from anyone" - meaning a single command-line HTTP request, no login required, returned the records.
• The data was unencrypted and openly exposed on the internet. No encryption at rest protecting it, and nothing in front of the database restricting who could connect.
• Patient voice recordings were sent to US-based AI APIs. The appointment-audio feature shipped recordings of medical conversations to major US AI providers, with - as far as Brunner could determine - no data-processing agreement governing that transfer and no consent obtained from the patients whose voices and medical conversations were being uploaded.

This is the same architectural failure mode the Vibe Graveyard has now catalogued many times over - authorization that exists only in client-side code, a database open to the internet, secrets and access sitting in the front end - but pointed at the one category of data where it is hard to imagine a worse target. EnrichLead (zero hand-written code) lost a sales-lead app the same way. Lovable's BOLA flaw (48 days exposed) exposed project source and credentials. The difference is the payload. Here the payload is people's medical histories.

The legal cliff

Brunner is careful to say he is not a lawyer. The exposure he describes does not require one to see the problem.

Switzerland's revised Federal Act on Data Protection - the nDSG, in force since September 2023 - treats health data as a special, more strongly protected category and requires appropriate technical and organizational security for personal data. "All records readable and writable by anyone with a curl command" is the textbook example of the security that act requires not existing. On top of the data-protection regime, Swiss medical practitioners are bound by professional secrecy rules (Berufsgeheimnis), the medical-confidentiality obligation that long predates any data-protection statute. A patient-management system that any stranger can read straight off the internet is difficult to square with a legal duty to keep patient information confidential.

Then there is the cross-border transfer. Sending identifiable patient audio - recordings of medical consultations - to AI APIs hosted in the United States, with no data-processing agreement in place and without informing or getting consent from the patients, stacks a separate set of violations on top of the storage problem. Brunner notes the data was on a US server with no such agreement, and that he had never been told any of this was happening to his own data. As a patient, he found out by poking at the app.

The response that wrote itself

Brunner did the responsible thing and notified the practitioner immediately. The reply he got was, in his telling, 100% AI-generated: a warm note thanking him for the report and assuring him that action had been taken right away - specifically, that they had added basic authentication and rotated some access keys.

Sit with that. The system was built by an AI agent. When a vulnerability report came in, it was apparently handed back to an AI to draft the response. And the "fix" - bolting basic authentication onto the front - addresses the doorbell while leaving the back wall missing. Basic auth in front of a single-page app does not retroactively give the database row-level security, does not encrypt the data at rest, does not establish a data-processing agreement with the US AI provider, and does not obtain the patient consent that was never there. It makes the front door require a password. The data architecture underneath - the part that made "one curl command away" possible - is a separate problem that a login prompt does not touch, and it is not clear from the account that it was addressed at all.

This is the loop that makes vibe-coded systems so hard to remediate: the person operating the agent does not have the mental model to know whether a fix is real, and the agent will happily generate a confident-sounding fix and a confident-sounding email about it either way. When you cannot read the code, you cannot tell the difference between "patched" and "told you it was patched."

The chorus

Brunner's writeup reached the front page of Hacker News - 213 points and more than 200 comments - and the comments are as damning as the post. They were not skeptics demanding proof. They were other people describing the same thing they had personally run into.

One commenter described reporting a vibe-coded CRM at an insurance company to Spain's data-protection authority after getting threats for trying to disclose the flaw responsibly. Another described a surgeon's vibe-coded web app that left database backups and credentials sitting in a web-accessible directory you could simply browse. Another mentioned an accounting firm building its client CRM on an AI app-builder with no technical staff in the building. These are unverified anecdotes, individually, but the volume and the consistency are the point: Brunner did not find a freak. He found an instance of a pattern, and a roomful of strangers immediately recognised it.

That pattern was independently quantified around the same period. Israeli firm Red Access reported finding roughly 380,000 publicly accessible AI-generated apps, of which several thousand were leaking potentially sensitive data including medical records and clinical details (380k exposure study). Brunner's account is one human-scale version of that statistic - a single practice, a single afternoon's poking - with the consequences spelled out in full.

What it teaches

The seductive promise of an AI coding agent is that anyone can now build the software they need without learning to build software. For a personal to-do list, fine. For a system holding identifiable medical records and recordings of consultations, the gap between "I can make it work" and "I can make it safe" is the entire discipline of secure software engineering - access control, encryption, data residency, consent, the legal regime around health data - and an agent that cheerfully ships a working app does not close that gap. It hides it. The app works. The demo is impressive. The records are also on the open internet, and the person who built it has no way to know that, because knowing that was the expertise they were promised they no longer needed.

There is no evidence in the account that a malicious third party actually downloaded the records and did something with them. What is documented is that the exposure was trivial, that a security researcher demonstrated full access in half an hour, and that the data sat reachable on the public internet for an unknown period. That is exposure and a near-certain regulatory breach, not a confirmed exploited breach. With sensitive health data, exposure of this kind is severe on its own terms - you do not get to wait for proof of harm before treating "anyone could read every patient record" as a catastrophe.

Sourcing

The victim is deliberately unnamed - Brunner withholds the practice's identity, reasonably, for the patients' sake and to avoid pointing attackers at a live target. That means this rests on a single named-researcher primary source, Brunner's own writeup, plus the corroborating community reports in the Hacker News thread. It has not been confirmed by a regulator, a court, or an independent outlet, and by design it likely never will be in a way that names the practice. Brunner is a credible, identifiable security professional describing his own firsthand experience in technical detail, and the Hacker News response shows the failure mode is common rather than exotic. Read this as a well-documented hazard and a representative case, not as an adjudicated incident.