The customer's details,redacted before the model reads them
Support threads, refund disputes, and requirement interviews are full of the one thing that shouldn't reach an AI model: real people's emails, phone numbers, and bank details. Khint puts a per-action switch on the problem: flip it, and those identifiers become typed placeholders before the text leaves for processing. The AI still does the work; the PII never makes the trip.
The text that needs AI the most
is the text you can least afford to paste
A rambling complaint email is exactly what an AI action is for: summarize it, extract the ask, draft the dispute note. But that same email carries a signature block, a callback number, and sometimes the customer's bank line, and pasting it into a chatbot ships all of it. Khint's answer works at the only place it can work: the moment the text leaves. Actions marked as PII-sensitive get their input scrubbed (pattern-matched emails, phone numbers, SSNs, and IBANs replaced with placeholders) before the request is forwarded to the model. It layers on top of Khint's privacy-first defaults: those pages are about how little leaves your machine; this one is about scrubbing what does.
The same complaint email, two ways
What changes when the identifiers stop traveling.
- The whole complaint goes in: signature, phone, bank line
- The identifiers now live in a chat history you don't control
- The reply quotes them right back at you
- Compliance finds out the way compliance always does
- Select only the passage that needs work
- Emails, phones, SSNs, IBANs become [EMAIL], [PHONE]…
- The model summarizes around the placeholders
- Real details get re-added by a human, on purpose
One checkbox, then business as usual
Setting up a PII-safe support workflow, step by step.
Find the actions that touch customer text
Look at the Actions you run every day and sort them by what they see. A ticket-tightening prompt sees your own words; a summarize this complaint or turn this refund thread into a dispute noteaction sees the customer's: full of addresses, callback numbers, and the odd IBAN from a billing screenshot. Those are the ones that need the seatbelt.
Tick one checkbox on each of them
Open the action in the editor on the Agents page and tick Redact PII before sending (email, phone, SSN, IBAN). That's the whole setup. The setting is per action and off by default, so your prose-polishing prompts keep behaving exactly as before. Only the customer-facing ones change.
Run the action exactly as you always do
Select the complaint email, hit your shortcut, pick the action. Before the text goes to the model, Khint swaps each identifier for a type-tagged placeholder ([EMAIL], [PHONE], [SSN], [IBAN]) so the model reads “the customer at [EMAIL] called from [PHONE] about a charge to [IBAN]” and can still summarize the situation perfectly well without ever holding the real values.
Get a clean result, re-insert only what's needed
The summary or ticket draft comes back with the placeholders still in place, and pastes in wherever you were working. Your original text is untouched in the source app, so if the escalation genuinely needs the callback number, you add it back yourself: one visible decision instead of a detail that slipped through. For queue-scale triage work, see AI ticket triage for support leads →
Tighten the sensitive actions all the way down
For the actions handling the most sensitive queues, also untick the session-context option in the same editor. Then the scrubbed selection is the only thing that run sends: no Memorysummary riding along. Your sessions were never synced to Khint's servers anyway; this just keeps them out of that one model call too.
A seatbelt, worn honestly
Khint doesn't call this data-loss prevention, because it isn't: the redaction catches formats (email, phone, SSN, IBAN), not meanings, so a customer's name in running prose passes through. What it removes is the failure mode that actually happens on a busy support desk: the identifier you didn't notice in paragraph four of the text you selected. It's off by default, visible as one labeled checkbox per action, and it composes with everything else Khint already does: only your selection is ever sent, your Memory sessions stay in a local database, and the input and output text of your runs never leave the device in sync.
Common questions
What exactly does the redaction catch?
A small set of high-value patterns: email addresses, phone numbers, US Social Security numbers, and IBANs. Each match is replaced with a type-tagged placeholder ([EMAIL], [PHONE], [SSN], [IBAN]) so the model still understands the shape of the sentence. It is deliberately a pattern-based safety net, not a data-loss-prevention product: names, street addresses, and account IDs that don't match those formats pass through, so you should still read what you select before you run an action on it.
Do I have to turn it on for every action?
No, it's a per-action checkbox, off by default. In the Action editor on the Agents page, tick "Redact PII before sending" on the actions that routinely touch customer text (a complaint summarizer, a refund-dispute formatter) and leave it off where the identifiers are the point of the task. Because the setting travels with the action, you decide once per prompt, not once per run.
Does the result come back with the real details in it?
No, and that's the guarantee working as intended: the model never received them, so it cannot echo them. The transformed text comes back with the placeholders where the identifiers were, and your original selection stays untouched in the source app. If the final ticket or summary genuinely needs a contact detail, you paste it back yourself: a deliberate, visible step instead of a silent leak.
Are there paths the redaction doesn't cover?
Two, and Khint is explicit about both. First, redaction applies to the text you selected; if the action also injects your active Memory session's compacted context, that summary rides along separately. For the most sensitive actions, untick the session-context option too, so only the scrubbed selection is sent. Second, bring-your-own-key mode calls Anthropic directly from your machine and bypasses the proxy-side redaction. With your own key you are trusting your own account, so the scrubbing step isn't in that path today.
Let the AI read the complaint, not the customer
Free with 10 AI actions and 5 captures per day. No credit card. One checkbox per action, and the identifiers stay home.