{"id":"8a900ad7-6ce1-4743-b765-24da0101bdc3","arxiv_id":"2508.01638","paper_version":1,"verdict":"UNVERDICTED","confidence":"LOW","novelty_score":5.0,"correctness_risk":"unknown","formal_verification":"none","parameter_count":0,"one_line_summary":"A plug-and-play framework transforms user prompts into semantically equivalent but obfuscated text for cloud LLMs and decodes responses back to preserve privacy without losing utility.","lead":"The paper proposes Semantic Encryption, a method that rewrites your question into a different wording with the same meaning before sending it to a cloud AI, then translates the AI's answer back using your private original. This could let people use cloud language models without exposing sensitive details in their prompts.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The privacy claim is under-specified: 'semantic transformation' is not defined as a secure mechanism, and preserving intent while removing sensitive information may be internally inconsistent; the abstract provides no evidence that the transformed input actually resists inference attacks.","rationale":"The reader's verdict is UNVERDICTED because the full text is unavailable, and I agree that the central claim cannot be checked from the abstract alone. My concern is more specific than the reader's weakest_assumption: while the reader highlights the lightweight local model's ability to preserve intent while removing sensitive information, I focus on the absence of a formal threat model and the inherent tension between semantic fidelity and privacy. This is not an ad hominem or a claim of fraud; it is a request for the missing definitions and empirical tests. The proposed concrete test would settle the concern by measuring whether the transformation actually resists a realistic adversary. Because the paper's own evidence is not available, the appropriate status remains UNVERDICTED rather than ACCEPT or REJECT. I marked agreement as partial because the reader identified the same general assumption but did not emphasize the threat-model gap, which is the most load-bearing issue for the privacy claim.","tokens_in":764,"tokens_out":2106,"duration_ms":30214,"concrete_test":"Request the full text's threat model and evaluation details, then run a reconstruction attack: take the SE-transformed prompts (as generated by the authors' code or described in the paper), give them to an independent off-the-shelf LLM, and ask it to recover the original sensitive attributes (e.g., names, locations, medical conditions, salary figures). Compare the reconstruction success rate against (a) the original prompts, (b) InferDPT-transformed prompts, and (c) a trivial baseline (e.g., removing named entities). If SE does not significantly reduce reconstruction accuracy relative to the original and to InferDPT, the privacy claim fails. Also check whether the paper defines a specific adversary class and a formal privacy metric; if not, the claim is vacuous.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that SE 'effectively protects data privacy without compromising data utility or user experience,' but the abstract never defines a privacy adversary or a formal notion of semantic encryption. The encoding phase is said to transform the original input into an alternative semantic context that 'maintains the original intent and logical structure while obfuscating sensitive information.' This creates a fundamental tension: if the transformed input preserves intent and logical structure, it remains semantically correlated with the original, so a cloud model (or an adversary with access to the transformed input) may be able to infer the omitted sensitive attributes through paraphrase-inference or other statistical attacks. Calling this 'encryption' is misleading without a cryptographic definition or a demonstrated indistinguishability property. The decoding phase references the locally stored original input, but that does not prevent the cloud from inverting the representation. The empirical claim of surpassing InferDPT is unverifiable from the abstract alone, but even if the numbers are correct, they do not establish privacy unless a threat model and a privacy metric are specified. This is load-bearing because if the transformation leaves recoverable semantic traces, the privacy promise fails regardless of utility or user experience.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes Semantic Encryption (SE), a plug-and-play framework for privacy-preserving interaction with cloud-based LLMs. It consists of a local lightweight model that transforms user input into an alternative semantic context maintaining original intent and logical structure while obfuscating sensitive information; the cloud LLM then processes this transformed input, and a decoding phase reconstructs the response into the original semantic context by referencing the locally stored user input. The abstract claims that SE protects data privacy without compromising data utility or user experience, and reports significant improvement over the state-of-the-art InferDPT across various evaluated metrics and datasets. The full text of the manuscript is not available for review, so only the abstract is assessed.","tokens_in":924,"tokens_out":3699,"duration_ms":41858,"significance":"The problem addressed—privacy of user data when interacting with cloud LLMs—is timely and of broad practical relevance. If substantiated, a local, plug-and-play transformation that preserves utility while offering meaningful privacy would be an important contribution. However, the abstract alone provides no methods, datasets, metrics, or threat model, so the significance of the contribution cannot currently be confirmed. The paper does identify a concrete limitation of existing approaches (overlooking logical structure) and proposes a plausible design pattern, but the scientific weight rests entirely on claims that are not checkable in the reviewed text.","major_comments":[{"comment":"The central claim that SE \"effectively protects data privacy\" is not supported by any explicit threat model, adversary class, or formal privacy definition. The abstract does not state what the adversary can observe (e.g., the transformed prompt, the cloud model's response, or auxiliary data), nor what notion of privacy is targeted (e.g., cryptographic indistinguishability, differential privacy, or resistance to specific inference attacks). Without such a definition, the privacy promise is not checkable, and the term \"encryption\" is used without a key-based or security-game-based definition.","section":"Abstract"},{"comment":"The encoding phase is described as producing an \"alternative semantic context that maintains the original intent and logical structure while obfuscating sensitive information.\" This creates a potential tension: if the transformed input retains the original intent and logical structure to the extent needed for accurate cloud responses, it likely remains semantically correlated with the original sensitive attributes. An adversary with access to the transformed input, or to the cloud model's response derived from it, may therefore infer the omitted sensitive information through paraphrase-inference or statistical correlation. The abstract provides no argument or evidence that this inference risk is mitigated.","section":"Abstract"},{"comment":"The empirical claim that SE \"demonstrates a significant improvement over the state-of-the-art InferDPT, surpassing it across various evaluated metrics and datasets\" is unverifiable from the abstract alone: no datasets, metrics, baseline configurations, or numerical results are reported. Even if such numbers exist in the full paper, the abstract does not connect them to a defined privacy metric, so the claimed privacy benefit cannot be separated from utility or user-experience measures.","section":"Abstract"}],"minor_comments":[{"comment":"The phrase \"plug-and-play\" is not defined; the authors should clarify what integration effort is required for existing CLLM-based applications and what interfaces (API, model-agnostic, etc.) are assumed.","section":"Abstract"},{"comment":"The description of Semantic Decoding is underspecified: it refers to the locally stored user input, but it does not say how the cloud response is \"reconstructed back into the original semantic context,\" and whether this reconstruction is deterministic, learned, or requires additional information not present in the transformed input.","section":"Abstract"}],"recommendation":"uncertain","confidential_remarks":"The manuscript submitted for review consists only of an abstract; no full text with methods, proofs, or experimental details is available. A substantive evaluation of the central claims is therefore impossible. I recommend that the editor request the complete manuscript, including the threat model, formal privacy definition, and full experimental description, before the submission is considered further."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Honest take: this is a sensible systems idea wrapped in a brand name, \"Semantic Encryption,\" that outruns what the abstract shows. The two-stage encode/decode framing—local model rewrites the prompt into a different semantic context, then reconstructs the response against the stored original—is a legitimate, useful way to frame the problem. It compares against InferDPT and claims gains across datasets, which is a testable, falsifiable claim. Good that they target both privacy and utility rather than one at the expense of the other.\n\nWhat I can't do is verify any of it. The full text wasn't available, so no methods, datasets, metrics, or threat model. The load-bearing assertion—\"protects data privacy without compromising utility\"—is stated but not supported. The stress-test note raises the main conceptual worry: if the transformed input keeps the original intent and logical structure, it is still semantically correlated with the sensitive attributes, so a cloud adversary might infer them via paraphrase or inference attacks. That is a real and serious tension, though the abstract doesn't actually state whether their obfuscation is designed to break that correlation or merely to remove obvious identifiers. So I'd call it a genuine open question, not a proven flaw.\n\nThe bigger soft spot is the word \"encryption.\" There's no formal security definition, no adversary model, no indistinguishability property. Calling this encryption is misleading; it's really semantic obfuscation with reconstruction. That matters because the paper's headline claim is a privacy guarantee, and you can't have a privacy guarantee without a threat model and a metric. Even if the empirical numbers beat InferDPT, that only shows utility preservation, not privacy.\n\nWho should read this: people working on privacy-preserving LLM serving and prompt obfuscation. The framework is a natural target for follow-up. It deserves a serious referee if the full paper contains a concrete threat model, realistic attack evaluation, and datasets. I'd accept it for review, with the expectation that the authors will need to sharpen the privacy claim and likely rename the contribution. I wouldn't cite it yet.","headline":"A practical-sounding privacy wrapper for cloud LLMs with a real internal tension; the abstract alone can't support the security claim.","tokens_in":1422,"tokens_out":1797,"would_cite":false,"duration_ms":19782,"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":"Semantic Encryption claims a local prompt rewrite can hide sensitive data from cloud LLMs while keeping answer quality intact.","keywords":["semantic encryption","cloud LLM privacy","semantic transformation","data utility","privacy-preserving prompting","InferDPT","plug-and-play","semantic encoding decoding"],"falsifier":"Run an attribute-inference attack on the encoded prompts: train a classifier to recover obvious identifiers such as names, emails, or phone numbers from the transformed semantic context. If that classifier performs noticeably above random guessing, the privacy claim is falsified. Separately, benchmark decoded answers on a multi-step reasoning set such as word problems; if SE's decoded answers fall materially below direct prompting accuracy, the utility claim fails.","tokens_in":583,"feed_emoji":"🔐","tokens_out":5357,"duration_ms":53941,"temperature":0.7,"pith_summary":"This paper tries to establish that a plug-and-play layer called Semantic Encryption (SE) can protect user privacy in cloud-based large language model interactions without sacrificing answer quality or user experience. The core idea is to transform each user prompt into an alternative semantic context that keeps the original intent and logical structure but removes sensitive information, send that transformed prompt to the cloud model, and then translate the cloud's response back into the original context using the locally stored prompt. If this works, users could query untrusted cloud LLMs with personal or confidential data and still get useful answers, whereas current approaches that merely encrypt sensitive tokens tend to degrade the model's performance. The paper reports that SE outperforms the existing InferDPT method across several metrics and datasets.","feed_headline":"Hide private prompts from cloud LLMs without losing answer quality","feed_subtitle":"Semantic Encryption rewrites prompts into a safe context, lets the cloud answer, then maps the answer back.","key_machinery":"The central object is the pair of Semantic Encoding and Semantic Decoding operations. Encoding is a local transformation that maps a user prompt $p$ to an alternative semantic context $\\tilde{p}$ that preserves intent and logical structure while obfuscating sensitive information; decoding maps the cloud response $r(\\tilde{p})$ back to a response in the original semantic context using the locally stored $p$. The 'alternative semantic context' is the key carrier: it is what the cloud sees, so it must be informative enough for the model to answer and uninformative enough about the user's secrets. The machine that effects the transformation is a lightweight local model, which keeps the privacy boundary on the user's device.","core_discovery":"On its own terms, the paper's central claim is that semantic transformation, rather than token-level encryption, is the right abstraction for private LLM use. SE's Semantic Encoding uses a lightweight local model to rewrite the user input into a sanitized but logically equivalent version; the cloud LLM answers that version; Semantic Decoding then reconstructs the original semantic context of the answer by referencing the original input kept on the user's device. The claim is that this preserves the logical structure the cloud model needs to answer well while removing the sensitive content the user does not want to expose. The paper further claims its evaluations show SE beats the state-of-the-art InferDPT on the metrics and datasets tested, meaning privacy and utility are both retained.","pith_inferences":["An implicit consequence is that the privacy guarantee is only as strong as the sanitization performed by the local model; a formal treatment could measure residual leakage via mutual information between the transformed prompt and the sensitive attributes.","SE can be viewed as a semantic error-correcting code: the local encoder adds structure that the decoder later removes, which suggests extending the framework to handle cloud responses that are off-topic or adversarial by adding redundancy to the encoding.","A natural testable extension is to benchmark SE against direct prompting on reasoning-heavy tasks such as multi-step arithmetic or instruction following, since the paper's utility claim is about logical structure preservation.","The assumption that the original input stays only on the user's device is critical; if an adversary can access the local store, the whole scheme collapses, so the practical deployment must include local encryption of that store."],"forward_implications":["If SE works as claimed, users can send sensitive prompts to commercial cloud LLMs without trusting the provider's data-handling policies.","The framework is plug-and-play: it wraps an existing LLM API, so it does not require retraining or modifying the cloud model.","Because decoding relies on the locally stored original input, the user experience stays continuous: the user sees answers in the original context, not in the transformed one.","SE's privacy-utility tradeoff beats InferDPT on the evaluated datasets, suggesting that preserving logical structure is more effective than encrypting sensitive tokens alone.","The approach shifts the privacy burden to the local device, so its guarantees scale with the quality of the local transformation model."],"supporting_citations":[],"fun_headline_variants":["Rewrite prompts to hide secrets, keep LLM answers useful","Semantic transformation shields prompts from cloud LLMs","Privacy for cloud LLMs via semantic rewriting, not tokens","Cloud LLM privacy: transform input, then map answer back","Hide sensitive prompts by changing meaning, not encrypting"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The scheme stands on a lightweight local model being able to rewrite any user prompt into a version that keeps the question's meaning and logical structure intact while removing every piece of sensitive information, and on the original prompt remaining safe on the user's device.","fun_headline_variants_meta":{"raw":{"variants":["Rewrite prompts to hide secrets, keep LLM answers useful","Semantic transformation shields prompts from cloud LLMs","Privacy for cloud LLMs via semantic rewriting, not tokens","Cloud LLM privacy: transform input, then map answer back","Hide sensitive prompts by changing meaning, not encrypting"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000209,"raw_usage":{"total_tokens":1393,"prompt_tokens":917,"completion_tokens":476,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":533,"completion_tokens_details":{"reasoning_tokens":397}},"tokens_in":533,"tokens_out":476,"duration_ms":4956,"temperature":1.0,"reasoning_tokens":397,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T05:27:31.000204+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run an attribute-inference attack on the encoded prompts: train a classifier to recover obvious identifiers such as names, emails, or phone numbers from the transformed semantic context. If that classifier performs noticeably above random guessing, the privacy claim is falsified. Separately, benchmark decoded answers on a multi-step reasoning set such as word problems; if SE's decoded answers fall materially below direct prompting accuracy, the utility claim fails.","supporting_citations":[],"review_version":1}