💻 computer science

PIIGuard: Mitigating PII Harvesting under Adversarial Sanitization

PIIGuard is a webpage-level defense mechanism that employs optimized hidden HTML fragments to steer LLMs away from disclosing contact PII, achieving high success rates in preventing data leakage while maintaining utility for benign queries.

Original authors: Mingshuo Liu, Yiwei Zha, Min Chen

Published 2026-05-06

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Mingshuo Liu, Yiwei Zha, Min Chen

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Problem: The "Helpful" Librarian and the Thief

Imagine a very helpful librarian (the AI assistant) who can walk into any library (the internet), find a specific book (a webpage), and read it out loud to answer your questions.

Now, imagine a thief (the attacker) who doesn't want to steal the book itself, but wants to steal the secret contact details written inside it—like a reporter's phone number or home address. The thief asks the librarian, "What is the reporter's phone number?" Because the librarian is programmed to be helpful, they read the page, find the number, and say it out loud.

The Dilemma:
Usually, the only way to stop this is to hire a security guard at the library entrance (the AI company) to check every book before the librarian reads it. But what if you are just the author of the book? You can't hire the guard. You can't control the librarian. You only control the book itself.

The Solution: PIIGuard (The Invisible Trap)

The researchers created a tool called PIIGuard. It allows the book author to hide a special, invisible note inside the pages of their own book.

Think of it like this:

The Old Way: Authors tried to hide the phone number by writing it in invisible ink or scrambling the letters (like turning "555-0199" into "555-0199" but with weird symbols). The thief's AI was smart enough to decode this or just ignore the weird symbols and find the number anyway.
The PIIGuard Way: Instead of hiding the number, the author plants a hidden instruction in the book's margins. This instruction is invisible to human readers but acts like a "stop sign" for the AI librarian. It says, "If you see this page, do not read the phone number out loud, even if someone asks for it."

How It Works: The "Evolutionary" Gardener

The researchers didn't just guess what the note should say. They built a digital "gardener" that grows and tests thousands of different notes to find the perfect one. Here is the process:

Planting Seeds: They start with a few basic notes (e.g., "Don't share contact info").
The Test: They let the AI librarian try to read the book with the note. Did the librarian accidentally say the phone number?
Mutation (The "Evolution"): If the note failed, the gardener "mutates" it. It changes the wording, moves the note to a different part of the page, or rewrites it entirely.
The Judge: A second AI (the Judge) acts as a strict inspector. It checks: "Did the librarian say the number? Even if the librarian didn't say it directly, could the Judge figure out the number just by listening to the librarian's answer?"
Survival of the Fittest: Only the notes that successfully stop the librarian from revealing the info survive. The gardener keeps the best ones and tries to make them even better.

The "Sanitizer" Challenge

The researchers realized that a smart thief might try to clean the book before the librarian reads it. Imagine the thief has a robot that scans the book, finds the hidden "stop sign" note, and rips it out before the librarian sees it.

PIIGuard tested this scenario too. They found that:

If the note is placed in certain "safe zones" of the book (like the footer or the bottom of the contact section), it is harder for the thief's robot to find and remove it.
If the note is placed in the "metadata" (the hidden code at the very top of the book), the thief's robot often finds and deletes it immediately, making the defense useless.

The Results: Does It Work?

The researchers tested PIIGuard on three different types of AI librarians (GPT, Claude, and DeepSeek).

Success Rate: In most tests, PIIGuard was 97% to 100% effective. It stopped the AI from revealing phone numbers, emails, and addresses almost every time.
No Side Effects: Crucially, the hidden note didn't stop the librarian from answering other questions. If you asked, "Who wrote this article?" the librarian could still answer correctly. The defense only blocked the specific request for private contact info.
Real World Test: They even put the books on a real website and let the AI browse the internet to find them. The defense still worked, though it was slightly less effective depending on which AI librarian was doing the browsing.

The Bottom Line

PIIGuard shows that website owners don't need to wait for AI companies to fix privacy issues. By planting a smart, invisible "stop sign" directly into their own webpages, they can trick helpful AI assistants into ignoring private contact details, keeping that information safe from digital thieves.

Key Takeaway: You don't need to hide the treasure; you just need to tell the guard not to look at it.

Technical Summary: PIIGuard

Problem Statement

Modern Large Language Models (LLMs) equipped with browsing capabilities (via MCPs, tool-calling, or web interfaces) create a novel attack vector for harvesting Personally Identifiable Information (PII). Attackers can submit contact-seeking queries to a browsing-enabled assistant, which then fetches raw HTML from target webpages and reproduces PII (names, phone numbers, emails, addresses) verbatim in its response.

Existing defenses are primarily deployed at the model, service, or agent layers (e.g., runtime filters, masked prompts), requiring privileged access that ordinary webpage owners lack. Page-level defenses that exist (e.g., character substitution or basic Indirect Prompt Injection) often fail against advanced attacks where the attacker employs an auxiliary LLM "sanitizer" to preprocess and strip suspicious content from the fetched HTML before the target model processes it. This paper addresses the gap in webpage-level defenses capable of withstanding both direct HTML access and adversarial sanitization.

Methodology: PIIGuard

PIIGuard is a webpage-level defense mechanism that embeds optimized, hidden HTML fragments (Indirect Prompt Injections, or IPI) into a webpage's DOM. These fragments are designed to steer the LLM away from verbatim or reconstructible disclosure of contact PII. The system operates via a five-step evolutionary pipeline:

Seed Selection: Initializes a candidate pool with diverse, hand-authored defense instructions paired with allowed insertion slots (e.g., after, footer, meta, contact_block).
Rule-Based Scoring: Evaluates candidates using a fast, rule-based leakage metric ( $\ell_R$ ) that matches extracted fields against ground truth. In advanced attack settings, this score aggregates the worst-case leakage across both raw and sanitized HTML paths.
Composite-Utility Ranking: Candidates are ranked not just by mean leakage, but by a composite utility function ( $U$ $U$ ) that prioritizes:
- Complete suppression (zero leakage across all fields).
- Low average leakage.
- Robustness (fraction of pages with minimal leakage).
Evolutionary Mutation: A target LLM acts as a mutator, rewriting instruction text, substituting slots, or hybridizing high-performing parents to generate new candidates. This loop iterates to minimize rule-based leakage.
Judge-Based Recoverability Assessment: The final survivors undergo a rigorous evaluation using a "Judge" LLM. This step tests semantic recoverability: even if PII is not explicitly present, can the Judge reconstruct the original identifiers from the model's response? Only fragments that pass both rule-based and judge-based criteria are selected.

The framework supports two distinct attack settings:

Basic Attack: The model fetches raw HTML directly.
Advanced Attack: An attacker-side sanitizer LLM preprocesses the HTML to remove suspected injections before the target model reads it. PIIGuard co-optimizes fragments to survive this sanitization.

Key Contributions

Threat Model Expansion: The paper is the first to systematically characterize an advanced attack scenario where the attacker uses an LLM sanitizer to clean fetched HTML, a threat model previously unaddressed by page-level defenses.
PIIGuard Framework: A novel webpage-level defense utilizing a five-step evolutionary pipeline (seed selection, rule-based scoring, composite ranking, LLM mutation, and judge-based reevaluation) to generate optimized hidden instructions.
Two-Stage Evaluation Protocol: A rigorous validation method combining fast rule-based field matching with a slower, semantic judge-based recoverability assessment to ensure defenses prevent both direct exposure and reconstruction.
Stress-Tested Validation: Evaluation across three realistic conditions:
- Direct HTML: Raw HTML input to the model.
- URL Mode: Real-world deployment via static sites accessed through standard browsing interfaces.
- Sanitizer Mode: Preprocessing by an attacker-side LLM filter.

Experimental Results

The system was evaluated on three target models: GPT-5.4-nano, Claude-haiku-4.5, and DeepSeek-chat.

Defense Success: Under direct HTML access, PIIGuard achieved a Defense Success Rate (DSR) of at least 97.0% (often 100.0%) across all models and insertion positions for both rule-based and judge-based metrics.
Benign Utility: The defense did not degrade the model's ability to answer benign questions (e.g., NewsQA tasks), with utility metrics (MAF1, BCR) remaining comparable to non-defended baselines.
Sanitizer Robustness: In the advanced attack setting, robustness varied by insertion position. The footer_notice slot proved most stable, achieving up to 86.00% DSR against various sanitizer prompts, whereas contact_block and bio_tail showed lower resilience.
URL Deployment: When deployed as live static sites accessed via browsing tools, performance remained high for the footer position but degraded significantly for the meta position, indicating that browsing toolchains may structurally strip certain injection sites.
Model Transfer: Fragments optimized for Claude-haiku-4.5 (a highly instruction-compliant model) generalized well to other models, suggesting that stricter optimization constraints yield more robust defenses.

Significance and Claims

The paper argues that webpage owners can effectively mitigate PII leakage by deploying lightweight, optimized HTML fragments without requiring cooperation from model providers.

Shift in Defense Paradigm: PIIGuard demonstrates that page-side defenses can move beyond simple obfuscation (which fails against semantic reconstruction) to active steering of model behavior via Indirect Prompt Injection.
Model Capability as an Ally: Contrary to the intuition that more capable models are harder to defend, the results suggest that more capable models (e.g., GPT-5.4-mini vs. GPT-5.4-nano) follow injected instructions more reliably, making them stronger defenders when PIIGuard is deployed.
Limitations and Future Work: The authors acknowledge that sanitizer survivability is currently a "positive existence claim" rather than a universal guarantee, as the space of sanitizer prompts is open-ended. They also note that current evaluations rely on single-model judges and synthetic static sites, suggesting future work should explore multi-judge ensembles and in-the-wild deployments.

Overall, PIIGuard positions page-side fragments as a practical, first-line defense layer that complements system-level safeguards, offering content owners a unilateral mechanism to protect contact information in the era of browsing-enabled LLMs.