PrivacyChecker: CI-Based Privacy Mitigation

• PrivacyChecker is a model-agnostic, prompt-based framework that operationalizes Contextual Integrity (CI) to evaluate and control information flows in LLM agent workflows.
• It extracts structured privacy flows from dynamic contexts and applies binding decisions to ensure that sensitive data is properly redacted before actions are executed.
• Empirical results show that PrivacyChecker dramatically reduces leakage rates (e.g., from ~36% to ~8%) while maintaining nearly optimal task helpfulness.

PrivacyChecker is a model-agnostic, prompt-based mitigation framework for LLM-powered agents that runs at inference time, is built around Contextual Integrity (CI), and is designed to operate inside realistic agent workflows such as Model Context Protocol (MCP) and Agent2Agent (A2A) rather than only in static Q&A settings. Its stated role is to bridge the “privacy judgment–action gap”: LLMs often recognize that something is private when probed, yet still leak it when generating actions such as emails, replies, or tool calls. In reported experiments, PrivacyChecker reduces privacy leakage from 36.08% to 7.30% on DeepSeek-R1 and from 33.06% to 8.32% on GPT-4o while preserving task helpfulness (Wang et al., 22 Sep 2025).

1. Conceptual basis in contextual integrity

PrivacyChecker operationalizes Nissenbaum’s Contextual Integrity by treating privacy as the appropriateness of information flows within a context rather than as a blanket prohibition on disclosure. In the formulation used for agent behavior, each flow is characterized by a sender, a recipient, a subject, a type of information, and a transmission principle. PrivacyChecker uses these CI roles to force the model to enumerate flows, judge each flow as contextually appropriate or inappropriate, and then honor those judgments when producing the final action (Wang et al., 22 Sep 2025).

This framing places PrivacyChecker in a broader shift from pattern-based privacy detection toward contextual reasoning. Closely related work formulates privacy as a reasoning problem rather than simple pattern matching and organizes privacy analysis around sender, receiver, subject, attributes, and contextual details, with HIPAA used as a worked example of full-regulation coverage (Li et al., 2024). A plausible implication is that PrivacyChecker belongs to a class of systems that treat privacy failures as errors in contextual disclosure rather than merely as exposure of predefined sensitive tokens.

The motivating setting is the emerging agentic ecosystem in which LLMs act over tools, logs, messages, and multi-step trajectories. PrivacyChecker is intended for those settings because benchmark results show that static privacy question-answering ability is not a reliable proxy for privacy-safe agent behavior. The framework therefore inserts explicit CI reasoning between task reasoning and action emission.

2. Internal structure and decision procedure

PrivacyChecker is described as a modular mitigation approach with three core components, all implemented via prompting. The first component is Information Flow Extraction. It translates the current agent context—user instruction, prior trajectory, tool outputs, emails, notes, or logs—into structured CI flows. The prompt instructs the model to identify each distinct information flow needed to answer the user’s instruction and output it in JSON with the fields data_type, data_subject, data_sender, data_recipient, and transmission_principle (Wang et al., 22 Sep 2025).

{ "data_type": "type of information being shared", "data_subject": "person or entity the information is about", "data_sender": "entity sharing the information", "data_recipient": "entity receiving the information", "transmission_principle": "purpose or context of sharing" }

The extraction prompt explicitly distinguishes flows by temporal context, spatial context, social context, functional purpose, and information category. This is meant to engage the LLM’s understanding of contextual roles and norms before the model drafts or revises an externally visible action.

The second component is Privacy Judgment Per Flow. For every extracted flow, the model is instructed to include only data absolutely necessary for the task and then decide whether it is acceptable to include the data_subject’s data_type in the final response. The output is a binary decision: (A) means sharing is acceptable, and (B) means the flow should be blocked or abstracted. The prompt imposes a binding rule: if any flow receives (B), the agent must not quote or paraphrase that data in the final answer and must instead replace it with a high-level summary. This binding rule is the central mechanism by which PrivacyChecker turns privacy reasoning into action constraints.

The third component is the Privacy Guideline, which is optional. It provides general heuristics and domain-specific rules for sensitive data handling, covering personal performance and academic data, sensitive personal, emotional, and health information, temporal and location specifics, relationships and social dynamics, workplace and institutional information, affiliation with niche or stigmatized groups, and the instruction “When in doubt—redact or abstract.” In the main reported results, the Privacy Guideline is not used, so that the effect of the core CI prompt can be isolated (Wang et al., 22 Sep 2025).

3. Integration into MCP and A2A workflows

PrivacyChecker is protocol-agnostic but is explicitly integrated into MCP and A2A workflows. MCP is presented as a standard enabling LLM agents to call tools such as Gmail, Notion, Calendar, Slack, and Messenger via a unified client-server pattern, while A2A is described as a protocol for secure, asynchronous, interoperable communication between agents representing different users or entities (Wang et al., 22 Sep 2025).

Three deployment strategies are specified. The first places PrivacyChecker inside the agent’s system prompt. In this configuration the agent is instructed that, before sending any email or message, it must draft content, analyze information flows and apply CI-based privacy judgment, and then adjust the draft to reflect those judgments. This is an always-on form of deployment appropriate when the system prompt is under direct control.

The second embeds PrivacyChecker inside a specific MCP tool, such as gmail_send_message. In that setting the tool itself becomes privacy-aware: it can inspect outgoing parameters, run CI-based flow extraction and judgment, and prevent sending or request revisions if flows are judged inappropriate. This supports tool-specific privacy policies.

The third implements PrivacyChecker as a standalone MCP tool called send_privacy_check. The workflow is two-stage. The agent first drafts the full email. It then calls send_privacy_check with to, subject, body, cc, bcc, execution_log_path, and card_path. The privacy tool reconstructs information flows from the draft and logs, assigns (A) or (B) to each flow, and outputs its analysis together with LEAKAGE_DETECTED: YES/NO. If leakage is detected, the agent revises the email and calls the tool again until leakage is eliminated, after which it invokes gmail_send_message. In A2A experiments, agent cards store private relationship information for each user and are not shared between agents; they are used internally by PrivacyChecker to reason about roles and flows (Wang et al., 22 Sep 2025).

4. Benchmarks, metrics, and empirical results

PrivacyChecker is evaluated with metrics adopted from PrivacyLens. Leak Rate (LR) is the fraction of test cases where the agent’s final action contains sensitive items. Helpfulness is a 4-point scale from 0 to 3, where scores of at least 2 are considered task-effective. Adjusted Leak Rate, denoted LR_h, is leakage conditioned on tasks that were actually helpful; it is used to evaluate the privacy-utility trade-off (Wang et al., 22 Sep 2025).

The primary static evaluation uses PrivacyLens with 493 agent tasks, with additional tests on ConfAIde and CultureBank. On PrivacyLens, DeepSeek-R1 moves from a baseline LR of 36.08% and LR_h of 37.21% to 7.30% and 8.06% under PrivacyChecker, while Help changes from 2.58 to 2.35. GPT-4o moves from LR 33.06% and LR_h 33.56% to 8.32% and 9.22%, with Help changing from 2.69 to 2.45. Qwen3-14B-T moves from LR 36.11% to 11.76%, and o1 from 27.24% to 11.63%. Across all models, the reported effect is dramatic leakage reduction with minimal helpfulness loss (Wang et al., 22 Sep 2025).

The framework is also compared to a recent CI-based supervisor used for form filling. For GPT-4o, the CI supervisor yields LR 14.4%, LR_h 15.96%, and Help 2.52, whereas PrivacyChecker yields LR 8.32%, LR_h 9.22%, and Help 2.45. For Qwen3-14B-T, the CI supervisor yields LR 23.16% and LR_h 24.46%, whereas PrivacyChecker yields LR 11.76% and LR_h 12.47%. The reported interpretation is that structured flow reasoning plus the binding decision rule is more effective in these agentic settings (Wang et al., 22 Sep 2025).

Ablation studies isolate three mechanisms. Removing explicit verbalization from the judgment step worsens leakage, indicating that explicit verbalization of CI reasoning matters. Replacing Step 1 with ground-truth information flows lowers leakage further, indicating that flow extraction errors are a major leakage source. Adding the Privacy Guideline yields only modest improvements, indicating that CI flow-based reasoning rather than general heuristics is the primary driver (Wang et al., 22 Sep 2025).

Live evaluation uses PrivacyLens-Live, which converts static cases into MCP and MCP+A2A workflows. With OpenAI’s o3 model, static baseline LR is 17.4%, while PrivacyChecker inside Gmail reaches 7.3%. In live MCP, baseline LR rises to 26.3%, while PrivacyChecker reaches 8.7% inside Gmail, 8.0% in the system prompt, and 5.3% as a standalone MCP tool. In MCP+A2A, baseline LR is 24.3%, while PrivacyChecker reaches 6.7% inside Gmail, 6.7% in the system prompt, and 8.7% as a standalone MCP tool. The central empirical conclusion is that live operation exposes higher privacy risks than static evaluation, but all three deployment strategies substantially reduce leakage (Wang et al., 22 Sep 2025).

5. Qualitative behavior, failure modes, and limitations

A core motivating observation is that privacy awareness in probing does not guarantee privacy-safe action. Reproducing PrivacyLens with a privacy-enhanced prompt shows that models correctly judge private information as sensitive in 98% of probe questions, yet still leak private details in approximately 33% of action-based evaluations. Manual inspection indicates that chain-of-thought often focuses on task completion—such as “All information is relevant, I’m gonna draft an email now”—without carrying privacy judgment into the generated action. PrivacyChecker addresses this by making privacy reasoning mandatory and explicit, then binding the final action to those judgments (Wang et al., 22 Sep 2025).

The qualitative case studies emphasize the role of trajectory noise in tool-based settings. In one MCP+A2A example, John’s agent responds to Emily about a possible collaboration while Notion contains both a confidential strategic plan and a public industry-trends presentation. In a noisy live trajectory, the agent may retrieve only the confidential plan and draft an email that leaks it. When send_privacy_check is used, it extracts the flow corresponding to the confidential strategic plan, labels it (B), flags LEAKAGE_DETECTED: YES, and causes the agent to revise the email to a higher-level description that avoids those specifics (Wang et al., 22 Sep 2025).

The limitations are explicit. MCP and A2A are evolving protocols, so PrivacyLens-Live and the integration recipes may need updating. Current tool coverage is limited to Gmail, Notion, Calendar, Slack, and Messenger. Residual leakage remains due to incorrect privacy judgments, remaining judgment-action gaps, flow extraction failures, and evaluator instability when small LLMs are used. The framework is primarily aimed at inadvertent leakage during benign tasks and does not explicitly model strong adversaries such as persistent prompt-injection attackers, although prior work on prompt injection and context hijacking motivates future safeguards such as memory validation, clarification prompts, and output verification (Wang et al., 22 Sep 2025).

6. Position in the literature and broader usage of the term

PrivacyChecker’s nearest conceptual relatives are CI-based evaluation and privacy-reasoning systems. AgentCIBench, for example, evaluates computer-use agents under three CI failure modes—visual co-location, task-ambiguity overshare, and recipient misalignment—and reports that 11 of 15 frontier agents leak on more than 50% of scenarios, with an average leakage of 67.9%; this situates PrivacyChecker as a mitigation mechanism for a problem that appears broadly across agentic systems (Goel et al., 22 Jun 2026). Privacy Checklist, by contrast, constructs a regulation-grounded checklist over HIPAA and uses LLMs plus retrieval-augmented reasoning to judge whether a disclosure is permitted, prohibited, or not applicable; its emphasis on sender, receiver, subject, attributes, purpose, and consent provides a regulatory analogue to PrivacyChecker’s CI flow extraction (Li et al., 2024).

The term also appears in adjacent domains with a more generic meaning. In Ethereum compliance work, a “PrivacyChecker” is described as a predicate-verifying system that checks statements such as “age ≥ 18” via client-side zk-SNARKs without revealing the underlying identity data, using a Grant–Verify–Revoke lifecycle (Khadka et al., 20 Feb 2026). In smartphone privacy analysis, a hybrid consistency checker compares policy and code by mapping both into knowledge-graph triples of the form $\langle actor, action, data \rangle$ and then applying deterministic matching rather than end-to-end semantic comparison (Mao et al., 28 Apr 2025). This suggests that the label functions both as the proper name of the 2025 CI-based mitigation framework for LLM agents and as a broader design pattern for privacy-preserving or privacy-compliance checking systems across agentic, mobile, and cryptographic settings.