DLP for LLMs: How to Hide Employee Names from an External Model Without Breaking Search

What happens to enterprise search when employee names have to be hidden from an external LLM? Replacing surnames with random placeholders protects the data but breaks the link between the request, the documents it finds, and the model's response. Here's how to reconcile privacy and usefulness: where to keep the mapping, why you need entity resolution, how the policy engine makes decisions, and why you have to check the model's response, not just the incoming prompt.

Companies are connecting AI assistants to internal data: Jira tasks, wikis, meeting notes. That data is full of names of colleagues, clients, and contractors. Under the GDPR, these are personal data. Sending them to an external model means processing them, and if the provider is outside the European Economic Area, it also means transferring them to a third country.

The simplest fix is to replace names with placeholders before a request goes to an external model. But imagine an employee writes: "find van Dijk's latest tasks on project X and compare them with the meeting discussions." If van Dijk becomes NAME_1 here and a random NAME_7 in the next message, search no longer understands that this is the same person. If the name stays as it is, it may leave the trust boundary. Privacy and usefulness end up in conflict.

When usefulness loses that conflict, employees don't stop using AI. They switch to personal tools: according to Microsoft and LinkedIn, 78% of people who use AI at work bring their own AI tools.^source The same names end up there, with no filter at all.

At Imaga, we're building an internal layer that our employees go through to work with LLMs and agents. One of the nastiest problems in a layer like this isn't just hiding a name or a phone number before a request goes to an external model. It's keeping the request's meaning.

This article covers an architectural approach that helps reconcile these requirements: the entity mapping is stored inside the trust boundary, and the model receives only a typed pseudonym.

Why does replacing names with NAME_1 break enterprise search?

A naive scheme with NAME_1-style placeholders has two flaws.

The first is local numbering. A number is usually assigned by position within a specific message. In the next request, the same person gets a different placeholder, and in a long conversation you easily end up with two entities that play the same role and carry different numbers.

The second is the loss of type and relationships. To an LLM, the string NAME_1 says almost nothing. A phone number, a surname, an organization, and a login all turn into identical chunks of text. The model can continue the sentence, but it's worse at matching the entity to search data and doesn't understand which operations are allowed.

So it helps to separate two tasks:

This resembles a foreign key in a database. A foreign key doesn't reveal the whole record, but it lets you join tables. The difference is that in our case, the key must not be handed to the user or the model as a way to recover the original value.

How does an LLM gateway with PII masking work?

Our internal layer works as a gateway in front of the LLM: a request goes through authorization, a DLP check, and a de-identifier, and is then sent to the provider. On the way back, the response goes through controlled rehydration, where the original values are put back in place of the tokens. The user's identity is passed in a service header and through proxy permissions, not in text that the model can read or tamper with.

The simplified path looks like this:

Define the trust boundary and deny the model access to the mapping; we'll cover how the mapping is stored below. Keep detection, entity resolution, the policy engine, and rehydration separate, and tag every detector signal with its source: regex, NER, a PII model, a decoder, or a rule.

How do you resolve van Dijk and jvandijk to the same employee, in context?

The most common mistake in searching corporate data is treating every name as equally sensitive and equally useless. In a work request like "invite van Dijk to the review," the surname may simply refer to an employee the user already has the right to look up. In a request against a client data export, the same string may call for a different policy.

We solved this with a directory and matching rules. In the dev tenant, the directory includes employees and client legal entities from internal systems, plus thirty internal tools. Records are split into employee, legal_entity, and other. The tenant administrator adds and revokes them through the API/UI, and spelling variants, such as the prefixes van and de or ij and y, are computed on the matcher side.

For a new request, the pipeline might look like this:

For search, this changes everything. The index and filters work on the stable internal entity_id of the directory corpus, while only [PERSON_1] goes into the prompt. The LLM gets a typed reference but not the entity_id itself or a way to reveal the full name.

Why isn't an employee directory an access whitelist?

An employee directory is not a whitelist for bypassing DLP. It answers "which object is meant," not "can its data be shown." These decisions need to be kept apart.

For example, searching an employee's tasks may be allowed while displaying their phone number is not. A lone surname without a first name should not be resolved by the directory automatically: when it's ambiguous, the policy chooses masking. An employee and a client legal entity are different kinds of entities with different rules. For clients, the directory should be a separate perimeter altogether.

What should a DLP policy do with a detected name: mask, block, warn, or allow?

Our internal DLP discussions converged on the idea that the detector and the de-identifier solve different problems.

This breakdown is more useful than a blanket ban. Block every name, and employee search stops being usable. Let everything from the internal directory through, and you can accidentally move data into the wrong source. The mapping preserves connectivity, but the policy engine still decides what's allowed.

The policy engine routes each request to one of the four outcomes. It has the tenant settings no_mask_labels, muted_labels, and fail_mode; directory suppression gets reason=directory and is highlighted separately in the UI:

How should you store the PII mapping? Protect the table, not the token

req_map, the current request's mapping, is not a dictionary we slip into the prompt. It's server-side session state. In production, the session mapping lives for two hours, is capped at 500 tokens, and works in insert-only mode: a repeated token doesn't overwrite the value. The context doesn't mix with another session's mapping.

If an incident investigation is needed, the mapping is stored encrypted; access to reveal it is separated by the pii_reveal permission and audited. Keys and long-term mappings should be kept separate from the main database.

A token can have a predictable format, such as [PERSON_1]. This raises the chance that the model won't distort it in a reasoning context or while generating JSON. Security, however, should rely not on the secrecy of the token text but on the inaccessibility of the mapping itself. If an attacker types [PERSON_1] by hand, the gateway must not "guess" the value: only tokens present in the current request's req_map are rehydrated.

That's why random ciphertext isn't always better. It's harder for the model, and its cryptographic properties don't save the architecture if the key or the mapping table sits next to the prompt.

The approach described here isn't "permanent anonymization." The additional information makes it possible to recover the original value, so the mapping table itself needs protection. Under the GDPR, this is pseudonymization: for the company holding the mapping, the data remains personal data.^source

How do you check the model's response, not just the prompt?

Checking only the prompt isn't enough. The model can return an entity in text, JSON, a quote, tool arguments, or a streamed response.

The choice of streaming mode is a deliberate trade of latency for strictness.

How do you test that PII masking hasn't broken search?

A minimal test set should check not only whether PII was found but also whether meaning was preserved. Before launch, ask your team to run these cases:

Metrics should be kept separate: detection recall, false positives, the share of successful entity matches, correctness of policy decisions, and no rehydration from someone else's mapping. A single overall "protection score" hides where exactly the system fails.

We don't have an automated search relevance test yet. Instead, we rely on a mask → upstream → rehydrate canary every 10 minutes, a policy-verdict match metric, red teaming, and a feedback loop for false positives and misses.

Bottom line and a first step

De-identification doesn't have to destroy meaning. To get there, stop treating the placeholder as a substitute for the name and start designing an identity layer, with mapping, lifecycle, permissions, and tests. The model sees a stable entity, and the trusted perimeter decides which value stands behind it and whether it can be returned.

You can go wrong in both directions. Block every name, and the assistant becomes useless, so employees take the same names to personal chats. Let everything through, and the names go to the provider.

You can check where you stand with a single request. Ask your assistant to find a specific colleague's tasks and compare them with the meeting discussions, as in the van Dijk example, then look at what went to the provider and what came back. If the name went out in plain text or the assistant got confused by the placeholders, start with the test set above.