PISIGuard and the problem of pasting sensitive data in chat

One point and zero comments. That was PISIGuard's score on Hacker News a few hours after it showed up in the aggregator's AI section, on the morning of 3 August. Traction is minimal, but the problem it targets comes up in almost every Claude integration project that crosses our desk: the moment someone pastes a full contract, complete with names, ID numbers and bank accounts, into a chat window.

The description on the GitHub repository is terse: protect your personal and sensitive information when you chat with AI. The Hacker News thread has not produced any discussion yet. With so little public surface, what matters is not the specific tool but the category it belongs to, one that has been growing for a couple of years without a settled name: redaction filters, DLP layers for prompts, anonymisation proxies that swap identifiable data for placeholders before the request leaves the building.

Where the real risk sits

Two things tend to get conflated. One is how the model provider handles your data, and there the contract rules: the commercial terms of serious APIs have long stated that customer inputs and outputs are not used for training by default. Reviewing the current terms before signing is still mandatory, but that is not where most things break.

The other layer is internal, and it is the one that produces the scares. An intern pasting the leads database into a personal chat on a Gmail account. A developer copying a production log with tokens inside it. A spreadsheet of patient data ending up in a tool bought by marketing rather than IT. No contract fixes any of that: it is a perimeter problem, and a local filter that intercepts text before it goes out is a reasonable answer to the right question.

What to check before installing anything

A tool like this sits at the most sensitive point in the flow, so the checklist is short but non negotiable.

1. Where detection runs. If the filter calls an external service to decide what counts as personal data, you have moved the problem rather than solved it.
2. Which method it uses. Regular expressions catch IBANs, cards and emails with high reliability. Proper names, addresses and clinical context need entity recognition, with the false negatives that come with it.
3. Whether it reverses. Replacing Marta López with `[PERSON_1]` is not much use if you cannot undo the mapping to read the answer with the real names.
4. Licence and maintenance. A freshly published repository with no history and no visible tests is not a production candidate, however good the idea is.

Alternatives inside the Claude stack

Anyone working with Claude Code has a less flashy and more controllable route: hooks. A `PreToolUse` hook that inspects the payload before a network call lets you block or rewrite content with your own script, audited by your team and free of third party dependencies. For desktop flows, an intermediate MCP server can act as customs between the user and the data, with the advantage that the policy lives in one place instead of in everyone's head.

Neither option is free in maintenance terms. A badly tuned regex breaks legitimate prompts and teaches staff to switch the filter off, which is the worst possible outcome: the feeling of control without the control.

We think it is healthy that projects like this appear, even if this one arrives green and without a community behind it. Data hygiene at the chat interface is the part of an AI rollout that gets postponed most often and ages worst when an audit turns up. If the repository ends up unconvincing, the conversation it triggers inside the team already justifies the time spent.