Every consultant or account manager who wants LLM help drafting email replies runs into the same wall: the inbox is full of client names, project codenames, IBANs, phone numbers, and NDA-covered company references, and none of that is supposed to leave the building, let alone get pasted into a third-party API. The usual workaround — manually scrub each email before pasting it into ChatGPT, then manually patch names back into the reply — is slow enough that people either skip it (and leak data) or skip the AI help entirely.

That’s not a solo-consultant problem, it’s an enterprise one. Any company subject to an NDA, GDPR, or a client confidentiality clause has the same blocker on every “let’s use AI to help with correspondence” initiative: legal won’t sign off until there’s a real answer to “what exactly gets sent to the model.” I built EmailAssistant to answer that question concretely for one narrow but common workflow — replying to email — with an actual data path instead of a policy document.

EmailAssistant runs as a console menu against a live Outlook inbox. Command R scans unread mail and extracts each email into a payload (a JSON file plus a plain-text file you can open and edit). Command L lists everything it has picked up with status, sender, and subject preview. Before any of that text reaches OpenAI, the obfuscator runs a two-layer pass: a configurable dictionary of terms to always mask (client names, project codenames, competitor names, cities — I keep mine in obfuscation_terms.txt) plus regex detection for emails, URLs, phone numbers, IBANs, and card numbers. Every match becomes a placeholder like <<TERM_3>> or <<IBAN_1>>, and the mapping back to the real value is stored alongside the payload, never sent anywhere.

From there the menu gives you O to open the obfuscated text in Notepad for a manual check, V to view it in the console, and C to copy it to the clipboard — the point being you can actually see exactly what would be sent before it’s sent. B re-obfuscates a payload after you’ve tweaked the terms list, so if the dictionary missed something you catch it and redo the masking without re-extracting from Outlook. E calls a separate, cheaper “evaluation” prompt against just the obfuscated subject lines to flag which emails likely need a reply, so triage happens before anyone reads a single body. Only when you’re satisfied does S send the obfuscated subject and body to the model with a system prompt that forbids it from touching or guessing at the placeholders, get back a JSON draft, rehydrate the placeholders with the real values, and create a genuine Outlook reply draft — never an auto-send. TD toggles hiding already-drafted items, D and CLEAR DRAFTED manage the session list, and everything is resumable: continue_from_payload.py and reobfuscate_payload.py let you pick a session back up later without re-scanning the inbox. It ships packaged as a standalone .exe via PyInstaller with a license check gating startup, so it runs on a machine without a Python environment.

The interesting design constraint wasn’t the LLM call, it was making the human-in-the-loop step actually usable rather than theoretical. A tool that “lets you review before sending” is worthless if reviewing means squinting at a JSON blob — so the whole payload/txt split, the O/V/C commands, and the re-obfuscate loop exist specifically so a person can catch a missed term and fix it in ten seconds instead of restarting the pipeline. I also learned that obfuscation has to survive a round trip cleanly: the placeholder scheme has to be robust enough that the model can’t accidentally “fill in” a masked value from context, and the rehydration step has to be exact-match reliable or you leak a placeholder into a live client-facing draft, which is worse than no automation at all.

The core pattern here — obfuscate, let a human or a gate check the redaction, call the model, rehydrate, keep everything reviewable — generalizes past email. Any workflow where an org wants LLM assistance on text that contains client or PII data (support tickets, contract drafts, meeting notes, CRM fields) can use the same obfuscate/rehydrate boundary instead of building a bespoke redaction system per use case. At team scale, the natural next step is centralizing the term dictionary and the placeholder/mapping store so redaction rules are shared and audited across a whole department rather than living in one person’s local obfuscation_terms.txt, and swapping the license-gated single-user .exe for a service that can log what was sent (without logging what it contained) for compliance review.

For this tool specifically, the obvious extensions are Gmail/other mail clients beyond Outlook, and letting the evaluation step also draft a suggested urgency/routing tag, not just a priority flag.