What leaves the device when you ask a question

Every business 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 customer’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 works on the placeholders. 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 gets the content with the identifiers it can detect removed.

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 stays on the device

When your staff asks a question against your own uploaded documents, the search itself runs on the device. When an answer draws on a document, only the passage it needs goes out, with identifiers removed first. The file stays on the device.

The exceptions, and why they exist carefully

Not every identifier should be hidden. A business’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.

Detection is automated, and it can miss. In our tests on deliberately awkward text, it hides about 96% of names as standard and about 99% once a business’s customer list is loaded. It is most likely to miss a surname standing on its own, for example in a file name, a spreadsheet row or a line copied from another system, so check text like that before you paste it.

What it does mean is specific and verifiable: the text a cloud provider sees, on the path that does the heavy lifting, has the identifiers the device detects removed before it leaves. 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 building Marling with our first founding customers, and we’re looking for more. 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.