PII Detection & Classification

Noxys uses a three-tier detection strategy to identify sensitive data: fast regex on the client, deeper NER on the server, and async context-aware classification for advanced use cases.

Detection Tiers Overview

Tier	Location	Latency	Coverage	Use Case
Tier 1	Browser Extension	<10ms	Basic PII (emails, phone, IBAN, credit cards)	Real-time policy enforcement
Tier 2	Backend (Presidio)	~30ms	Expanded PII + entities (names, medical, legal)	Deep classification (opt-in)
Tier 3	Async Processing	Minutes	Context-aware, custom patterns	Compliance research, incident investigation

Tier 1: Extension-Based Regex Detection

The fastest detection runs entirely in your browser. No data leaves your device unless you explicitly enable server-side classification.

Supported Classifications

Type	Pattern	Examples	Confidence
EMAIL	RFC 5322 regex	alice@acme.fr, john.smith@company.co.uk	95-99%
PHONE	E.164 international format	+33612345678, +1-555-0123, 0612345678	90-95%
CREDIT_CARD	Luhn algorithm (PAN)	4532-1234-5678-9010, 378282246310005	98-99%
IBAN	ISO 13616 checksum	FR1420041010050500013M02606, DE89370400440532013000	98-99%
FR_NIR	French Social Security	1 85 07 75 056 045 72, 185077505604572	95-98%
FR_SIRET	French Business ID	73282932000074 (14 digits)	99%
FR_SIREN	French Company ID	732829320 (9 digits)	99%

Performance Characteristics

Tier 1 Detection:

• Execution time: <10ms per message
• Memory footprint: <5MB for entire extension
• CPU overhead: <1% (runs only on 15 AI platform URLs)
• No external API calls (fully offline-capable)

Privacy:

• Pattern matching happens in browser sandbox
• Raw text never transmitted to backend
• Only SHA-256 hash + match metadata sent

Example Detection

User input: "Call me at +33612345678 or email alice@acme.fr"

Tier 1 Processing:

1. Scan text with 7 regex patterns
2. Found: EMAIL at position 41-59
3. Found: PHONE at position 14-28
4. Calculate risk_score = 2 / 45 * 0.92 ≈ 0.04
5. Send to backend:
{
  "content_hash": "a665a45920422f9d...",
  "classifications": [
    { "type": "EMAIL", "confidence": 0.98, "start": 41, "end": 59 },
    { "type": "PHONE", "confidence": 0.92, "start": 14, "end": 28 }
  ],
  "risk_score": 0.04
}

Tier 2: Backend-Based NER (Named Entity Recognition)

For deeper analysis, optionally enable server-side classification using Microsoft Presidio.

Enable Server-Side Classification

1. Click extension icon → Settings → Advanced
2. Toggle Enable Server-Side Classification
3. Click Save

Effect:

• Prompts sent to backend for deeper analysis (~30ms latency added)
• Backend runs Presidio NER to detect additional entities
• Text is immediately deleted after processing (not stored)

Supported Classifications (Tier 2)

Beyond Tier 1, Presidio detects:

Type	Examples	Use Case
MEDICAL_TERM	Patient name, diagnosis code, medication	Healthcare compliance (HIPAA)
LEGAL_REFERENCE	Contract party name, clause reference	Legal/compliance review
API_KEY	Bearer tokens, AWS keys, API secrets	Credential leak detection
IP_ADDRESS	IPv4 (192.168.1.1), IPv6 (::1)	Network info protection
PERSON_NAME	John Doe, Jane Smith	Privacy protection
ORGANIZATION	Acme Corp, Microsoft Inc.	Entity de-identification
LOCATION	Paris, New York, EU	Geographic data
DATE	2026-03-20, 20/03/2026	Temporal info

Privacy With Server-Side Classification

Important: Enabling Tier 2 sends the raw prompt text to the backend.

Security guarantees:

• Text is immediately deleted after NER processing (no storage)
• Encrypted in transit (TLS 1.3)
• Backend processing logs are redacted (no text stored in logs)
• Complies with GDPR (text not stored, only hash)
• Audit trail shows "server-side classification processed"

Data flow:

Browser
  ↓
"My diagnosis is ICD-10: C34.9"
  ↓ [TLS 1.3]
Backend Presidio
  ↓
Detect: MEDICAL_TERM (confidence: 0.85)
  ↓
DELETE TEXT
  ↓
Send back: { type: "MEDICAL_TERM", confidence: 0.85 }
  ↓ [TLS 1.3]
Browser

Configuration Options

In Settings → Advanced → Server-Side Classification:

• Sensitivity Level:

  • Strict: High confidence only (>0.9)
  • Balanced: Medium confidence (>0.7)
  • Permissive: Any match (>0.5)

• Entity Types to Detect:

  • Checkboxes for each type (MEDICAL, LEGAL, API_KEY, etc.)
  • Default: All enabled

• Batch Timeout:

  • How long to wait before processing (default: 2 seconds)
  • Lower = faster response, higher CPU
  • Higher = more efficient, slight delay

Tier 3: Async SLM Classification

For compliance research and advanced use cases, async processing runs context-aware classification using smaller language models (SLMs).

When Tier 3 Is Used

Tier 3 is NOT real-time. It processes interactions asynchronously:

1. Tier 1 + Tier 2 complete in real-time (policy enforcement)
2. Tier 3 classification runs in background (minutes to hours)
3. Results available in Dashboard → Interactions → [click interaction] → "Tier 3 Analysis"

Capabilities

Tier 3 detects context-dependent classifications:

Capability	Example
Ambiguous names	Is "Smith" a person name or product name?
Medical context	"Patient reports fatigue" → flag medical context
Financial sensitivity	"Q4 earnings: $50M" → flag sensitive financial data
Custom rules	Organization-specific patterns

Configuration

In Settings → Compliance → Advanced Classification:

1. Enable Tier 3 Async: Toggle on
2. Processing Delay: 5 minutes to 24 hours (choose balance of speed vs. resource usage)
3. Custom Rules: Upload JSON file with organization-specific patterns

Example custom rule:

{
  "pattern": "\\b(project|codename)\\s+[A-Z][a-z]+\\b",
  "classification": "INTERNAL_PROJECT",
  "confidence": 0.85,
  "description": "Matches 'Project XYZ' style internal codenames"
}

Risk Score Calculation

Formula

risk_score = (count_of_detections) / (content_length) × (avg_confidence)

Examples

Example 1: Email in normal message

Message: "Call me at alice@acme.fr anytime"
Length: 32 chars
Detections: 1 email (confidence: 0.98)
Risk = 1 / 32 × 0.98 ≈ 0.03 (Low)

Example 2: Multiple PII types

Message: "alice@acme.fr +33612345678"
Length: 26 chars
Detections: 1 email (0.98) + 1 phone (0.92)
Avg confidence: 0.95
Risk = 2 / 26 × 0.95 ≈ 0.07 (Low-Medium)

Example 3: Highly concentrated PII

Message: "alice@acme.fr +33612345678 FR1420041010050500013M02606"
Length: 60 chars
Detections: 1 email (0.98) + 1 phone (0.92) + 1 IBAN (0.99)
Avg confidence: 0.96
Risk = 3 / 60 × 0.96 ≈ 0.05 (Low-Medium)

Example 4: Dense sensitive content

Message: "alice@acme.fr | 4532-1234-5678-9010"
Length: 36 chars
Detections: 1 email (0.98) + 1 credit card (0.99)
Avg confidence: 0.985
Risk = 2 / 36 × 0.985 ≈ 0.055 (Medium)

Example 5: Sensitive data dominating message

Message: "FR1420041010050500013M02606"
Length: 27 chars
Detections: 1 IBAN (0.99)
Risk = 1 / 27 × 0.99 ≈ 0.037 (Low-Medium)

Risk Score Bands

Band	Range	Interpretation	Typical Action
Minimal	0.00-0.10	Incidental mention	Log
Low	0.10-0.30	Some PII, longer message	Log / Coach
Medium	0.30-0.70	Moderate PII concentration	Coach / Block (context-dependent)
High	0.70-0.90	Significant PII	Block
Critical	0.90-1.00	Severe PII density	Block

Note: Thresholds are configurable per organization.

Classification Confidence

Each detected PII has a confidence score (0-1) indicating likelihood of a true positive.

Confidence Factors

High confidence (0.95+):

• Credit card numbers (Luhn checksum validates)
• IBANs (ISO checksum validates)
• French identifiers (fixed format)

Medium-high confidence (0.85-0.95):

• Email addresses (valid format + TLD)
• Phone numbers (E.164 format)

Medium confidence (0.70-0.85):

• Names (could be common words)
• Medical terms (context-dependent)
• API keys (pattern match, but format varies)

Low confidence (<0.70):

• Single letters that look like codes
• Abbreviations (could be legitimate)

To adjust sensitivity:

1. Extension Settings → Advanced → Classification Sensitivity
2. Choose: Strict (>0.9), Balanced (>0.7), Permissive (>0.5)
3. Lower threshold = more detections (higher false-positive rate)

French-Specific Classifications

Noxys has built-in support for French PII types (critical for EU compliance).

FR_NIR (French Social Security Number)

Format: 15 digits: SEX|YY|MM|DEP|COM|CODE|KEY

Examples:

• 1 85 07 75 056 045 72 (formatted)
• 185077505604572 (unformatted)

Sensitivity: Critical — never share with AI services

Detection: Tier 1 (regex) + checksum validation

Validation algorithm:

1. Extract 13-digit base
2. Concatenate "97" + last 2 digits (key)
3. MOD97 calculation must equal 0

FR_SIRET (Business Establishment ID)

Format: 14 digits: SIREN (9) + SIRET seq (5)

Examples:

• 73282932000074
• 7328 2932 000074 (formatted)

Sensitivity: Business identifier — may need protection depending on policy

Detection: Tier 1 (regex) + length validation

FR_SIREN (Company ID)

Format: 9 digits

Examples:

• 732829320
• 732 829 320 (formatted)

Sensitivity: Public company identifier — lower risk than NIR

Detection: Tier 1 (regex) + checksum validation

Detection Accuracy & False Positives

Known Limitations

False positives (legitimate text flagged as PII):

Scenario	Example	Likelihood
Email-like format in non-email context	"It's user@domain logic"	Low (0.5%)
Phone in product ID	"Model 5G-123-45"	Low (1%)
IBAN-like format in code	var iban = "FR14..."	Medium (5%)
NIR-like format in example	"Example: 123 45 67 8..."	Medium (10%)

False Negatives

Missed detections (PII not flagged):

Scenario	Likelihood
Misspelled email (typo)	10-20%
International phone without E.164 format	5%
Credit card without standard separators	5%
Redacted PII (e.g., "john...@acme.fr")	100%

Improving Detection

To reduce false positives:

1. Increase confidence threshold (Strict mode)
2. Create policies with additional conditions (e.g., platform, department)
3. Use Coach (not Block) for medium-risk scenarios

To reduce false negatives:

1. Enable Tier 2 (server-side NER)
2. Lower confidence threshold (Permissive mode)
3. Add custom Tier 3 rules for organization-specific formats

Classification API

For programmatic access, use the API to send interactions:

curl -X POST https://api.noxys.cloud/v1/interactions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "platform_id": "chatgpt",
    "content_hash": "a665a45920422f9d...",
    "classifications": [
      {
        "type": "EMAIL",
        "confidence": 0.98,
        "start": 24,
        "end": 42
      }
    ],
    "risk_score": 0.15
  }'

Classification in Policies

Using Classifications in Policy Conditions

Create policies based on classification types:

Example 1: Block any EMAIL

Condition: classification_types contains "EMAIL"
Action: Block

Example 2: Block multiple types together

Condition: classification_types intersects ["EMAIL", "PHONE", "CREDIT_CARD"]
Action: Block

Example 3: Block specific types only

Condition: classification_types contains "FR_NIR"
Action: Block

Example 4: Block if high-risk + specific type

Condition: risk_score gte 0.7 AND classification_types contains "MEDICAL_TERM"
Action: Block

Monitoring & Reporting

In Dashboard

Interactions page:

• View all detected classifications
• Filter by type (EMAIL, PHONE, etc.)
• See confidence scores
• Review risk distribution

Compliance Reports:

• PII type distribution (pie chart)
• Risk score trends (line chart)
• Top platforms by PII detection
• Classification effectiveness

Next Steps

• Policy Configuration — Use classifications in policy conditions
• Architecture Overview — Understand how detection integrates
• AI Service Catalog — Map services to data regions

---

Need help?

• Email: support@noxys.eu
• Detection test: Upload sample text at Settings → Test Classification
• False positive report: Contact support with example