Detection Categories

Blur focuses on categories that matter in workplace prompts: contact data, names, financial identifiers, and sensitive traits. Each category can be toggled independently, allowing teams to customize detection to match their specific privacy requirements.

Contact Information

Included in free tier

Email addresses, phone numbers, and physical addresses are detected so teams can ask for writing or analysis help without pasting raw personal contact data into a model request.

Examples of what this category catches:

• Email addresses in any standard format (e.g., name@company.com)
• Phone numbers in domestic and international formats
• Street addresses, city/state/zip combinations, and mailing addresses

This is one of the most commonly triggered categories because contact information frequently appears in prompts that involve drafting emails, summarizing meeting notes, or processing customer data.

Names & Entities

Included in free tier

Blur can replace people names, company names, and organization references with clean placeholders that preserve the intent of the prompt without exposing the original context.

Examples of what this category catches:

• First names, last names, and full names
• Company and organization names
• References to specific teams or departments when combined with identifiable context

The detection engine uses a combination of pattern matching and entity recognition to distinguish names from common words, minimizing false positives while catching a broad range of name formats.

Financial & Regulated Identifiers

Enterprise only

SSNs, credit card numbers, and other high-risk identifiers are surfaced aggressively because these are the highest consequence values to leak into third-party model traffic. A single exposed SSN or card number in an AI prompt creates immediate regulatory and liability risk.

Examples of what this category catches:

• Social Security Numbers (SSN) in standard and common alternative formats
• Credit and debit card numbers (Visa, Mastercard, Amex, Discover patterns)
• Bank account and routing numbers
• Tax identification numbers (EIN, ITIN)

This category uses strict pattern matching optimized for low false-negative rates. It is designed to err on the side of flagging potential matches rather than missing genuine sensitive data.

Sensitive Traits

Enterprise only

Health details, dates of birth, and other sensitive personal descriptors are treated as review-worthy fields so users can decide what leaves the browser. This category is particularly relevant for teams in healthcare, HR, insurance, and legal verticals where personal attributes frequently appear in work context.

Examples of what this category catches:

• Medical conditions and health-related terms
• Dates of birth and age references
• Demographic descriptors including race, ethnicity, religion, and gender identity
• Disability status and accommodation references

Because these traits are context-dependent, the detection engine flags potential matches for user review rather than automatically masking them. This gives users the final say on whether a flagged item is genuinely sensitive in their specific use case.

Aggressive Mode

Enterprise only

When enabled, Aggressive Mode applies stricter matching thresholds across all active categories. This results in more items being flagged for review, which is appropriate for teams with zero-tolerance policies around data exposure in AI prompts.

Aggressive Mode is recommended for:

• Teams handling regulated data (HIPAA, PCI, SOX)
• Security-conscious organizations during initial rollout
• Use cases where the cost of a missed detection is high

Smart Placeholders

Enterprise only

By default, Blur replaces detected items with generic placeholder tokens (e.g., [NAME], [EMAIL]). Smart Placeholders upgrade this behavior by generating contextually appropriate replacement values that make the resulting prompt read more naturally.

For example:

• "John Smith" might be replaced with "Alex Rivera" instead of [NAME]
• "john.smith@acme.com" might be replaced with "alex.rivera@example.com" instead of [EMAIL]

This is useful when the AI model's response quality depends on having realistic-looking input data rather than obvious placeholder tokens.