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. Agents 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 agents 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 note action 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.
Check one box on each of them
Open the action in the editor on the Agents page and check Hide personal details from the AI (emails, phone numbers, bank details). 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 uncheck the session-context option in the same editor. Then the scrubbed selection is the only thing that run sends: no Memory summary 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's 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 agent editor on the Agents page, check "Hide personal details from the AI" 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 can't 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?
One, and Khint is explicit about it: redaction applies to the text you selected, so if the action also injects your active Memory session's compacted context, that summary rides along separately. For the most sensitive actions, uncheck the session-context option too, so only the scrubbed selection is sent. Bringing your own provider key doesn't change this: those runs still go through Khint's backend with your key swapped in, so the same redaction step applies before the text reaches the model.
Let the AI read the complaint, not the customer
Free with 300 credits a month, about 10 AI actions a day. No credit card. One checkbox per action, and the identifiers stay home.