We caught our own version of the Claude leak before it ever reached a practice

When we wrote about the hundreds of private Claude conversations that ended up on Google, our argument wasn't that Anthropic is careless. It's that consumer software ships with things switched on by default that nobody audits, until a researcher, a journalist, or a practice finds out the hard way. Writing that argument down is easy. Actually holding ourselves to it means going and checking.

So we did. Here's what we found, and why finding it is the point.

What we checked

Marling's chat interface is built on Open WebUI, a widely used open-source project. Like most software with a lot of features, it ships with things switched on by default that not every deployment should want. One of them is a "share to community" button: one click sends a full chat transcript to a public, third-party website, entirely outside the boundary where we detect and mask identifying details. It's the same shape of risk as the Claude story, a one-click action connected to a surface hosted by someone else.

We run this kind of audit routinely, on the internal development and test machines we build and break things on before anything reaches a practice. That's exactly where we found it: reachable, on every one of those machines, because it's the software's own default and nobody had explicitly turned it off. No customer device was ever running with this setting on. This never touched a practice, a patient, or a client file.

That's not luck. It's the reason internal machines exist separately from what ships.

Why this is the system working, not failing

A vendor that only ever points at other companies' incidents hasn't told you anything about what happens when a problem shows up in their own product. We'd rather be the vendor that actually looks, on a schedule, before anyone else has to ask.

Finding this cost us nothing but the time to look. Not finding it, and having a customer or a researcher find it instead, would have cost a great deal more. That trade is the entire argument for auditing your own product the way you'd audit a vendor's.

What we changed

We didn't stop at flipping a switch, because a one-time fix drifts back the moment someone toggles a setting in an admin panel or a device gets rebuilt. We treated it as a configuration-drift problem.

New deployments now ship with the setting off by default. For our existing internal fleet, we built a small tool that reads and corrects the setting through the software's own administrative interface, because our fleet runs two different versions of the underlying software with two incompatible ways of storing that setting, and a shortcut that worked for one silently failed on the other. That tool now runs automatically on every deployment and every feature install, not just once, so the setting can't quietly turn itself back on. We also added an automated test that fails outright if this setting is ever found on, so it's something our own build process checks by default, not something a person has to remember.

We verified it two ways: by reading the actual configuration back from every machine after applying the fix, not trusting the tool's own success message, and by deliberately forcing the setting back on in a test environment to confirm our new automated check actually catches it. Both passed, everywhere.

Why this is the advantage, not the caveat

This is only possible because of how Marling is built. We control every device end to end, so we can look for exactly this kind of thing, close it, and prove it stays closed. If this setting were buried in a cloud vendor's infrastructure instead, you'd have no way to check it, and honestly, neither would they until it was too late.

We'll keep running audits like this one, on a schedule, not just when something prompts us to. When we find something, we'll keep writing about it, the same way we did here.

If you want to know what else we've checked, or what we're checking next, ask us: hello@marling.io.