How Guardia Detects PII, PHI, and Credentials in Real Time

Ask why an AI data protection tool would need more than one detection method, and the honest answer starts with a simple test: try writing a single regular expression that reliably matches every way a person's name can appear in a sentence. It's not possible because names don't have a fixed format, they don't follow a consistent pattern, and vary infinitely by language, culture, and context. Now try writing a named-entity-recognition model that reliably distinguishes a real AWS access key from a similarly-formatted string in a code comment. That's a much better job for a precise pattern match than for a probabilistic language model.

This is the actual reason real detection engines run more than one method side by side rather than picking whichever is easiest to build. This guide covers how Guardia's detection layer handles both problems, the free-text entity detection that PII and PHI require, and the structured pattern matching that credentials and financial identifiers require, and why conflating the two into a single "PII scanner" undersells what each one is actually good at.

What Actually Happens When a Prompt Gets Scanned?

Before an AI model ever receives a prompt, Guardia's scanner service runs a fixed detection sequence: a named-entity-recognition pass runs unconditionally on every request first, then whichever additional scanners are attached to the active policy run against that same content. LangProtect's guide to sanitization, redaction, and smart redaction covers what happens to a detected entity once it's found and this guide focuses one layer earlier, on how something gets identified as sensitive in the first place.

Two fundamentally different technical approaches do that identification work, and understanding which one applies to which category of data is the difference between a detection engine that actually works and one that either misses obvious sensitive data or drowns policies in false positives.

How Does Detection Work for PII and PHI?

Personally identifiable information and protected health information are detected primarily through named entity recognition (NER), it is a machine learning approach that identifies entities based on context and language patterns, not a fixed string format. Guardia's implementation runs on Microsoft Presidio, Microsoft's open-source data protection and anonymization framework, extended with custom recognizers for region-specific identifiers and clinical terminology.

NER is the right tool here because names, addresses, and most PHI categories simply don't have a matchable structure. "John Martinez," "J. Martinez," "Johnny M.," and "the patient's brother" might all refer to the same person in the same conversation, and no regular expression can reliably catch all four while ignoring the thousands of two-word phrases that aren't names at all. NER models instead learn to recognize entities from surrounding context and linguistic patterns, that's the same category of technique used across the industry for this exact problem, because the alternative (exhaustively listing every possible name) simply doesn't scale.

A representative example is Guardia's Healthcare PHI Protection scanner, which uses Presidio to detect all eighteen identifier categories specified under HIPAA's Safe Harbor de-identification method; names, dates more specific than year, geographic subdivisions smaller than a state, medical record numbers, and the other categories the regulation defines; alongside clinical entities like medications and diagnoses that fall outside Safe Harbor's list but carry obvious sensitivity in a healthcare context.

How Does Detection Work for Credentials and Secrets?

Credentials, API keys, connection strings, and similar secrets are detected primarily through pattern-based scanning; regular expressions matched against the prompt text, configured with flags that control case sensitivity, boundaries, and similar matching behavior. This is the opposite situation from names: an AWS access key, a JWT token, or a database connection string does follow a fixed, predictable structure, which makes it exactly the kind of value a well-constructed regular expression catches reliably, with far less computational overhead than running a language model against every request.

Guardia's Credential & Secret Exposure category is built around this approach, covering API keys, passwords, authentication tokens, private keys, and database connection strings; categories where a structural definition (a specific prefix, a specific length, a specific character set) makes pattern matching both fast and precise. This category runs on the input side, catching secrets before they leave the browser, and a related scanner like MCP Output Secret Masking applies the same logic on the output side, specifically scanning AI coding assistant responses for credentials that shouldn't be echoed back into a developer's IDE.

Financial identifiers like credit card numbers fall into this same category for the same reason: a 16-digit number following one of a small number of well-defined card-issuer formats is a pattern-matching problem, not a language-understanding one.

Why Does This Require Two Different Methods Instead of One?

Because the two categories of sensitive data have opposite properties, and optimizing a detection method for one makes it worse at the other. A regular expression precise enough to reliably catch a specific credential format has essentially zero ability to recognize that "Sarah" is a name in a sentence that could describe millions of different things depending on context. Conversely, a named-entity-recognition model tuned for contextual language understanding is solving a fundamentally different problem than exact structural matching, and applying it to something like a credential format, where precision matters more than contextual flexibility, and it adds computational cost without adding accuracy.

This is precisely why a production detection engine runs both simultaneously rather than picking one general-purpose method and accepting its blind spots. Guardia's built-in scanner library spans several categories built on different underlying techniques for this reason: sensitive-data exposure (Presidio-based NER), credential and secret exposure (pattern-based), behavioral risk and prompt-attack detection (a mix of pattern, keyword, and for genuinely semantic evaluation a self-hosted intent-classification model), and output quality and format controls. A dedicated comparison of Guardia's three custom scanner types Pattern, Keyword, and Intent covers when each is the right tool to reach for when building a custom detection rule, since the tradeoffs between them extend beyond just the PII/PHI-versus-credentials split covered here.

What Happens After Something Is Detected?

Detection alone doesn't determine what happens next; every scanner, regardless of which method produced the detection, contributes a confidence score and a priority level that together decide whether an enforcement action actually fires.

Each scanner declares a priority (critical, high, medium, or low) that determines its contribution to an aggregate risk score when multiple scanners trigger on the same prompt, and a confidence threshold, a value between 0.00 and 1.00, below which a detection gets logged as a soft detection rather than triggering enforcement. This distinction matters in practice: a Presidio-based name detection with moderate confidence in an ambiguous sentence and a pattern-based credential match with near-certain confidence shouldn't be treated identically just because both technically "found something." When multiple scanners trigger on the same prompt, the highest-severity triggered result determines the actual enforcement outcome, which of the five available outcomes that ends up being, and how to decide, is covered in LangProtect's guide to redact, warn, or block.

Confidence thresholds are configurable per policy, not fixed globally; an organization in a heavily regulated industry might lower the threshold for PHI detections to catch more borderline cases at the cost of more false positives, while a lower-stakes deployment might raise it to reduce interruption for genuinely ambiguous, low-risk content.

Frequently Asked Questions

Is PII detection just a big list of regular expressions?

No, not for entities like names and addresses because those are detected through named entity recognition, a machine learning approach that identifies entities from context and language structure rather than matching a fixed pattern. Regular expressions remain the right tool for structured identifiers with a fixed format, like credit card numbers or API keys, but they can't reliably catch free-text entities like names, which is why a real detection engine needs both approaches, not one applied everywhere.

What is Microsoft Presidio?

Presidio is Microsoft's open-source framework for detecting and anonymizing sensitive data, using named entity recognition to identify categories like names, locations, and dates in unstructured text. It's a widely used foundation for PII detection specifically because building an accurate NER model from scratch is a substantial undertaking that most organizations reasonably build on top of rather than duplicate.

Why do credentials need a different detection method than PII?

Because credentials follow fixed, predictable formats like a specific prefix, length, or character structure that a regular expression can match with high precision and low computational cost. Applying a language-understanding model to a problem that's really about exact structural matching adds overhead without improving accuracy, the same way using a regex to find a person's name would miss nearly every real-world case.

What are the eighteen HIPAA Safe Harbor identifiers?

They're the specific categories of information that must be removed for health data to qualify as de-identified under HIPAA's Safe Harbor method, including names, geographic subdivisions smaller than a state, dates more specific than year, phone and fax numbers, email addresses, Social Security numbers, medical record numbers, and several other identifier categories defined in the regulation. A scanner built to detect all eighteen categories is doing meaningfully more than generic PII detection, since several of these categories (like geographic subdivisions or dates) require healthcare-specific handling that a general-purpose PII scanner wouldn't necessarily cover.

What does it mean when a detection is "below the confidence threshold"?

It means the scanner found something that matched its detection criteria, but with a confidence score lower than the level configured to trigger enforcement. Rather than being discarded, this kind of detection is still recorded in the audit log as a soft detection which is useful for later review or threshold tuning, without interrupting the employee's task or altering the prompt.

Can a single prompt trigger multiple scanners at once?

Yes, and this is common because a single prompt might contain a customer's name (caught by NER), a credit card number (caught by a pattern scanner), and language resembling a jailbreak attempt (caught by an intent scanner) all at once. When this happens, the highest-severity triggered result determines the actual enforcement outcome applied to the prompt, rather than each scanner's result being applied independently.

Does adding more scanners to a policy slow down every request?

Not proportionally, because scanners don't all run the same way. Pattern and keyword-based scanners are inexpensive and run synchronously against every request. Scanners that require a language-model inference call are typically invoked more selectively, either because they're configured to always run, or because cheaper scanners have already raised a prompt's risk profile enough to warrant the additional check, which keeps the typical request fast while still allowing deeper evaluation when it's actually warranted.

Detection Accuracy Is the Foundation Everything Else Depends On

Redaction, warnings, and blocking all depend on one thing happening correctly first: the system has to actually recognize that something sensitive is present, and recognize it as the right type of sensitive data, not just a generic flag. A detection engine that only knows how to pattern-match will miss the majority of PII and PHI, which doesn't follow fixed formats. A detection engine that only understands language context will be slower and less precise at catching credentials and structured identifiers that a regular expression handles perfectly well.

Getting this layered correctly; NER for what varies, pattern matching for what doesn't, isn't an implementation detail buried behind the more visible parts of an AI data protection product. It's the foundation the entire policy engine, every redaction decision, and every audit log entry is built on top of.