Every team that generates HTML eventually ships something it shouldn't have. Not a breach — a lead list with three phone numbers still in the footer, a proposal with a test API key in a script tag, a training page that quotes a customer email verbatim. The tooling question that follows is always the same: what kind of PII scanner do we put in front of publishing, and what will it actually catch?
Two families of scanner, two different blind spots
Sensitive data detection splits cleanly into two approaches, and they fail in opposite directions.
Deterministic pattern matching (regex). A rules engine looks for structured formats: email addresses, phone numbers, credit card numbers with a valid checksum, Social Security and passport numbers, dates of birth, street addresses, API keys and bearer tokens. If the data has a shape, this catches it. It runs in milliseconds, on the same box, with no network call. It's auditable — you can point a compliance reviewer at the exact rule that fired. And on the formats it covers, false negatives are close to zero.
What it cannot do is read. "Regional VP of Procurement, Cleveland, two kids, currently evaluating vendors" contains no pattern at all, and it identifies a person to anyone who works in that market. Regex is blind to context and blind to combination.
AI/contextual scanning. A language model reads the document and reasons about what identifies a person. It catches the name-plus-role-plus-city problem, the anecdote that names a real deal, the paragraph where someone's medical situation is described without a single structured identifier. That's the gap, and it's a real one.
It also costs tokens per scan, adds seconds of latency to publishing, and is non-deterministic: the same document scanned twice can produce slightly different findings. And it raises the question your security reviewer will ask first — where does the content go, and under whose agreement is it processed?
The conclusion most teams reach after one incident is the correct one: run both. Regex is the floor you never turn off. AI is the layer you add when the content is unstructured enough that patterns alone won't defend you.
How the layered PII scanner works in HTMLvault
The base layer is regex, and it runs on every publish for every plan, including Free. It costs zero tokens and never sends your HTML to a model. It detects nine categories: ssn, financial, api_key, passport, address, person, dob, email, and phone. Findings are returned inline before the link exists, not after.
The AI layer sits on top and is available on Teams and Enterprise via BYOK — bring your own key. You connect your own Anthropic, OpenAI, or Google API key, and the contextual scan runs against your account with that provider. Two consequences follow, and both are things your security reviewer will care about:
- The content is processed under your model agreement, not a vendor's. Whatever data-handling terms you already negotiated with your AI provider are the terms that apply. Nothing new to redline.
- HTMLvault funds no tokens. Your scan spend is visible in your provider's billing console, at your rates, with your usage caps. There is no per-scan markup because there is no per-scan resale.
That answers the "where does the content go" question with a name your team already approved. If your organization has standardized on one model provider, contextual PII identification runs through that same provider and nowhere else.
Running a scan from the UI
The scan is not a separate step you remember to do. It's attached to publishing.
- Paste or generate your HTML in the content box on
/upload. - Click Create Link. The button reads Scanning… while a sweep animates over the content box.
- If the document is clean, you get a green strip: Scan complete — no sensitive data found, and the link publishes.
- If there are findings, a notification window appears under the options row with a Warning: Sensitive data detected group and one red pill per finding, each with its count —
SSN (3),EMAIL (12). - Click View sensitive data to open the Sensitive Data Found modal.
Inside the modal, a counts strip lists each detected type with its count, and a scrollable code pane shows your HTML with every match highlighted — remaining matches in red, the one you're on in yellow, anything already redacted in green. ← Prev and Next → walk you through them with an N of M position indicator. The Anonymize Data dropdown in the header is a checkbox menu — All, Name, Email, Phone, Card, SSN, Date of Birth, Passport — so you redact by category rather than one match at a time. Preview shows pending changes; Save applies them.
Once you publish, the success screen carries a PII scan card: a warning-style eyebrow reading PII scan — N finding type(s) with the finding badges, or a green PII scan — no sensitive data detected when the document came back clean. That card is your record of what the scanner saw at publish time.
A worked example: the lead list that shouldn't ship
An analyst exports 400 rows from the CRM, has an AI tool render them as a sortable HTML table, and pastes the result in to share with the field team. It looks like a report. It contains contact emails, direct-dial numbers, one column of account notes someone typed a partial card number into two years ago, and — because the export template was never cleaned up — a service token in a commented-out script tag at the bottom.
Click Create Link and the regex layer returns four finding types: email (400), phone (317), financial (1), api_key (1). Open the modal, check Email and Phone under Anonymize Data, and 717 matches become placeholder tokens in one action. Walk the remaining two with Next →: the card fragment gets redacted, the token gets deleted from the source entirely rather than masked, because a masked secret is still a secret you shipped. (For the deeper version of that workflow, see how to scan HTML for API keys before sharing.)
What regex will not flag in that same file: the notes column entry reading "spoke to the ops director in Austin, going through a divorce, timeline slipping." No pattern, real exposure. That's the row the AI layer catches, and the reason a serious PII software stack runs both.
Tuning: false positives, block versus warn
A scanner nobody trusts gets ignored, and an ignored scanner is worse than none. Three tuning decisions matter.
Handling false positives
Structured matching over-fires in predictable places: demo data that looks like real card numbers, a support email address that's meant to be public, sample phone numbers in a template. Don't fight the scanner on these — fix the input. Use obviously fake sample data (555 numbers, example.com addresses), and keep public contact details in a footer partial your team reuses rather than retyping them. The finding count on the success card should be a number you can explain, not one you scroll past.
Block versus warn
Organizations on Teams and Enterprise can set a scan policy that decides what a finding does. Three outcomes:
- Warn. The findings window appears with its red pills; the Create Link button relocates into that window with the caption *I acknowledge this is ok to publish. The publisher makes a deliberate choice instead of an accidental one.
- Acknowledge. A separate amber group appears — Acknowledgment required by your organization's scan policy — with category pills and an I acknowledge — enable publish button. Same publish, recorded consent.
- Block. A red Blocked box states that your organization's scan policy blocks this content, lists each category with its count, and shows a Risk score: line followed by the score and the instruction to redact the flagged items to publish. Publishing is unavailable until the findings are gone.
Reserve hard blocks for categories where there is no legitimate case — ssn, api_key, passport. Warn on email and phone, which are frequently intentional in sales content. Blocking everything trains people to route around the tool, which is the failure mode that produces shadow IT in the first place.
Separately, HTMLvault checks outbound links against Google Safe Browsing. If the HTML contains a flagged URL, an Unsafe links detected box names the threat types and publishing is blocked outright — that one isn't configurable, because the risk is to your recipient.
The PII policy gate on programmatic publishing
Most sensitive HTML now gets created by a tool, not a person: Claude via MCP, a Custom GPT action, a Zapier step, a Clay enrichment table, or a direct call to the REST API. A scanner that only exists in the browser is a scanner that half your volume bypasses.
The PII API surface mirrors the UI. scan_html runs the scan without publishing anything — useful when an agent wants to check its own output and revise before creating a link. create_link and create_links run the same policy on the way in: warn categories return findings alongside the created link, block categories return an error with the finding types and counts, and no link is created. Same rules, same categories, same policy, regardless of which client called.
Two practical notes. Give automations their own API keys rather than reusing a human's, so a blocked publish is attributable to a specific integration. And handle the block response in the automation itself — an agent that retries the same payload three times produces three identical audit entries and no link.
Limits worth knowing before you buy
- Regex covers formats, not judgment. The nine categories are the nine categories. A regional identifier scheme outside them won't fire.
- The AI layer needs a key. BYOK is Teams and Enterprise. Without a connected Anthropic, OpenAI, or Google key, you're running regex only — which is a defensible position, just a documented one.
- AI findings vary between runs. Don't design a control that assumes identical output on re-scan. The deterministic layer is what you cite in an audit.
- Scanning is a publish-time control, not a permanent one. Edit a live link and it re-scans. Pair scanning with link expiry and a retention window so content that passed the scan doesn't sit exposed indefinitely.
- Rendered output only. The scanner reads the HTML you submit. Data pulled in client-side after load isn't visible to it.
For the wider evaluation frame, sensitive data discovery software covers what to test before you commit, and what PII privacy actually means is a useful primer for stakeholders who haven't had to define it yet.
Why this matters for the person approving the tool
The IT or security lead reviewing a sharing tool is usually asked to approve a vibe: everyone likes it, it's fast, please sign. That's an unpleasant position, because the thing you can't describe is the thing you get blamed for.
A layered scanner replaces the vibe with a control you can write down: a deterministic regex pass on nine named categories that runs on every publish and costs nothing to operate, an optional contextual pass under your own model agreement with your own provider, a policy that blocks the categories you can't defend and records an acknowledgment on the ones you can, and identical enforcement whether the HTML came from a browser or an agent. That's a paragraph in a security review, not a shrug.