{"id":"98ff480c-06b6-4263-9731-fe1ca35fe7d9","arxiv_id":"2505.17145","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"An enterprise proxy that detects sensitive data in LLM prompts with a fine-tuned small model and replaces it with format-preserving encryption.","lead":"This paper describes a privacy shield that sits between users and online chatbots, scanning prompts for sensitive data and encrypting it before it leaves the organization. If it works, companies could let employees use tools like ChatGPT without exposing customer records.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"FPE changes the actual value of sensitive entities (Table 8), so any downstream task requiring value-based reasoning yields outputs that the response-decryption step cannot fix; no quantitative utility evaluation is provided.","rationale":"The reader's weakest assumption correctly identifies the lack of quantitative evidence for FPE preserving downstream task utility. My concern sharpens this: FPE not only lacks support, it structurally cannot preserve accuracy for tasks that reason over the entity's actual value, because the response decryption only reverts exact ciphertext occurrences. This makes the central claim 'preserving the functional accuracy of LLM-driven tasks' overbroad. The detection component (DLMS) is separately evaluated and appears technically sound, and the paper could be revised to scope the utility claim (e.g., to extraction/copy tasks with quantitative validation) or to add a value-preserving mechanism. Thus the existing CONDITIONAL verdict remains appropriate: accept only after the utility claim is either substantiated on representative tasks or explicitly narrowed. No verdict change is needed beyond the reader's conditional recommendation.","tokens_in":20454,"tokens_out":6729,"duration_ms":60398,"concrete_test":"Construct a simple prompt: 'Fund value $150,000. Compute a 10% management fee.' Encrypt '150,000' using the paper's FF3-1 FPE implementation and send the encrypted prompt through the described pipeline (external LLM plus SDA response-decryption step). If the returned fee is not $15,000 (and cannot be recovered by decrypting the response), the utility-preservation claim fails for arithmetic tasks. Repeat across 50 prompts per task type (arithmetic, entity-attribute lookup, information extraction) to quantify the fraction of tasks where FPE preserves accuracy.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that the framework 'preserving the functional accuracy of LLM-driven tasks' is unsupported and likely false for common value-dependent tasks. In Section 9, utility is defined as preservation of semantic context, yet FPE (Section 9.1) replaces a sensitive value with an unrelated ciphertext preserving only format. For example, Table 8 maps the monetary value 1,452,500 to 6,423,095. The workflow (Section 2.3, step 6) decrypts only exact ciphertext occurrences that appear verbatim in the LLM response. If the LLM computes with the encrypted value (e.g., '10% of $6,423,095'), the returned number $642,309.50 is not the original ciphertext and will not be decrypted, so the user receives an incorrect result. The only evidence of utility preservation is a single qualitative example (Appendix Figure A.1), with no task-accuracy evaluation. The paper acknowledges the fundamental privacy-utility trade-off (No Free Lunch Theorem, [46]) but never quantifies where it lands. A broad claim of preserving functional accuracy therefore rests on an untested and structurally questionable assumption.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes LLM Access Shield, an end-to-end framework for enforcing organizational privacy policies during user interactions with external LLM services. It combines a domain-specific fine-tuned model (DLMS), trained with supervised fine-tuning and reinforcement fine-tuning under an \"analyze-then-decide\" reasoning paradigm, with format-preserving encryption (FPE) for anonymizing detected sensitive entities. The authors evaluate DLMS on synthetic datasets built from a six-category taxonomy, report detection accuracy at safety, category, and entity levels, test generalization to four non-taxonomy policies via prompting, and argue that FPE preserves the semantic utility of prompts for downstream LLM tasks. The central claims are that the framework mitigates security risks and preserves functional accuracy of LLM-driven tasks.","tokens_in":20745,"tokens_out":3206,"duration_ms":25071,"significance":"If the detection and utility-preservation claims were fully established, the framework would be a useful practical contribution: it has a sensible modular architecture, a lightweight 3B-parameter detector, a clearly described two-stage workflow, and an interesting combination of curriculum learning and rule-based rewards for reinforcement fine-tuning. The paper also gives explicit credit where due: it documents training configurations, provides sample prompts and outputs in appendices, and compares qualitatively with prior prompt-sanitization systems. However, the current evidence is not sufficient to support the central claims. The detection evaluation is based on a self-referential synthetic dataset with no released artifacts, and the claimed comparison to Llama-Guard-3-8B is not present in the reported table. The utility-preservation claim rests on a single qualitative example and is structurally doubtful for value-dependent downstream tasks. These issues affect load-bearing parts of the paper, so the contribution is currently more a promising system description than a validated framework.","major_comments":[{"comment":"The text states that \"all DLMS models significantly outperform the baseline Llama-Guard-3-8B\" across Accuracy, F1-Score, and AUPRC, but Table 5 contains no Llama-Guard-3-8B row; the only non-DLMS row is Llama-3.2-3B-Instruct. This is a load-bearing comparison error because the claimed advantage over an established safety-classification model is not actually reported. Please either add the Llama-Guard-3-8B results (with the same prompt format and metrics) or revise the text so that the comparison is only against the base model. In addition, all results in Tables 5-7 are reported on a single split with no confidence intervals or error bars, so the reader cannot assess the stability of the differences.","section":"Section 7.1, Table 5"},{"comment":"The central claim that the framework \"preserving the functional accuracy of LLM-driven tasks\" (Abstract) is not supported by the evidence. The paper defines utility as preservation of semantic context, but FPE changes the actual values of sensitive entities: Table 8 shows the monetary value 1,452,500 becoming 6,423,095. In the workflow of Section 2.3, step 6 decrypts only exact ciphertext occurrences that appear verbatim in the LLM response. If a downstream task reasons over the encrypted value (for example, computing 10% of 6,423,095), the LLM's output is a new number that is not in the ciphertext and therefore will not be decrypted, so the user receives an incorrect result. The only evidence for utility preservation is one qualitative example in Figure A.1, and no quantitative task-accuracy evaluation is provided. The paper cites the No Free Lunch theorem for privacy-preserving inference [46] but never quantifies where the trade-off lands. Please add a task-level accuracy evaluation on representative value-dependent and entity-dependent workloads, or narrow the utility claim to the class of tasks for which FPE is actually lossless.","section":"Section 9, Section 2.3, Table 8"},{"comment":"The evaluation benchmark is self-referential. The training and testing datasets are generated from the same six-category taxonomy and template-based prompt generation procedure described in Appendix A, so high scores on the test set may reflect template memorization rather than robust privacy-policy compliance. The non-taxonomy policy test in Section 8 is a step in the right direction, but the four policies' examples overlap heavily with the training categories: POL02 names phone numbers, POL03 names email addresses and phone numbers, and POL04 names bank account and credit card information, all of which are T-categories in Table A.2. The claim of generalization to unseen policies would be stronger with an externally curated or independently annotated benchmark, and with release of the generated datasets and evaluation scripts for reproducibility.","section":"Section 3.2, Appendix A, Section 8"}],"minor_comments":[{"comment":"Section 5.4 states that \"All four reward components are active during training,\" but Section 5.5 describes a stage-specific reward schedule in which format penalties and category/entity rewards are introduced progressively. Please clarify whether the four components are active at every stage of the curriculum or only in the later stages.","section":"Section 5.4 and Section 5.5"},{"comment":"The definition of utility as preservation of semantic context cites reference [1], which is a study of privacy leakage in GPT conversations rather than a semantics or utility reference; a more appropriate citation would be a work on semantic similarity or prompt utility.","section":"Section 9"},{"comment":"Several cells in Table 6 are missing spaces (for example \"0.9220.7120.703\"), making the table difficult to read; please fix the formatting.","section":"Table 6"},{"comment":"Table A.1 is referenced in Section 8 as being in Appendix A, but it appears in Appendix D together with Tables A.2 and A.3; please renumber or update the cross-reference.","section":"Appendix D"},{"comment":"The manuscript contains several typographical errors and spacing artifacts (e.g., \"Incontract,\" \"mayinferorretain,\" \"GDPR the HIPAA\"), which should be corrected in a careful proofreading pass.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The paper describes an interesting system but currently overclaims on both the detection comparison and utility preservation. The missing Llama-Guard-3-8B comparison in Table 5 and the absence of any quantitative downstream-task evaluation are the most serious issues. I would encourage the editor to request a revised version with corrected comparisons, confidence intervals or repeated runs, and a task-level utility evaluation; release of the dataset and code would also greatly improve verifiability. The paper is within the scope of the journal, but the revisions are substantial rather than cosmetic."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short take: the detection half of this paper is a credible piece of applied RL work; the utility-preservation claim is not just unproven, it is probably wrong for value-dependent tasks, and that is the claim the abstract sells.\n\nYou should know two things. First, the RFT \"analyze-then-decide\" training for privacy detection, with the curriculum over safety/category/entity levels, is a genuinely new configuration, and the few-shot generalization result (Section 8) is the strongest part of the paper. Second, the central claim about preserving functional accuracy is not supported. The only evidence is one qualitative Copilot example in Appendix Figure A.1. FPE replaces a monetary value 1,452,500 with 6,423,095 (Table 8). If the downstream LLM does any arithmetic on that ciphertext, the output is a number like 642,309.50 that is not the original ciphertext, so the response-decryption step cannot map it back. The user gets a wrong answer. The paper even cites the No Free Lunch theorem but never quantifies where it lands.\n\nThe detection results are plausible but do not clear the bar set by the abstract. The dataset is synthetic and generated from the same taxonomy used for training; the non-taxonomy policy test (Section 8) uses policies whose examples heavily overlap the training categories (phone numbers, bank accounts). No artifacts are released, no error bars are reported, and Section 7.1 text claims comparison to Llama-Guard-3-8B while Table 5 only includes Llama-3.2-3B-Instruct. Those are fixable, but they undermine confidence.\n\nCredit where due: the authors are honest about reward hacking and catastrophic forgetting, and the curriculum results are reported with stage-wise checkpoints rather than cherry-picked. The RFT generalization advantage over SFT on few-shot policies is interesting and worth checking independently.\n\nWho should read it: anyone building deployable privacy layers for enterprise LLM use, and RL practitioners working with rule-based rewards. It is not a fundamental advance, but it is a useful operational paper if the utility claim gets fixed. As it stands, I would not ship this framework for financial or healthcare tasks without a quantitative task-accuracy evaluation on value-dependent workloads.\n\nRecommendation: send to peer review, but flag the FPE/utility issue as the main thing referees must push on. This deserves referee time; the detection half is substantive. Conditional accept after major revision, not a desk reject.","headline":"The detection half is a credible applied RL contribution, but the paper's headline claim—that FPE preserves functional accuracy—is unsupported and likely false for value-dependent tasks.","tokens_in":21217,"tokens_out":2066,"would_cite":false,"duration_ms":16892,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Privacy shield encrypts prompt data before it reaches the LLM.","keywords":["LLM privacy","format-preserving encryption","sensitive data detection","policy compliance","reinforcement fine-tuning","curriculum learning","prompt anonymization","domain-specific LLM"],"falsifier":"Run a suite of standard LLM tasks (summarization, question answering, entity extraction, code completion) on prompts whose sensitive entities have been replaced by FF3-1 ciphertexts and compare against the same prompts in plaintext; if the encrypted-prompt outputs show a statistically significant drop in accuracy, similarity, or task completion, the utility-preservation claim is falsified.","tokens_in":20298,"feed_emoji":"🛡️","tokens_out":8091,"duration_ms":61519,"temperature":0.7,"pith_summary":"LLM Access Shield claims that organizations can let employees use external chat and coding assistants without exposing regulated data by routing prompts through a local proxy. A purpose-built detector model (DLMS) classifies each prompt as safe or unsafe, names the violated data categories, and extracts sensitive strings; when a string is found, a format-preserving encryption module replaces it with ciphertext that keeps the same length and character shape, and the response is decrypted on the way back. The paper argues this gives a practical middle path between expensive fully homomorphic or secure-multiparty approaches and noise-based methods that degrade answers. The reported detection metrics are specific and detailed, while the claim that encrypted prompts preserve downstream task accuracy is supported by one illustrative comparison rather than a quantitative benchmark.","feed_headline":"Privacy shield encrypts prompt data before it reaches the LLM","feed_subtitle":"A domain-specific detector plus format-preserving encryption keeps context intact for downstream tasks.","key_machinery":"The load-bearing machinery is the pair formed by DLMS and the Sensitive Data Anonymizer. DLMS is the domain-specific reasoning model that reads a prompt and emits a safety label, violated category codes, and exact sensitive strings, using either supervised fine-tuning or a reinforcement fine-tuning loop whose rule-based reward measures format, safety status, category set, and entity extraction; the analyze-then-decide paradigm trains it to show its reasoning in one tagged section before the final answer. The Sensitive Data Anonymizer applies FF3-1 format-preserving encryption, which keeps length, character classes, and delimiters unchanged, so a phone number stays a phone-number-shaped string and a monetary value stays a number; this is what lets the external LLM see coherent text while the true value remains secret.","core_discovery":"The central claim is that an end-to-end proxy framework can enforce privacy policies during LLM interaction at acceptable cost to utility. Detection is carried by DLMS, a 3-billion-parameter instruction-tuned model fine-tuned on 2,311 annotated prompts, either by supervised fine-tuning in the style of a safety-classifier prompt format or by reinforcement fine-tuning with an analyze-then-decide reasoning trace and rule-based rewards, optionally structured through a three-stage curriculum. On the six-category taxonomy, the supervised model reaches 0.935 safety accuracy and a 0.839 privacy hiding rate, and the curriculum-trained reinforcement model reaches 0.862 accuracy on four unseen natural-language privacy policies through few-shot prompting. For anonymization, the framework applies FF3-1 format-preserving encryption to detected entities so ciphertexts keep the format of emails, phone numbers, and monetary values, then decrypts any such entities that appear in the LLM response. The paper's conclusion is that confidentiality, contextual integrity, and functional accuracy can be balanced in high-assurance domains such as finance, law, and healthcare.","pith_inferences":["If the same encryption key and tweak are reused across many prompts, a curious external provider could compare repeated ciphertext patterns and infer correlations; the paper treats the external LLM as honest-but-curious but does not analyze this side-channel, and a natural extension would be per-request tweaks.","The utility-preservation claim would be much stronger if tested on standard summarization, question-answering, and coding benchmarks; the paper shows one illustrative example, so measuring task accuracy on such benchmarks is the direct next experiment.","The shield's detection and encryption logic sits entirely on the input side; the authors list output-side leakage as future work, but the same architecture could eventually filter responses by role-based access if a separate response-compliance detector were trained.","For adoption in regulated industries, the audit trail of reasoning tokens plus decryption logs is only as credible as the reasoning itself, so an evaluation of reasoning accuracy, not just final labels, would be a useful public benchmark."],"forward_implications":["A deployment can add the shield as a proxy or integrator without modifying the external LLM, so existing corporate chat and coding assistants can be brought under a privacy policy with configuration rather than model replacement.","New or changed privacy policies can be enforced at inference time by injecting them into the prompt with few-shot examples, removing the need to retrain the detector for every regulatory update.","Because format-preserving encryption retains token format, downstream processing that depends on schema shape, such as parsers, validation rules, and structured outputs, can continue to operate on the ciphertext.","The reasoning traces emitted inside the tagged analysis section give auditors a human-readable record of why a prompt was flagged, supporting explainability requirements in regulated settings.","The curriculum-based reinforcement variant improves multi-label category accuracy over single-stage training, suggesting that staged rewards help the model handle prompts that violate several data categories at once."],"supporting_citations":[{"why":"Supplies the motivating evidence that GPT models can leak private information through crafted prompts.","marker":"[1]"},{"why":"Provides the Privacy Hiding Rate metric and a baseline comparison for entity anonymization.","marker":"[35]"},{"why":"Supplies the NIST FF1 and FF3-1 standard that the Sensitive Data Anonymizer uses for format-preserving encryption.","marker":"[40]"},{"why":"Provides the supervised fine-tuning prompt format that DLMS adapts to a sensitive-data taxonomy.","marker":"[41]"},{"why":"Supplies the rule-based reinforcement learning approach behind the reinforcement fine-tuning variant.","marker":"[42]"},{"why":"Supplies the REINFORCE++ algorithm used to train the reasoning-based detector.","marker":"[43]"},{"why":"Supplies the curriculum learning precedent that motivates the staged reward schedule for reinforcement fine-tuning.","marker":"[44]"},{"why":"Formalizes the privacy-utility trade-off that the framework's format-preserving anonymization is designed to navigate.","marker":"[46]"},{"why":"Defines format-preserving encryption, the core mechanism whose format retention justifies the utility claim.","marker":"[48]"}],"fun_headline_variants":["LLM shield encrypts prompt data, keeps downstream tasks accurate","Dynamic policy shield detects and hides sensitive data in LLM prompts","Format-preserving encryption in LLM shield keeps context intact","Domain-aware shield hides sensitive data, preserves LLM utility","Real-time policy shield encrypts prompt secrets, keeps tasks accurate"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that replacing sensitive strings with format-preserving ciphertext leaves enough meaning intact for the external LLM to answer well; the paper supports this with a single illustrative comparison rather than a quantitative task-accuracy study.","fun_headline_variants_meta":{"raw":{"variants":["LLM shield encrypts prompt data, keeps downstream tasks accurate","Dynamic policy shield detects and hides sensitive data in LLM prompts","Format-preserving encryption in LLM shield keeps context intact","Domain-aware shield hides sensitive data, preserves LLM utility","Real-time policy shield encrypts prompt secrets, keeps tasks accurate"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000927,"raw_usage":{"total_tokens":3957,"prompt_tokens":914,"completion_tokens":3043,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":530,"completion_tokens_details":{"reasoning_tokens":2959}},"tokens_in":530,"tokens_out":3043,"duration_ms":19184,"temperature":1.0,"reasoning_tokens":2959,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T15:02:51.296858+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a suite of standard LLM tasks (summarization, question answering, entity extraction, code completion) on prompts whose sensitive entities have been replaced by FF3-1 ciphertexts and compare against the same prompts in plaintext; if the encrypted-prompt outputs show a statistically significant drop in accuracy, similarity, or task completion, the utility-preservation claim is falsified.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the motivating evidence that GPT models can leak private information through crafted prompts."},{"cited_title":"Dworkin, Recommendation for block cipher modes of operation: Methods for format-preserving encryption, Methods and Techniques (2016)","cited_arxiv_id":null,"evidence_quote":"Supplies the NIST FF1 and FF3-1 standard that the Sensitive Data Anonymizer uses for format-preserving encryption."},{"cited_title":"Zhang, Y","cited_arxiv_id":null,"evidence_quote":"Formalizes the privacy-utility trade-off that the framework's format-preserving anonymization is designed to navigate."},{"cited_title":"Bellare, T","cited_arxiv_id":null,"evidence_quote":"Defines format-preserving encryption, the core mechanism whose format retention justifies the utility claim."}],"review_version":1}