What actually leaves the building when you ask Marling a question

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.