Marling Blog

What actually leaves the building when you ask Marling a question

2026-08-20T00:00:00Z

Every practice that looks at Marling asks some version of the same question: if this thing uses Claude to do its thinking, doesn't a patient's name or a client's case file end up on someone else's server?

It's the right question, and it deserves a specific answer, not a reassurance. Here is exactly what happens.

The short version

Before a request leaves the device, names, record numbers, dates of birth, and other identifying details are found and replaced with placeholders. The cloud model never sees the real ones. When the answer comes back, the placeholders are swapped for the real values again, on the device, before anyone on your staff reads it. If that detection step can't run for any reason, the message doesn't go out at all.

That's the whole mechanism. The rest of this post is what's underneath it, and where its edges are.

How the detection actually works

Marling uses Presidio, an open-source identification engine originally built at Microsoft, running entirely on the device. It isn't a list of banned words. It combines pattern matching (a Social Security number has a shape; a phone number has a shape) with language models trained to recognize names, places, and organizations in context, the same way a person reading a sentence knows "Sarah" is a name without being told.

When your staff sends a message, that text is scanned first. Every match, a name, an address, a medical record number, a date of birth, gets replaced with a placeholder before the request ever reaches Claude or any other cloud model. The model does its reasoning against the placeholder version. When the response comes back, Marling swaps the placeholders back to the real values, on the device, so the draft your staff reads looks normal. The cloud provider never has both the content and the identity in the same place.

What happens when the safeguard can't run

A masking system is only as good as what happens when it fails. Marling's answer is the boring one on purpose: if the detection service is down, errors, or can't confirm the text is clean, the message does not send. No fallback, no "send anyway" option, no silent pass-through. The failure mode is a staff member has to try again in a minute, not a name reaching a server it shouldn't.

What never leaves at all

Some of what Marling does doesn't touch this pipeline, because it never needs to. When your staff asks a question against your own uploaded documents, that search and retrieval happens on the device itself. It was never going to leave the building, so there's nothing to mask and nothing to send.

The exceptions, and why they exist carefully

Not every identifier should be hidden. A practice's own name, its office phone number, a room number, these usually aren't sensitive, and masking them by default makes responses harder to read for no privacy benefit. An admin can declare specific exceptions on the device.

That feature is deliberately narrow. Exceptions are exact phrases, not patterns, because a pattern that matches a few names matches every name, including a patient's. Anything that looks like it could expose more than the admin intended is refused outright, and the refusal says what it would have exposed. This is the kind of thing that's easy to get quietly wrong, so it's built to fail toward masking more, not less, whenever something is ambiguous.

The honest caveat

Masking covers the completion path, the traffic that goes to a cloud model to do the reasoning work. It is not a claim that nothing can ever go wrong. A staff member can still misread a redacted draft, still paste something into the wrong window, still take a screenshot. No architecture removes human judgment from the picture, and we're not going to tell you it does.

What it does mean is specific and verifiable: the text a cloud provider sees, on the path that does the heavy lifting, doesn't carry the identifiers that would make an exposure a breach instead of a non-event. That's a narrower promise than "your data is safe." It's also one we can actually stand behind.

If you want to see it, not just read about it

We're working with a small group of founding design partners who use Marling in their real practice and tell us what to fix. If you'd rather watch how the masking behaves on your own documents than take our word for it, we'd like to hear from you: hello@marling.io.

Hundreds of private AI chats just showed up on Google

2026-08-15T00:00:00Z

In late July, Reddit users noticed something unsettling: typing a simple search operator into Google surfaced page after page of other people's conversations with Claude, Anthropic's AI assistant. Wired, Fortune, and TechCrunch each dug through the results and found a detailed medical report on a named patient, clinical trial results listing patient names, documents containing the names and phone numbers of primary-school-aged children, a crypto wallet's keys, and, in a case that will make any practitioner wince, a lawyer asking the chatbot whether they had to self-report a breach of professional conduct.

Nobody was hacked. That's the part worth sitting with.

What actually happened

Claude, like most consumer AI tools, has a share button. Click it, and the tool creates a public web link: a snapshot of your conversation you can send to a colleague. The interface warns that "anyone with the link can view" the chat.

What it doesn't say is what "anyone" means on the open internet. A public URL with no instruction telling search engines to stay away is a page like any other. Post it in a forum, a Slack channel that gets archived, a shared doc, anywhere a crawler can see it, and Google will index it. So it did, for hundreds of conversations.

Anthropic's response was, essentially, that the feature worked as designed: users chose to make those chats public. And they're not wrong. This isn't a story about one careless vendor. OpenAI went through a nearly identical episode with ChatGPT's shared links, and so did xAI's Grok. It's a story about what consumer AI tools are: websites, where your conversations live on someone else's servers, one click away from the public web.

For most people, that's a manageable risk. For a practice that handles client files, patient records, or privileged questions, it's a different calculation entirely. The people whose medical reports showed up in those search results almost certainly thought they were sharing a link with one colleague. The gap between what they intended and what they did was invisible until it wasn't.

Why this failure mode doesn't exist on a Marling device

Marling is a small device that sits on your office network. Your staff open a chat window in their browser and work the way they would with any AI assistant. But the architecture underneath is different in ways that matter for exactly this scenario.

There is no public link to leak. Marling isn't a website. It runs on the device in your office, reachable only from your own network. When someone on your team shares a conversation, the link they share only works for people who can already reach the device, meaning people inside your practice. There's no public snapshot on the open internet, so there's nothing for Google to crawl, nothing to index, nothing to stumble across. The entire category of "shared chat ends up in search results" has no equivalent here.

Identifiers are stripped out of anything that goes to a cloud model. Marling still uses frontier models, including Claude, to do the heavy lifting. But before a request leaves the device for one of those models, names, record numbers, and other identifiers are detected and masked on the device itself, then restored in your finished draft. If the masking can't run, the message doesn't send. The work that doesn't need a frontier model, like searching your own uploaded documents, is handled on the device and never leaves at all. So the traffic that does reach a cloud provider doesn't carry the details that made those leaked chats so damaging. A medical summary without a patient's name in it is a very different thing to expose than one with it.

One person's slip isn't a silent one. In a consumer tool, every staff member has their own account, their own sharing settings, their own habits, and you have no visibility into any of it. Security researchers have a name for this: shadow AI. Marling is one shared, governed device for the whole office, with roles and an audit trail. The tool your team actually uses is the one you can actually see.

The honest caveat

No system makes data leaks impossible, and anyone who tells you otherwise is selling something. A screenshot can always be emailed; a draft can always be pasted somewhere it shouldn't go. What architecture can do is remove the traps: the innocent-looking share buttons whose consequences only become clear when your client's file is on page two of a Google search.

That's the standard we think tools for regulated work should meet: not "be careful," but "the careless path doesn't lead anywhere dangerous." It's also a standard we hold ourselves to: while writing this piece, we went and audited our own product for the same shape of risk, on the internal machines we test on before anything reaches a practice. Here's what that audit caught, before it ever became anyone's problem.

If this is the anxiety you've been carrying

You're probably already using AI in your practice, quietly, and holding back the real work because of exactly this kind of story. That instinct is correct, and it's also why we're building Marling. We're currently working with a small group of founding design partners who use it in their real work and tell us what helps.

If that sounds like you, we'd like to hear from you: hello@marling.io.

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

2026-08-15T00:00:00Z

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.