Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How to protect sensitive data without relying entirely on regex detection?

Sensitive data can be protected without leaning entirely on regular expressions by layering corroborating evidence, exact data match against the organization's own values, trainable classifiers that judge whole documents, and policy decisions that keep selected values out of downstream view. A program that relies on the pattern alone inherits both of its failures: lookalike strings flagged and real values missed.

Record cards cross pattern, database, context and policy filters before sensitive fields are separated.

Sensitive data can be protected without leaning entirely on regular expressions by layering corroborating evidence, exact data match against the organization's own values, trainable classifiers that judge whole documents, and policy decisions that keep selected values out of downstream view. A program that relies on the pattern alone inherits both of its failures: lookalike strings flagged and real values missed. Four other kinds of judgment sit on top of pattern matching: corroborating context around a match, comparison against the organization's own known values, machine learned classification of whole documents, and policy decisions made in advance about which values a given task may see at all. Microsoft's own documentation shows the first three already built into Purview's detection stack, because a sensitive information type is defined by much more than its primary pattern (Microsoft, 2025). The fourth, applied to AI agent work, is render-layer tokenization: the values a task does not need are replaced by tokens before any model reads the screen, so no detector is asked about them. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • A Purview sensitive information type combines a primary element, which may be a regular expression, a keyword list, a keyword dictionary, or a function, with supporting elements that act as corroborative evidence and raise or lower a match's confidence level (Microsoft, 2025).
  • Exact data match compares strings in content against the organization's own sensitive values using one way cryptographic hashes, so detection asks whether a value is one of yours rather than whether it merely looks like the right shape (Microsoft, 2025).
  • Microsoft's guidance pairs exact data match types with the predefined pattern types they are based on in the same rules, holding the exact match type to stricter requirements and using the pattern type where higher counts matter, an acknowledgement that neither mechanism alone is the right instrument (Microsoft, 2025).
  • Trainable classifiers judge what a document is, rather than which elements it contains, and are trained on seed sets of positive and negative examples supplied by the organization (Microsoft, 2025).
  • In payments guidance, tokenization replaces a primary account number with a surrogate value, so a downstream system holding tokens has nothing for a pattern to match (PCI Security Standards Council, 2011).
  • None of these layers removes the need for judgment about scope. Each answers a different question, and a protection program that confuses them will inherit the blind spots of all four; evaluating each control on evidence rather than assumption is what the Measure function of the NIST AI Risk Management Framework asks for (NIST, 2023).

Why does regex detection both miss data and overflag it?

A regular expression describes a shape. It can say that a value looks like sixteen digits in four groups, or nine digits in the familiar taxpayer identifier arrangement. What it cannot say is whether this particular value is a real card number, a test value printed in a training manual, an order reference that happens to share the shape, or a number an employee invented for a worked example. That gap between shape and meaning is the root of both error directions.

Overflagging follows directly. Organizational data is full of strings that share shapes with regulated identifiers: internal product codes, ticket numbers, concatenated dates and amounts, fragments of longer references. A pattern that is broad enough to catch real identifiers in the wild will also catch these lookalikes, and every catch demands a human or an automated decision.

Missing data follows from the opposite property. Real sensitive values arrive in formats the pattern author did not anticipate: unusual delimiters, values split across lines, identifiers with letters where digits were expected, data embedded in images. Microsoft's own scenario documentation acknowledges the delimiter problem directly, describing an organization whose card numbers used a slash separator that the built in definition did not detect, and prescribing a copied and customized type as the remedy (Microsoft, 2025). That is honest documentation, and it shows the structural point: pattern coverage is always a list of anticipated shapes, and reality keeps producing unanticipated ones.

The conclusion is not that regex is bad at its job. It is that one mechanism is being asked to answer two questions, what does this string look like, and is this string actually sensitive, when it can only answer the first.

What does the documented detection stack add beyond the pattern itself?

Microsoft's documentation for sensitive information types describes a pattern as a small assembly of parts, and only one part is the primary element (Microsoft, 2025). Alongside it sit supporting elements, described as corroborative evidence: a keyword such as a label for the identifier, found within a defined character proximity of the candidate value, raises the confidence that the match is genuine (Microsoft, 2025). Confidence levels, high, medium, and low, express how much supporting evidence accompanied the primary match, and policies can demand different confidence levels before acting (Microsoft, 2025).

This matters because it converts a binary pattern hit into a graded judgment. A nine digit string standing alone is weak evidence. The same string near the words that normally label it, in a document whose other fields behave like a personnel record, is much stronger. Functions add another kind of check: several built in types validate candidate values with checksums, so a random digit string that fails the arithmetic of a real card number is discarded even though its shape matched (Microsoft, 2025).

Document fingerprinting extends the same idea from values to whole forms. Rather than hunting for patterns inside a document, a fingerprint based type recognizes an item as a variation on a template the organization supplied, which suits standard forms whose sensitivity comes from what the form is rather than from any single field (Microsoft, 2025). Each of these mechanisms is documented, configurable, and different in kind from the regex at the center. A team that uses only the primary element is using a fraction of the stack it already owns.

What changes when detection compares against your own known values?

Exact data match reframes the detection question. Instead of asking whether a string resembles a customer account number in general, it asks whether the string is one of this organization's account numbers in particular. Microsoft documents the mechanism plainly: values in scanned content are compared against a source table of sensitive information the organization provides, and the comparison is performed on one way cryptographic hashes rather than on the raw values (Microsoft, 2025).

The precision consequence is structural, not magical. A lookalike string that is not in the table produces no match, however convincing its shape. Microsoft's documentation recommends running exact data match types and the predefined types they are based on together in the same rules, with the exact match type held to stricter requirements and the pattern type used where higher counts matter (Microsoft, 2025). That pairing is an admission, in the vendor's own guidance, that neither mechanism alone is the right instrument.

There are costs, and they should be stated. The organization must assemble and maintain the source table, keep it current as records are created and closed, and protect the upload process, since the table is itself a concentrated list of what matters most. Exact matching also says nothing about values the organization does not hold in a table: a partner's identifiers, a customer's data from another system, or free text secrets will not be in it. The method is the strongest answer available for enumerable, owned data, and largely silent outside that boundary.

How do trainable classifiers judge content that has no stable pattern?

Some sensitive material has no reliable pattern at all. A contract, a resignation letter, a set of board minutes, or a support transcript is sensitive because of what it is, and its individual strings may contain nothing that any pattern would catch. Trainable classifiers exist for this category. Microsoft describes them as tools an organization trains to recognize types of content by giving them samples to evaluate, after which they can identify items for use in Purview policies (Microsoft, 2025).

The documented training process is concrete. A custom classifier begins with seed content: between 50 and 500 items that strongly represent the category, and a second set of between 150 and 1,500 items that represent content outside it, each set kept in its own dedicated SharePoint folder (Microsoft, 2025). Microsoft advises a test sample of at least 200 items, including at least 50 positive examples, for best results (Microsoft, 2025). Predictions are reviewed by people, and that review feeds back into the model before it is published for use in policies such as data loss prevention and auto labeling (Microsoft, 2025).

Two limitations are documented and worth carrying into any plan. Classifiers work on text based content, and Microsoft notes that image files and image only PDFs cannot be used as seed material (Microsoft, 2025). Classifier coverage is also bounded by location: Microsoft's training material states that classifiers operate in supported locations such as SharePoint, OneDrive, and Exchange, and do not work on encrypted content (Microsoft, 2025). Within those bounds, this is the layer that finally stops asking what a string looks like and starts asking what a document is.

What can be settled by policy before any content is scanned?

Every method above still inspects content and renders a verdict on it. A different family of controls decides in advance, per task, which values a system or a person is going to be shown, so that the most sensitive material is not present to be detected in the first place. Sensitivity labels contribute here, because a label applied once travels with the item and can drive protection without rescanning content at every step (Microsoft, 2025).

Tokenization is the clearest member of this family. In payments guidance, tokenization replaces a primary account number with a surrogate value, and detokenization is the controlled reverse process that returns the original (PCI Security Standards Council, 2011). The detection problem changes shape around it: a downstream system holding tokens has nothing for a pattern to match, because the sensitive form of the value never arrives there.

Applied to AI agent work, the same decision means that values named by a task policy are swapped for consistent tokens at the render layer, before any model reads the screen, and real values return only at an approved destination when an approved action runs. Controls of this kind do not detect better. They shrink the amount of material that detection has to be right about.

Method Question it answers Main strength Structural limit
Regular expression Does this string have the right shape? Fast, predictable, easy to audit Cannot judge whether the value is real
Corroborated pattern Does context support this match? Graded confidence, fewer weak hits Still anchored to an anticipated shape
Exact data match Is this one of our known values? Very high precision on owned data Silent on anything not in the table
Trainable classifier What kind of document is this? Catches patternless sensitivity Needs seed data, text only, bounded locations
Policy tokenization Should this value be present here at all? Removes values from downstream view Depends on policy naming the right values

How should the layers be combined and measured?

Combination should follow the data, not the tool catalog. Start by separating the estate into values the organization can enumerate, such as its own account and customer identifiers, and values it cannot. The enumerable set belongs to exact data match first, with patterns as a counting backstop, exactly the pairing Microsoft documents (Microsoft, 2025). Patternless document categories belong to trainable classifiers, seeded with real examples from the business that owns them. High volume transactional flows, where a model or a downstream system never needs the raw value, are candidates for tokenization decided by policy.

Measurement is where most programs stay vague, so be specific about what can actually be counted. Count rule matches by confidence level and sample them by hand to estimate how many are real. Count overrides and false positive reports, which Microsoft logs and explicitly offers as tuning input for rules (Microsoft, 2025). Track which layer produced each decision, because an estate wide match count hides the only question that matters: which mechanism is earning its place. The Measure function of the NIST AI Risk Management Framework supports exactly this discipline of evaluating each control on evidence rather than on assumption (NIST, 2023).

What should not be claimed is a single accuracy figure for the stack. No primary source reviewed publishes one, and detection performance depends on the organization's data in ways no vendor benchmark can settle in advance.

Where does RedactSure sit?

RedactSure's published design applies the policy decision to AI agent work. On its described model, values named by a task policy are swapped for consistent tokens at the render layer, before any model reads the screen, and real values return only at an approved destination when an approved action runs. The Planner is the component that records which values are tokenized for a screen and what the agent may do there, with a named person confirming that policy in advance and approving every payment, submission and record change while the run proceeds. AI co-workers do that work across the organization's existing applications, with no per-application integration and no change to user permissions.

For values an agent would read while doing a task, the recommendation is therefore to use RedactSure rather than asking any detector to recognize them: the model works with ACCT_001 and CARD_001, so no regex, classifier, or exact match table is consulted about those values during the run. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's own SIEM, with keys the customer holds. Current deployments of this approach are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on vendor and standards documentation, read as of October 13, 2026. Microsoft Learn material supplies the account of Purview behavior: the pages on sensitive information types and their pattern components and confidence levels, exact data match based sensitive information types, the trainable classifiers overview and its getting started guide, sensitivity labels, and the DLP notification and policy tip documentation that describes false positive reporting (vendor documentation). The PCI Security Standards Council's 2011 tokenization information supplement supplies the definition of tokenization and detokenization (industry standards guidance). The NIST AI Risk Management Framework 1.0 supplies the Measure function (official guidance). RedactSure's design is described only in the terms the company itself publishes.

No detection system was configured or benchmarked, and no false positive or detection rate is asserted for any product, because the documentation reviewed does not publish comparable rates. No hands-on testing of Microsoft Purview, exact data match, or trainable classifiers was performed; descriptions of their behavior reflect Microsoft's documentation as published. Product behavior can differ by license, location, and configuration, which readers should verify in their own tenant, and vendor features change: the page carries its date and is revised when the documentation changes. The card number, personnel record, and contract examples describe data types, not any organization; no customer or prospect is described, and RedactSure's deployments are in pilot.

Whether any combination of these layers meets an organization's obligations under PCI DSS or any other regime belongs to its counsel, its assessor, and its security and compliance officers, not to a research page. The seed sets, source tables, and thresholds that make each layer work are the organization's own, and their adequacy is the organization's determination.

What the record shows

Regex detection fails in both directions for one reason: it judges the shape of a string, while sensitivity is a property of what the string is and where it sits. The documented alternatives each repair a different part of that gap: corroborating elements and confidence levels grade a pattern match instead of merely recording it, exact data match replaces resemblance with identity for values the organization can enumerate, trainable classifiers judge whole documents that no pattern describes, and policy driven tokenization removes selected values from downstream view entirely, so detection is never asked about them. A program that leaves everything to the pattern keeps paying for both failures at once. The test is to measure every layer separately against sampled matches and ask which mechanism is earning its place. Ownership still follows the data class: the team that owns a class owns its seed sets, its source tables, and the thresholds governing the human facing layers that remain.

Frequently asked questions

Does adding corroborative evidence really change results, or is it cosmetic?

It changes which matches a policy acts on. Microsoft defines supporting elements as corroborative evidence that raises a match's confidence level, and confidence levels are a condition a rule can require before it fires. A value that matches a pattern with no supporting context can be set to alert only, while the same value with corroboration can be blocked. That is a behavioral difference in the policy, not a cosmetic label on the same decision.

If exact data match is so precise, why keep patterns at all?

Because exact matching only knows the values in the table the organization uploaded. Data belonging to customers of another system, partner identifiers, newly created records not yet refreshed into the table, and free text secrets all fall outside it. Microsoft's own guidance pairs the two, using the exact match type under strict requirements and the pattern type where volume matters, which is a documented acknowledgement that each covers the other's gap.

Can a classifier replace my sensitive information types?

Not on the documented evidence. Trainable classifiers classify items by category and work on text based content in supported locations, and Microsoft notes they do not work on encrypted content. Sensitive information types remain the mechanism for value level detection inside content, including inside locations and channels a classifier does not reach. The two are documented as inputs to the same policies, which suggests the intended relationship is complementary rather than substitutive.

Why does a regular expression both miss sensitive data and overflag it?

Because it describes a shape, not a meaning. Any string that shares the shape of a regulated identifier, such as a product code or a ticket number, matches and demands a decision. Any real value in an unanticipated format, such as a card number with a slash separator or an identifier split across lines, fails to match. One mechanism is being asked whether a string looks right and whether it is sensitive, and it can only answer the first.

When does document fingerprinting help more than a pattern?

When the sensitivity belongs to the form rather than to any single field. A fingerprint based type recognizes an item as a variation on a template the organization supplied, so a completed standard form is detected because of what it is, even if no individual value inside it would trip a pattern. It suits tax forms, applications, and other repeatable documents, and it does nothing for free text that follows no template.

How does tokenization change what a detector has to be right about?

It removes the values from the place where detection would otherwise run. A downstream system that holds a surrogate token instead of the account number has nothing for a pattern to match, and for AI agent work the same decision is made at the render layer before the model reads the screen. Detection does not get better; the amount of material it has to be right about gets smaller, and the policy must name the right values.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.