Yes, but not by adding your system to Claude directly. When you paste your ATS's own address into Claude's Connectors screen, Claude talks to the ATS itself and there is nothing in between: it works, records come back, nothing looks broken, and every name, email and ID number in them is real and now sits in a chat log. To keep them out, you put a redaction proxy in the middle and give Claude that address instead. PII Shield does this as a hosted connector: you add your system in the dashboard, it hands you one web address, and Claude sees [PERSON_1] where the record said Marcus Delacroix. Tokens are stable and reversible, so when Claude sends one back — looking somebody up by email, say — the real value is restored on the way out and the lookup still works.
Why the obvious approach quietly fails
Most business systems now publish an MCP server, and Claude will happily connect to one. The setup takes a minute and the result looks exactly right: you ask for your shortlist, the shortlist appears. That is the problem. Nothing in the protocol lets one connector sit in front of another, so once Claude holds your ATS's address it is talking to your ATS, and the whole record — name, email, phone, ID number, the CV text — travels into the conversation. There is no error, no warning, and no way to tell from the answer that anything went anywhere it should not have.
This is different from the risk people usually worry about. It is not somebody carelessly pasting a spreadsheet; it is an integration working as designed and moving thousands of records, quietly, because somebody in ops connected a tool one afternoon.
What goes in between
The fix is to be the server Claude talks to. A redaction proxy speaks the same protocol in both directions: Claude asks it for tools, it asks your system; Claude calls a tool, it calls your system, takes the answer apart, replaces every personal value with a token, and hands back a record that reads normally and identifies nobody.
{ "name": "Marcus Delacroix",
"email": "[email protected]",
"phone": "+27 82 555 0134",
"stage": "Onsite Interview",
"role": "Financial Controller" }{ "name": "[PERSON_1]",
"email": "[EMAIL_1]",
"phone": "[PHONE_1]",
"stage": "Onsite Interview",
"role": "Financial Controller" }Notice what survives. The stage and the role are untouched, because they are what the question was actually about. A model can rank this shortlist, compare candidates, spot that somebody has been sitting at the same stage for three weeks — everything you wanted — while being unable to tell you who any of them are, and so can anybody who reads that conversation later.
The half that makes it usable rather than merely safe
One-way masking would make the whole thing a toy. If your agent can read a shortlist but cannot act on it, you have bought a summariser.
Reversibility is what fixes that. Each value gets a stable token for the whole session, so [EMAIL_2] is the same person every time it appears, and when the model calls find_by_email("[EMAIL_2]") the proxy turns that back into the real address before your system ever sees the request. Your ATS receives a perfectly ordinary query. The model never held the address at all.
Several systems, one address
Teams rarely have one system. Once you have an ATS, a helpdesk and a CRM connected, the useful thing is not three addresses in Claude but one, carrying all of them — because then the tokens are shared. The same person coming out of your ATS and out of your helpdesk gets the same token, so "[PERSON_1] applied and then raised a ticket" is a sentence about one human being rather than a coincidence you have to reconstruct.
It also means adding or removing a system never touches Claude's settings again. The address stays the same; you tick things in or out of it.
What to check before you trust it
- Ask the model what it actually received. Not whether it worked — whether it saw tokens or real names. This is the one failure that is invisible from the outside, so make it visible on purpose.
- Check it fails closed. An unreachable proxy, a bad credential or an exhausted plan should return an error, never the raw record. If it degrades to passing data through, it is worse than nothing, because you will trust it.
- Check the tool descriptions, not just the results. A system that generates one tool per record puts the person's name in the tool description, and descriptions reach the model before any tool is called.
Nothing to install
Worth saying plainly, because it is the practical difference: this route needs no software on anybody's machine and no configuration file. It is a web address pasted into a settings screen, so it works in claude.ai in a browser, where most people actually are. The local-wrapper approach — putting a program in front of a server in your MCP config — is still the right answer for Claude Code and the desktop app, but a browser cannot start a local program, so for the browser this is the only thing that can work at all.
Common questions
Does adding my ATS to Claude as a connector protect the data?
No. Claude then talks to the ATS directly and nothing sits in between, so every name, email and ID number in the records reaches the model and the conversation log. It works and nothing looks broken, which is exactly why it is dangerous. To keep personal data out you have to give Claude the address of something that redacts, and let that thing talk to your ATS.
Can an AI agent still email or look up a real person if the data is redacted?
Yes, if the redaction is reversible. Each value gets a stable token, and when the model sends a token back — calling find_by_email("[EMAIL_1]") for example — the proxy restores the real address before the request reaches your system. The system sees an ordinary query; the model never held the address.
Can I connect more than one system through a single address?
Yes. A bundle address carries every connected system at once, and because they share one session they share one set of tokens, so the same person has the same token whichever system they came out of. Adding or removing a system then never requires changing anything in Claude.
Try it on your own data
A free workspace takes one step — 250 requests a month, three connected systems, no card.
Create a workspace