A privacy tool can recognize an email address, phone number, or payment card. It cannot automatically know that CUST-482913 is a customer record, EMP-18427 identifies an employee, or northwind-eu is a private tenant slug.
Those identifiers are meaningful because of your organization’s conventions. Protecting them starts with turning that local knowledge into narrow, testable redaction rules.
Inventory the real demo surface
Before writing a pattern, record a short walkthrough of the screen you actually plan to share. Group sensitive values into three buckets:
- Common structured data such as email addresses and API keys.
- Organization-specific strings such as customer codes, ticket numbers, employee IDs, and tenant slugs.
- Visual information such as names, avatars, or account balances that may not follow a stable pattern.
Automatic rules work best for the first two. Visual information usually needs a persistent manual blur box.
Make the pattern narrow
A useful custom rule includes every stable property you control: prefix, length, character set, separators, and word boundaries. Matching any six-digit number will hide too much and train reviewers to ignore the blur. Matching CUST- followed by exactly six digits is easier to explain and test.
Keep separate patterns for separate concepts. A customer ID and an employee ID may look similar, but they have different owners and different failure consequences.
Test the edges, not only the happy path
Build a small test sheet with:
- valid examples at the start, middle, and end of a line;
- lower- and uppercase variants if the product allows both;
- values next to punctuation;
- near misses that must remain visible;
- dynamically loaded content;
- text inside input fields.
False negatives expose secrets. False positives can hide the part of the interface you are trying to teach. You need evidence for both sides.
Add a visual fallback
Some sensitive data arrives after the page loads or appears as an image. Use persistent blur regions for those areas, then rehearse a panic shortcut that hides the whole screen if the interface changes unexpectedly.
Auto Blur supports custom regular-expression rules, scans page text and input fields, keeps manual blur boxes attached as content moves, and processes data locally in the browser. These controls work best when they are part of a small runbook: open the demo account, enable the rule set, inspect the preview, start sharing, and keep the emergency shortcut ready.
The goal is not maximum blur. It is a repeatable proof that the audience sees everything needed for the task and nothing that belongs to a customer, employee, or internal system.
Learn more at Auto Blur.
Top comments (0)