PrivacyLens-Live: Live Privacy Mediation

• PrivacyLens-Live is a multi-faceted research framework applied across programmable lensless imaging, dynamic LLM-agent evaluations, browser-level anonymization, and on-device image provenance verification.
• It integrates co-designed optics and classifiers, event-driven tool benchmarks, and local sanitization pipelines to provide actionable insights into mitigating privacy leakage.
• The systems demonstrate practical deployment with cost-efficient hardware, real-time performance, and significant reductions in privacy leakage via techniques like mask cycling and PII smokescreens.

Searching arXiv for papers mentioning “PrivacyLens-Live” and related “PrivacyLens”. PrivacyLens-Live is a research name used in multiple, distinct privacy-preserving system designs rather than a single canonical artifact. In the literature provided here, the name denotes: a fully programmable lensless camera that co-designs optics and a classifier for privacy-enhancing embeddings; a dynamic benchmark that converts static PrivacyLens cases into live MCP and A2A sessions for evaluating privacy leakage in LLM-powered agents; a browser-level PII redaction and smokescreen overlay inspired by PII Shield; and a privacy-first, on-device mobile framework for cryptographic image provenance and AI detection derived from Origin Lens (Bezzam et al., 2022, Wang et al., 22 Sep 2025, Holschneider et al., 26 Mar 2026, Loth et al., 3 Feb 2026). The term is therefore best understood as a family resemblance across live, privacy-aware mediation systems, with roots in the original PrivacyLens framework for evaluating privacy norm awareness of LLMs in action (Shao et al., 2024).

1. Scope and nomenclature

The uses of the name span several technical domains.

Usage of “PrivacyLens-Live”	Core function	Source
Programmable lensless camera	Privacy-enhancing optical embeddings for classification	(Bezzam et al., 2022)
Dynamic agent benchmark	Live MCP and A2A privacy evaluation for LLM agents	(Wang et al., 22 Sep 2025)
Browser overlay blueprint	Local entity anonymization and smokescreens for AI chats	(Holschneider et al., 26 Mar 2026)
Mobile verification blueprint	On-device provenance verification and AI detection	(Loth et al., 3 Feb 2026)

In the optical-imaging usage, PrivacyLens-Live is explicitly described as building on “Privacy-Enhancing Optical Embeddings for Lensless Classification,” extending that work into a fully programmable, lensless camera whose optics and classifier are co-designed for real-time task accuracy and visual privacy (Bezzam et al., 2022). In the LLM-agent usage, the term refers to a live benchmark that replays agentic tool-use trajectories in real time under MCP and A2A, motivated by the claim that static benchmarks fail to capture the noise and redundancy of real tool-call traces and the complexities of inter-agent communication (Wang et al., 22 Sep 2025). The browser and mobile usages are presented as technical blueprints that adapt the name to privacy-preserving front ends for AI interaction and image verification, respectively (Holschneider et al., 26 Mar 2026, Loth et al., 3 Feb 2026).

A common source of confusion is therefore terminological rather than methodological. The literature does not present a single, standardized PrivacyLens-Live stack. Instead, it reuses the name across systems that share an emphasis on live execution, privacy mediation, and deployment-facing architectures.

2. Lensless optical embeddings and live programmable imaging

In the lensless-imaging line, the forward optical model maps a scene $x \in \mathbb{R}^{H\times W}$ through a programmable amplitude mask $\phi \in [0,1]^K$ onto a low-resolution sensor. Under incoherent, polychromatic illumination and a linear shift-invariant assumption, the measurement is

$v = D\bigl(|H_{\phi}(x)|^2\bigr) + n,$

where $H_{\phi}(\cdot)$ denotes convolution with a PSF determined by $\phi$, $D(\cdot)$ is differentiable bilinear downsampling to sensor resolution, and $n$ is additive Gaussian noise set to $\mathrm{SNR}=40\,\mathrm{dB}$ (Bezzam et al., 2022). The PSF is computed via a scalar-diffraction, band-limited angular spectrum model, and gradients are back-propagated through both $D$ and $H_\phi$ by auto-differentiating the FFT-based wave-propagation model.

The training objective jointly optimizes the mask and classifier parameters:

$\phi \in [0,1]^K$0

In the reported experiments, $\phi \in [0,1]^K$1, so no explicit privacy regularizer is used; privacy is said to arise from severe downsampling and mask variability. Cross-entropy is used for MNIST and CIFAR-10, and binary cross-entropy for CelebA attributes (Bezzam et al., 2022).

The mask is implemented on an off-the-shelf ST7735R LCD with $\phi \in [0,1]^K$2 colour pixels, sub-pixel pitch approximately $\phi \in [0,1]^K$3, and cost $\phi \in [0,1]^K$4. In software, approximately $\phi \in [0,1]^K$5 sub-pixels covering $\phi \in [0,1]^K$6 of the sensor area are jointly optimized. Reconfigurability is achieved by generating $\phi \in [0,1]^K$7 distinct masks $\phi \in [0,1]^K$8 and cycling them on the LCD at up to $\phi \in [0,1]^K$9; $v = D\bigl(|H_{\phi}(x)|^2\bigr) + n,$0 recovers a fixed mask, whereas $v = D\bigl(|H_{\phi}(x)|^2\bigr) + n,$1 or $v = D\bigl(|H_{\phi}(x)|^2\bigr) + n,$2 yields variable projections (Bezzam et al., 2022).

The hardware prototype places the programmable LCD approximately $v = D\bigl(|H_{\phi}(x)|^2\bigr) + n,$3 in front of a Raspberry Pi High-Quality Camera using a Sony IMX477 sensor and is powered by a Pi 4B, for a total cost of approximately $v = D\bigl(|H_{\phi}(x)|^2\bigr) + n,$4 dollars. The digital twin reproduces this geometry with scene distance $v = D\bigl(|H_{\phi}(x)|^2\bigr) + n,$5–$v = D\bigl(|H_{\phi}(x)|^2\bigr) + n,$6, mask-to-sensor distance $v = D\bigl(|H_{\phi}(x)|^2\bigr) + n,$7, mask pixel pitch $v = D\bigl(|H_{\phi}(x)|^2\bigr) + n,$8, and either LED-pinhole PSF measurement or physics-based PSF simulation across $v = D\bigl(|H_{\phi}(x)|^2\bigr) + n,$9 (Bezzam et al., 2022).

Empirical results are reported on MNIST, CelebA, and CIFAR-10. For MNIST, learned $H_{\phi}(\cdot)$0 with logistic regression and a 2-layer FC net maintains at least $H_{\phi}(\cdot)$1 accuracy even at $H_{\phi}(\cdot)$2 dimensions, described as only a $H_{\phi}(\cdot)$3 drop and outperforming fixed masks or random $H_{\phi}(\cdot)$4 by at least $H_{\phi}(\cdot)$5. For CelebA gender versus smiling, learned $H_{\phi}(\cdot)$6 yields $H_{\phi}(\cdot)$7 and $H_{\phi}(\cdot)$8 at $H_{\phi}(\cdot)$9 dimensions, and $\phi$0 at $\phi$1 dimensions. For CIFAR-10 with VGG11, learned $\phi$2 achieves $\phi$3 accuracy at $\phi$4 and $\phi$5 at $\phi$6, which is reported as a $\phi$7 boost over the best fixed mask (Bezzam et al., 2022).

The privacy claims are operationalized against two inversion attacks. In convex inversion, an adversary with known $\phi$8 solves

$\phi$9

via projected gradient. On CelebA, the reported recovery quality is approximately $D(\cdot)$0 and $D(\cdot)$1 at high resolution, degrading to approximately $D(\cdot)$2 and $D(\cdot)$3 at $D(\cdot)$4; if $D(\cdot)$5 is reconfigured, recovery collapses to $D(\cdot)$6 and $D(\cdot)$7, described as an approximately $D(\cdot)$8 drop in metrics. In generator-based plaintext attacks, cycling among $D(\cdot)$9 or $n$0 masks reduces attack quality from fixed-$n$1 values of approximately $n$2 to $n$3, described as a $n$4 drop (Bezzam et al., 2022).

3. Dynamic privacy evaluation for LLM-powered agents

In the agentic-LLM line, PrivacyLens-Live transforms the static PrivacyLens benchmark into dynamic MCP and A2A environments. The starting point is the static PrivacyLens test set of 493 multi-step email and Notion-driven scenarios, each originally designed for a single, monolithic LLM prompt. The live conversion instantiates MCP tool servers for Gmail and Notion, and, when appropriate, A2A peer agents representing distinct parties such as John’s agent and Emily’s agent (Wang et al., 22 Sep 2025).

At run time, each sample is executed by a live MCP client in one of two modes. In “MCP only,” a single agent follows its system prompt, issues function calls such as gmail_search_messages, gmail_get_message, and NotionManagerSearchContent, refines its draft, and finally issues gmail_send_message. In “MCP + A2A,” a sender agent first sends a structured request to a recipient agent, the recipient agent uses MCP tools to fetch content and draft a reply, and the reply is returned as another A2A message. The benchmark therefore converts a static case into a live trajectory with interleaved tool calls, retries for “no results,” and asynchronous hand-offs (Wang et al., 22 Sep 2025).

The MCP protocol is event-driven. Each turn consists of an agent-to-server JSON function call of the form {"name": tool_name, "arguments": {...}}, a structured server observation containing {results: [...]}, and then either another tool call or a final action. In the MCP + A2A setting, each email send/receive is wrapped as an A2A message with fields such as {"to_agent": recipient_id, "subject": "...", "body": "..."}. All identities, agent cards, and private relationships are kept in agent-local memory only, so that privacy is measured specifically when data crosses the agent boundary (Wang et al., 22 Sep 2025).

The benchmark reuses PrivacyLens leakage metrics in dynamic form. For each sample $n$5, $n$6 indicates whether the final agent action contains any sensitive item from the ground-truth set $n$7. The leak rate is

$n$8

and the adjusted leak rate conditions on helpful outputs only:

$n$9

The contextual-integrity representation of an information flow is a 5-tuple $\mathrm{SNR}=40\,\mathrm{dB}$0 (Wang et al., 22 Sep 2025).

Evaluation is reported on the original 493 PrivacyLens cases and an extended 36-case 3-tool set adding Calendar, Slack, and Messenger, under four live settings: MCP (2-tool), MCP + A2A (2-tool), MCP (3-tool), and MCP + A2A (3-tool). Under an unmitigated OpenAI o3 baseline, the leak rates are $\mathrm{SNR}=40\,\mathrm{dB}$1 for Static (2-tool), $\mathrm{SNR}=40\,\mathrm{dB}$2 for MCP (2-tool), and $\mathrm{SNR}=40\,\mathrm{dB}$3 for MCP + A2A (2-tool). The paper reports a roughly $\mathrm{SNR}=40\,\mathrm{dB}$4 relative jump in leak rate from static to live settings, and adding a third tool raises leakage to $\mathrm{SNR}=40\,\mathrm{dB}$5 in MCP + A2A (Wang et al., 22 Sep 2025).

PrivacyChecker is then integrated via three deployment strategies: embedded in the system prompt, inside the Gmail tool’s function description, or as a standalone MCP tool send_privacy_check. With these mitigations, the reported leak rates become $\mathrm{SNR}=40\,\mathrm{dB}$6 in MCP and $\mathrm{SNR}=40\,\mathrm{dB}$7 in MCP + A2A for the Gmail-tool strategy; $\mathrm{SNR}=40\,\mathrm{dB}$8 in MCP and $\mathrm{SNR}=40\,\mathrm{dB}$9 in MCP + A2A for the system-prompt strategy; and $D$0 in MCP and $D$1 in MCP + A2A for the standalone-tool strategy. Average helpfulness remains in the “Good” band at approximately $D$2–$D$3 (Wang et al., 22 Sep 2025).

This line of work is directly continuous with the original PrivacyLens framework, which already argued that seed-level or vignette-level privacy QA can diverge sharply from action-level behavior in agent trajectories. In that earlier benchmark, GPT-4 and Llama-3-70B achieved at least $D$4 on probing tasks yet still leaked sensitive information in $D$5 and $D$6 of cases under the Basic Prompt, with leakage persisting under the Privacy-Enhancing Prompt (Shao et al., 2024). PrivacyLens-Live operationalizes that discrepancy in live tool-using environments.

4. Browser-level PII mediation and smokescreens

In a separate blueprint, PrivacyLens-Live denotes a browser-level PII redaction and smokescreen system inspired by PII Shield. The architecture consists of a web page or AI UI, a browser extension with UI Hooks, a Network Interceptor, and an Overlay Renderer, and a Local Anonymization Engine running on localhost or embedded WASM (Holschneider et al., 26 Mar 2026). The data flow begins when a user types a prompt, continues with local anonymization through a port such as http://127.0.0.1:5000/anonymize, replaces the outbound request with a sanitized final_prompt, and then applies a reverse pass on the response so that placeholders shown in the page can reveal original PII via hover tooltips.

The PII detection pipeline combines transformer-based NER with rule-based regular expressions. The blueprint names spaCy, Hugging Face “bert-base-ner,” and a distilled LLM of size approximately $D$7 as examples, and supplements them with regex patterns for emails, phone numbers, and SSNs. An entity span $D$8 is redacted if its confidence satisfies

$D$9

with default $H_\phi$0 and a UI slider exposing $H_\phi$1 (Holschneider et al., 26 Mar 2026).

The replacement strategy maps each entity to a placeholder of the form <TYPE_i>, where TYPE may be PERSON, ORG, EMAIL, or PHONE, and stores an ordered metadata map $H_\phi$2 of (placeholder, original_token, TYPE). The overlay lists all detected entities immediately after analysis, allows per-entity “redact / keep” toggles and custom replacements, and updates the preview pane in less than $H_\phi$3 via a re-call to anonymize_text with updated flags (Holschneider et al., 26 Mar 2026).

The smokescreen mechanism is conceptually different from ordinary redaction. It generates a surrogate narrative that is semantically equivalent but refers to a fictitious third party. The given example rewrites “I feel suicidal” to “My friend Alex reports feeling distressed.” The blueprint proposes using a small local LLM such as GPT-Neo 125M with a template instructing the model to rewrite the text as if describing a friend while preserving sentiment and removing first-person references. Token selection is specified by top-$H_\phi$4 sampling with $H_\phi$5 and temperature $H_\phi$6:

$H_\phi$7

The resulting surrogate is concatenated with the redacted prompt as a “System” or “Context” message so that the cloud LLM sees only the obfuscation narrative plus the sanitized user request (Holschneider et al., 26 Mar 2026).

The threat model treats the cloud LLM provider plus any network observer as the adversary. They can see only the final_prompt and receive no direct PII tokens, while local processing ensures that no plaintext PII leaves the user’s machine. A safety-net regex check blocks any request containing unredacted PII, and all redaction and smokescreen logic runs in a sandbox consisting of the extension and local engine (Holschneider et al., 26 Mar 2026).

This blueprint closely parallels the design principles of Rescriber, another browser extension for user-led data minimization in LLM-based chatbots. Rescriber combines a browser-extension frontend, a local mapping store, an on-device Llama3-8B backend quantized via Ollama, and a sanitization pipeline supporting replacement and abstraction. Its evaluation reported that comprehensiveness and consistency of detection and sanitization were central to users’ trust and perceived protection, and that subjective ratings for Llama3-8B were on par with GPT-4o in a study with $H_\phi$8 participants (Zhou et al., 2024).

5. On-device mobile provenance and AI-detection framework

A further blueprint applies the PrivacyLens-Live name to a privacy-first, on-device mobile framework for cryptographic image provenance and AI detection, explicitly derived from Origin Lens. Its architecture is layered. The always-enabled on-device path includes: C2PA provenance parsing from JUMBF boxes; heuristic EXIF/IPTC metadata scans for markers such as Stable Diffusion sd_version, Adobe Firefly CreatorTool, and Midjourney PromptHash; local SynthID watermark detection; and confidence aggregation. An optional user-opt-in fifth layer performs reverse-image retrieval using a cryptographic hash and a small embedding, described as a 256-D MobileNet V2 feature vector (Loth et al., 3 Feb 2026).

The provenance mechanism is based on hard-bound, certificate-backed verification. The blueprint specifies digital signatures, SHA-256 hash chaining, and X.509 certificate-chain validation. The content and bound hashes are

$H_\phi$9

so that any pixel-level change yields a different $\phi \in [0,1]^K$00 (Loth et al., 3 Feb 2026). It also notes an optional zkSNARK layer for applications demanding privacy of the manifest’s assertions.

For generative-model fingerprints, the framework uses two lightweight channels. The first is EXIF/IPTC signature parsing, encoded as a binary vector $\phi \in [0,1]^K$01 over known keys and classified with a logistic head:

$\phi \in [0,1]^K$02

with thresholding for AI-generated classification. The second is SynthID watermark correlation, computed as

$\phi \in [0,1]^K$03

with the text describing watermarked classification when $\phi \in [0,1]^K$04, typically around $\phi \in [0,1]^K$05 (Loth et al., 3 Feb 2026).

If retrieval is enabled, the image is embedded via a 256-D MobileNet head $\phi \in [0,1]^K$06 and matched against a remote Faiss index using IVF-PQ. The normalized retrieval score is

$\phi \in [0,1]^K$07

where $\phi \in [0,1]^K$08 is the top-1 distance (Loth et al., 3 Feb 2026).

The final graded confidence is a weighted combination of cryptographic, fingerprint, and retrieval signals:

$\phi \in [0,1]^K$09

with typical weights $\phi \in [0,1]^K$10, $\phi \in [0,1]^K$11, and $\phi \in [0,1]^K$12. The resulting interface uses a traffic-light mapping: green for $\phi \in [0,1]^K$13, yellow for $\phi \in [0,1]^K$14, and red for $\phi \in [0,1]^K$15 (Loth et al., 3 Feb 2026).

The benchmarked resource profile is explicitly mobile-oriented: C2PA manifest parsing and signature verification on a 12 MP JPEG takes $\phi \in [0,1]^K$16; EXIF/IPTC scanning takes $\phi \in [0,1]^K$17; SynthID correlation on a $\phi \in [0,1]^K$18 patch takes $\phi \in [0,1]^K$19; feature embedding generation takes $\phi \in [0,1]^K$20; and Dart-to-Rust FFI overhead is $\phi \in [0,1]^K$21 per call. Reported memory footprint is approximately $\phi \in [0,1]^K$22 for the Rust core and $\phi \in [0,1]^K$23 for the Flutter shell, with CPU load peaking at approximately $\phi \in [0,1]^K$24 on a 6-core mobile SoC and supporting more than $\phi \in [0,1]^K$25 for live camera streams when skipping non-essential layers (Loth et al., 3 Feb 2026).

6. Lineage, adjacent systems, and interpretive themes

The different PrivacyLens-Live usages sit within a broader privacy-preserving systems lineage. The original PrivacyLens framework formalized privacy-sensitive seeds using Helen Nissenbaum’s contextual-integrity 5-tuple, expanded them into expressive vignettes, and then into ToolEmu-based trajectories, showing that strong performance on privacy QA did not imply privacy-safe action selection in agent settings (Shao et al., 2024). The live benchmark variant inherits that concern and shifts the emphasis from scripted trajectories to event-driven tool use and inter-agent messaging (Wang et al., 22 Sep 2025).

On the vision side, the lensless-camera instantiation is contiguous with earlier work on human-imperceptible recognition under learnable lensless imaging. That prior work modeled measurement as $\phi \in [0,1]^K$26 or $\phi \in [0,1]^K$27, learned a binary mask via a straight-through estimator, and introduced privacy-oriented losses based on similarity, total variation, invertibility, and the restricted isometry property. It reported that learned masks with TV, INV, and RIP losses preserved high machine accuracy while rendering measurements unrecognizable to human observers, with subjective human verification around chance for some settings (Canh et al., 2023). PrivacyLens-Live extends that research direction by replacing static photolithographic masks with a reconfigurable LCD mask and explicitly evaluating inversion attacks (Bezzam et al., 2022).

Related live privacy-protection systems also appear in streaming and large-scale urban imaging. FPVLS, “Face Pixelation in Video Live Streaming,” uses MTCNN, CosFace embeddings, Positioned Incremental Affinity Propagation, ELR-based trajectory refinement, Gaussian smoothing, and block mosaic pixelation. On a live-stream dataset of 20 clips and 51,040 face labels, its full system reports MFPA of $\phi \in [0,1]^K$28, MFPP of $\phi \in [0,1]^K$29, OPR of $\phi \in [0,1]^K$30, and runtime of $\phi \in [0,1]^K$31–$\phi \in [0,1]^K$32 FPS (Zhou et al., 2021). In street-view privacy protection, LiDAR-assisted processing reduces the search space for face and license-plate detection to approximately $\phi \in [0,1]^K$33 of a 250 Mpix cyclorama by ground-plane extraction and reprojection, allowing a modern CNN pipeline to remain cost-effective despite a $\phi \in [0,1]^K$34 resolution increase (Sebastian et al., 2019).

Taken together, these systems suggest that the “PrivacyLens-Live” label has been used to mark deployment-facing privacy mediation in at least four senses: privacy-preserving sensing, privacy-aware agent evaluation, user-controlled prompt sanitization, and local provenance verification. A plausible implication is that the term has evolved from the PrivacyLens benchmark identity into a broader naming convention for live privacy instrumentation rather than a single architecture. Another plausible implication is that the shared design center is not one modality or threat model, but the insertion of privacy control at the point where data would otherwise become externally actionable: at capture time, at tool invocation time, at browser dispatch time, or at on-device verification time.