noirdoc - PII guard for Claude Code to keep client data out of context
by•
Open-source plugin that redacts PII before Claude Code reads it. Names, emails, and IBANs become placeholders Claude sees; you reveal originals locally. Same engine ships as a CLI for any LLM and a hosted proxy for OpenAI/Anthropic/Azure.


Replies
voice→form widgets are the case i kept hitting — transcribed names, addresses, phone numbers flowing straight into prompts before anyone notices. the moment you try to use real customer voice samples, Legal blocks the whole pipeline.
the German-tuned detection is the part that actually matters — most tools fail on lowercase legal text and "Müller, Anna" patterns, and false positives there kill adoption faster than missed PII.
apart from finance information is it able to detect some credentials been passed accidentaly?
@zabbar Not yet, but we have it on the roadmap!
This solves a real pain point. I work at a fintech and we hit the same wall constantly: engineers want to use Claude Code on production support tickets but the moment there's a customer IBAN or address in the file, compliance shuts it down. The PreToolUse hook approach is smart because it catches things before they ever leave your machine. Curious about the performance overhead on large files (e.g. 10K+ line logs with scattered PII). Does the Presidio+Flair ensemble add noticeable latency, or is it fast enough to feel invisible during normal Claude Code usage?
@elijahbowlby Honest answer: it will not be invisible on 10K-line files with the full pipeline. Flair's the bottleneck here. For huge logs you can drop Flair and run Presidio + spaCy only — ~10× faster, you lose some German name recall but the regex layer still catches IBANs and emails (which is the actual fintech failure mode).
The hook is async, so Claude Code shows a "redacting…" state instead of blocking. But yeah — for large files, you will feel the latency!
How do you detect names? A dictionary? An LLM or model of some sort?
@robert_douglass No a dictionary would be too brittle, it uses a combination of tools.
Presidio handles regex-based PII (IBAN, email, tax IDs). For names, we use three NER models, all local:
The NER component of spaCy's de_core_news_lg pipeline (called via Presidio)
Flair's de-ner-large (dedicated NER model, separate pass — catches "Schmidt, Lisa" comma-form and lowercase legal text)
GLiNER (zero-shot — add custom entity types at runtime without retraining)
Each NER fails differently, so the three vote together, because the union has better recall than any single one.
The local reveal step is the part that makes this feel usable in real consulting work. Redaction alone is never enough if the team cannot safely get back to the real values before shipping. Curious how the detector handles domain specific identifiers that are not classic PII.
This is pretty smart. I can imagine a lot of corporations needing this tool, including my own consulting firm.
Are you able to create your own dictionary as well? Can this be deployed at the enterprise level?