Rampart Open-Sourced for Local Removal of Personal Data from Messages

Rampart checks messages in the browser and replaces detected personal data with labels before sending them to a chat service. The project has been released as open source in alpha.

· 4 min read · 4 comments

On October 9, the Rampart developers announced that they had open-sourced a tool for detecting and masking personal data in the browser. According to the announcement, Rampart checks a message before it is sent to a chat service and replaces detected information with labels, without sending the message to a server for the check itself. The project is in alpha: it is a first line of defense that may miss personal data.

How Rampart Processes a Message

The tool uses two detection methods. Regular expressions, combined with match validation, handle data with predictable formats: Social Security numbers, payment card and bank account numbers, phone numbers, email addresses, IP addresses, and document numbers. For this kind of information, rules can look for specific sequences of characters.

A small MiniLM language model supplements the rules when the context of a sentence matters. Its job includes finding names and street names, which cannot be reliably described by a single pattern. Detected passages are replaced with category labels. In the example from the announcement, the first and last names get separate labels, while the Social Security number is replaced with [SSN]. The monthly income amount remains in the request.

The check runs after the user enters text but before the message is sent. Mappings between labels and original values are stored temporarily in the browser so the values can be restored in the chat service’s response. In the code example, the application first calls protect on the message, sends the processed text to the model, and then applies reveal to the response. This means values detected by the filter do not need to be sent to the service with the request.

The authors explain their local approach by noting that remote scrubbing still requires the original message to be sent to a server. Another barrier they identify is the size of some personal data detection models: downloading a large file into the browser can take a long time on a slow connection. Rampart is presented as a component that runs the check directly on the user’s device.

What Has Been Released and Its Limitations

Alongside the source code, the authors provide a model on Hugging Face, an NPM library, and a technical paper. The announcement shows how to use @nationaldesignstudio/rampart to process a request and then restore values in the response. This example describes the intended workflow, not every possible integration.

The project claims support for seven languages written in the Latin script: English, Spanish, French, German, Italian, Portuguese, and Dutch. Training used AI4Privacy’s OpenPII 1.5M and synthetic data that augmented 17 entity types with examples resembling chat messages. The complete processing pipeline was evaluated on a held-out set of 30,000 OpenPII records across the seven supported languages. The text provided does not include numerical results from that evaluation.

The authors call Rampart a first step in a broader effort to handle personal data in AI chats. If the filter does not recognize a passage, or if the information falls outside the categories it detects, it will remain in the text. The announcement does not give a date for leaving alpha.

What This Means for Web Teams

For a website with a chat feature, the timing of the check matters: Rampart processes a message before it reaches an external service. If personal data is recognized, the site can send text with labels instead of the original values. That changes the path taken by detected data, but it does not answer which requests the site should send to a chat service in the first place.

When evaluating an integration, developers should test the entire flow with examples from their own project: what text comes out of protect, what exactly is sent to the model, and when the interface calls reveal. They should also check what happens when messages contain information written in unusual ways. For site owners and marketing teams, this is a reason to describe how the chat works more precisely to visitors: having a filter is not the same as promising that anything they enter will stay on their device.

My Take

I would treat Rampart as an additional layer before sending a request, not as a substitute for reviewing the entire integration. Local processing solves a specific problem: detecting data does not require sending the original text to a separate service. But before adopting it, I would want to test it against real user phrasing and understand which passages remain in the message after processing.

For a small website, I would also work out the cost of integration and maintenance. If a team does not check the masking results or control the path the text takes to the chat service, simply installing the library provides little reason to change how it handles data.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

  1. Rampart: Browser native on-device PII radaction ndstudio.gov

About the author

Roman Zimmer

e-commerce full-stack developer

I build high-traffic shops and integrations for inventory and payments. Before choosing a stack, I look at the workload profile and the cost of maintenance.

All posts by the author

Leave a comment

Not published. We’ll send a link to confirm your comment.

No links or ads. Your first comment is published after review. By sending a comment you agree to the privacy notice.

  1. calling this a first line of defense sounds optimistic for an alpha tool that can miss data; client-side checks are useful, but they don’t replace careful handling on the chat service

    1. @lukasz.gorski Fair point—the “first line” framing only works if it’s treated as a prompt to catch obvious formats like emails or card numbers, not as a safety boundary; server-side controls still need to do the heavy lifting.

    2. Would you consider it a useful extra layer if the chat service still handles the main checks, especially since the browser model can miss context?

      1. Yes, as a defense in depth layer, provided the chat service remains authoritative. Rampart’s browser checks can catch predictable formats and some context-dependent cases, but the alpha model can miss things; I’d measure both false positives and misses before relying on it in a workflow.