PII Data Discovery: Finding Sensitive Fields Before They Reach a Shared Link

That gap is the problem with how PII data discovery is usually practiced. The tooling is excellent at inventorying databases, object storage, and laptops. It is structurally blind to a file that did not exist this morning and will be public by lunch. This guide argues for a third scan surface — publish time — and walks through how to actually operate one.

What PII data discovery actually means

PII data discovery is the practice of finding personally identifiable information wherever it lives, classifying it, and deciding what happens next: redact, restrict, delete, or accept. PII is any data that identifies a person on its own or in combination — a name, an email, a phone number, a passport number, a home address, a date of birth, a Social Security number.

Two jobs hide inside that one phrase, and conflating them is where programs go wrong:

• Inventory — what sensitive data do we hold, and where? This is a mapping exercise, run on a schedule, owned by governance. It answers audit questions.
• Interception — is sensitive data about to leave our control right now? This is a gate, run per artifact, owned by whoever hits publish. It answers the incident question.

Most PII discovery tools sold as enterprise platforms do the first job well. They were built when sensitive data moved slowly, in bulk, between systems that IT provisioned. The second job needs a different shape entirely: fast, synchronous, and sitting exactly where content becomes a URL.

The three scan surfaces

Think of coverage as three surfaces rather than one product category. Each catches a different failure, and none of them substitutes for the others.

At rest

Warehouses, data lakes, buckets, shared drives, endpoints. Scanning is scheduled and thorough. It produces the map: which tables carry identifiers, which buckets are misclassified, which laptop has a CSV from 2019. Strength: completeness. Weakness: latency. A scan that runs nightly cannot stop something that was created and shared inside forty minutes.

In transit

Email gateways, DLP proxies, CASB inspection of uploads. This catches the file crossing a network boundary. Strength: it sees movement. Weakness: it sees movement it recognizes. Content generated inside an AI tool and posted to a sharing service over plain HTTPS often looks like ordinary web traffic, and a proxy that inspects attachments has nothing to open.

At publish

The moment a person or a script turns a blob of HTML into a link someone else can open. This is the narrowest, highest-signal checkpoint in the whole chain: you have the full artifact, you have the human who made it, and nothing has been distributed yet. It is also the one most organizations have never instrumented, because until recently there was nothing to instrument — content went into a document system that IT already scanned.

That assumption broke when generation got cheap. A rep can now produce a formatted, credible-looking dashboard from a CRM export in under two minutes, and the artifact never touches a sanctioned repository on its way out the door.

What regex catches, and what it doesn't

Publish-time scanning has to be fast enough that nobody routes around it. That rules out sending every draft to a model and waiting. So the first pass is pattern matching, and it is better than its reputation.

HTMLvault's scanner runs regex across nine categories — SSN, financial account numbers, API keys, passport numbers, street addresses, person names, dates of birth, email addresses, and phone numbers. It runs locally, in milliseconds, and costs zero tokens. Structured identifiers are exactly what patterns are good at: a Social Security number has a shape, an API key has a prefix and an entropy profile, an email has an unambiguous grammar.

What patterns miss is context. Three examples:

• Quasi-identifiers. "VP Finance, 400-person logistics firm, Tulsa, started March" contains no regex-matchable field and identifies roughly one person.
• Prose-embedded facts. A deal-notes paragraph reading "her husband's diagnosis is why renewal slipped to Q3" is health information in a sales artifact. No pattern fires.
• Aggregation risk. A column of job titles and a column of ZIP codes are each innocuous. Side by side in a twelve-row table, they re-identify.

This is the honest boundary of sensitive data detection by pattern, and it is why the second layer exists. On Teams and Enterprise you connect your own Anthropic, OpenAI, or Google API key and an AI pass runs on top of the regex results, reading for the contextual cases above. Tell your finance team up front: you supply the key and you pay for the tokens. HTMLvault funds none of it. That is a deliberate design choice — your prompts run against your account, under your model provider's terms, with no third-party token budget shaping how much scanning you get.

Worked example: a lead list inside a generated dashboard

The workflow end to end, using the churn-risk dashboard from the intro.

1. Generate. A CRM export goes into an AI tool with a prompt like "build a churn-risk dashboard from this." The model returns HTML with a table, a few charts, and an account-notes column it faithfully preserved.
2. Scan before creating the link. Call scan_html via MCP or the REST API. The regex pass returns findings by category with locations. In our example: nine email, fourteen phone, four address, and one api_key — a stray internal endpoint token the model copied out of a sample fetch call.
3. Run the AI pass. With a BYOK key connected, the second layer reads the notes column and flags two rows: one naming a contact's medical leave, one describing a named individual by role, region, and headcount precisely enough to identify them. Neither matched a pattern.
4. Remediate. Drop the notes column, delete the token, regenerate. Rescan. Clean.
5. Publish with controls. Create the link with an expiry that matches the review cycle, a password if it is leaving the building, and a retention window that disposes of the artifact on schedule. Every HTMLvault link is excluded from search indexing by default, so discovery never becomes a crawler's problem.

Steps two through five are one function call each, which matters more than it sounds: a checkpoint that requires opening another console gets skipped by the third week. Wire it into the tool that generates the HTML — MCP for Claude, the action schema for a Custom GPT, or the REST API from Zapier, Clay, or a script.

A coverage checklist for evaluating discovery tooling

If you are assessing sensitive data discovery software, most vendor comparisons will push you toward connector counts and classifier taxonomies. Those matter for the inventory job. For the interception job, ask these instead:

• Does it scan the artifact, or the store? If the answer is "we scan your S3 bucket," it has no opinion about a file that never lands in one.
• Is it synchronous? A scan that returns after the share is a post-mortem. It must block or warn before the URL exists.
• Is it callable from where content is made? If your team generates HTML in an AI assistant, the scan needs an API, a key, and ideally an MCP tool — not a web upload form.
• What is the per-scan cost model? Per-document pricing quietly teaches people to scan less. Pattern scanning should be free at the point of use; only the optional AI layer should have a marginal cost, and you should control it.
• What happens after a finding? Detection without a remediation path is a longer list, not less risk. Look for expiry, password, retention limits, and revocation attached to the same object you just scanned.
• Who can prove it ran? Teams and Enterprise give you audit logs and custom roles, which is what turns "we scan things" into something Compliance can defend in a questionnaire.

Two caveats, stated plainly. First, no scanner has a zero false-negative rate; publish-time PII identification reduces exposure, it does not eliminate judgment. Second, this surface complements at-rest discovery rather than replacing it — you still need the inventory to answer where data lives. The point is that the inventory was never going to catch the 10:04 link. For more on evaluating the category as a whole, see our breakdown of what discovery tools scan and what they miss, and the practical mechanics in scanning HTML for API keys before sharing.

Why this matters for the person running revenue operations

The RevOps lead is in an unfair position. They build the exports, dashboards, and lead lists that the rest of the company shares, and they carry the reputational risk when one of those artifacts contains something it shouldn't — without owning the security stack that would catch it. Historically their only real control was reading every row before sending, which does not survive contact with a Tuesday.

A publish-time checkpoint changes that. It puts a scan, a finding list, and a set of controls at the exact moment the artifact becomes shareable, callable from the tool that generated it, with a log that shows it happened. The report still goes out at 10:04. It just goes out knowing what is in it.