{"id":"0acd0fd4-d348-414f-863e-08dea12f4a70","arxiv_id":"2608.06690","paper_version":2,"verdict":"ACCEPT","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Trusted authorization can completely prevent a separately trained private expert branch from executing in sparse MoE LLMs, verified across Qwen3-30B-A3B and DeepSeek-V2-Lite.","lead":"AI models with expert modules can now be built with a separate private branch that runs only when trusted authorization allows it. Tests on two large open models show unauthorized requests execute zero private experts, with logs and independent hooks matching exactly.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"G1's universal form rests on Python-level hooks that may not observe compiled or fused kernels; a kernel-level fault-injection check would settle whether private experts ever execute under deny.","rationale":"The paper's center of gravity is G1: a universal, deterministic execution-control claim. For such a claim, one unlogged execution path is a counterexample. The authors are unusually careful: they separate G1/G2/G3, use route logs plus hooks, run 96 deny events, and explicitly scope the trusted computing base. My reading is that the argument is internally consistent and the evidence is strong for an eager-mode Qwen implementation. The single soft spot is that the physical-execution audit has the same granularity as the code it audits: Python-level module hooks and the masking/routing code live in the same runtime, and the torch.compile DeepSeek arm is exactly the setting where a graph rewrite can bypass module boundaries. This is not an inconsistency with the declared TCB; it is the point where the proof of verification from route events is weakest. The proposed fault-injection test is decisive because it tests the negation of G1 directly and works even if hooks are bypassed. Since the limitations are openly stated and the claim is explicitly scoped, I do not think the verdict needs to change; I would encourage the authors to run this test and release the artifact so the universal form can be checked independently.","tokens_in":18029,"tokens_out":8991,"duration_ms":87594,"concrete_test":"Poison every private-expert weight tensor in the deny checkpoint with a sentinel (all-NaN or a fixed random perturbation) while leaving public weights and manifests unchanged; run the full deny arm on both Qwen and the torch.compile DeepSeek path. If any output token, logit, or sampled trajectory differs from the unpoisoned deny run, private weights are physically read despite zero route-logged selections, disproving G1. Complement this with a kernel-level trace (CUPTI/nsys on GPU, or eBPF/perf on CPU) during deny to confirm no private-expert GEMM or slice is launched. A bit-identical deny result plus no private-expert kernel activity would settle the concern without relying on Python forward hooks.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Eq. (1) claims that for every trace, deny executes no private expert, and the paper says this is verified from route events rather than generated text. The load-bearing support is the route logger plus independent forward hooks on the 32 private expert modules (Sec. 5.2; App. F.1). The weak point is that both observations come from the same Python-level software stack that implements masking. The DeepSeek arm runs under torch.compile and FlashAttention-2 (Sec. 4.1); compiled graphs and fused expert-dispatch kernels can read or invoke private-expert weights without calling a hooked nn.Module.forward, while the route logger only records the top-k decisions made before dispatch. The reported 931-call/11,616-row hook audit is described for the Qwen checkpoint, and App. F.1 explicitly states the audit is not kernel-level or formal. Consequently the evidence does not fully rule out a dispatch bug or compiler rewrite that executes an ineligible expert under deny; if such a path exists, Eq. (1) fails even though every route log says zero. This is the least secure link in an otherwise clean argument, and it is the same gap the authors disclose in Sec. 8 and App. F.1.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes Policy-Masked Private Experts, a mechanism for capability access control in sparse Mixture-of-Experts language models. It freezes a pretrained MoE and trains a disjoint private expert pool at selected layers; trusted authorization metadata, never the prompt, determines a hard mask applied before top-k routing, so an authorized request sees only private experts and a denied request only public experts. The main formal claim is G1 (Eq. 1): under the declared trusted computing base, τ=0 implies no private expert executes. The paper further separates G2, isolation of the training update to the private branch, and G3, empirical capability uplift on declared task distributions. Experiments on Qwen3-30B-A3B and DeepSeek-V2-Lite report zero private selections across 96 deny/fail-closed events, independent forward hooks matching 11,616 routed private rows, exact allow–deny–allow recovery, unchanged public fingerprints across seeds, and positive utility lifts on two Qwen benchmarks and one DeepSeek suite; a sealed CCTU benchmark is valid but near-neutral. The authors frame the contribution as an auditable, reversible access boundary rather than proof of semantic knowledge removal.","tokens_in":18304,"tokens_out":6803,"duration_ms":61207,"significance":"If the claims hold, the paper provides a concrete, testable mechanism that addresses a real gap in LLM access control: most defenses regulate behavior while leaving the same computation available to every request, whereas Policy-Masked Private Experts make a designated parameter path physically unreachable under deny. The main security claim is narrow and falsifiable, which is a strength. The paper also models good research practice: preregistration, frozen benchmark IDs, sealed evaluation with validity gates, immutable hashes, failure ledger, clean-lock reproduction, and independent instrumentation. The design honestly separates execution control from utility and does not overclaim semantic capability removal. The route-event auditing and independent hooks are direct and go beyond refusal-based evaluation. The main risk, explicitly disclosed by the authors, is that the audit is not a kernel-level or formal proof; the guarantee is conditional on the correctness of the routing and auditing implementation. Overall, the contribution is significant for the systems/security angle of deployed MoE serving.","major_comments":[{"comment":"The universal form of G1, \"for any request trace T(x,τ), τ=0 ⇒ Exec(T) ∩ E_priv = ∅\", is stronger than what the reported evidence can establish. The empirical verification covers 96 deny/fail-closed events and 11,616 routed rows under the authors' Python-level instrumentation; App. F.1 explicitly states that this is not a kernel-level or formal proof. Because the claim is the primary security endpoint, the paper should either add a stronger audit (e.g., a kernel-level or binary-level execution trace, or a formal correctness argument for the mask-to-routing step) or qualify Eq. (1) in the main text to state explicitly that the guarantee is conditional on the routing and audit instrumentation being correct and complete. The authors' disclosure in Sec. 8 is commendable, but the formal statement in Eq. (1) currently overstates the verification level. This is a load-bearing point because the abstract and introduction present G1 as the central result.","section":"Sec. 2.2, Eq. (1); App. F.1"}],"minor_comments":[{"comment":"The independent hook audit (931 calls, 11,616 rows) is reported for the Qwen checkpoint, but the DeepSeek arm uses torch.compile and FlashAttention-2, where Python-level nn.Module hooks may not observe fused kernels. Please clarify explicitly whether the same hook audit was applied to the DeepSeek checkpoint, and if not, state so in the evidence summary.","section":"Sec. 4.1 / Sec. 5.2"},{"comment":"Consider adding a one-sentence condition to Eq. (1) or its surrounding text: \"conditional on the trusted computing base behaving as specified.\" This would align the formal statement with the threat model and with the limitations stated in Sec. 8 and App. B.3.","section":"Sec. 2.2 / Eq. (1)"},{"comment":"The footnote for the Gated LoRA allow row says it is a post-hoc diagnostic; please also add a footnote to the \"Gated LoRA deny\" results in Sec. 5.2 (1,225 calls) clarifying that the deny condition is the same post-hoc audit, or state that explicitly in the text to avoid confusion.","section":"Table 3 / Sec. 4.2"},{"comment":"The sentence describing the projected 11.564 GPU hours versus the declared eight-hour cap is important for transparency, but it is easy to read as an unapproved extension. Please add a clause explaining that the projection was made before any adapted output and that the single permitted nested reduction to 100 records was applied before evaluation, as is later clarified.","section":"App. D.1"},{"comment":"The abstract states \"A valid sealed evaluation is near-neutral.\" This is accurate, but consider adding a phrase such as \"with route traces supporting G1\" so the reader understands that the null utility result does not undermine the access-control claim.","section":"Abstract"}],"recommendation":"minor_revision","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"What you should know: this paper makes a deliberately narrow claim—under a declared trusted computing base, an unauthorized request executes no private expert in a sparse MoE—and then actually tests that claim rather than inferring it from text. That is rarer than it should be. The construction is simple: a hard policy mask applied before top-k routing, with a disjoint trainable expert pool and the public model frozen. The paper correctly says the hard mask itself is not the novelty; the novelty is the access-control framing, the causal allow-deny-allow intervention, the adversarial authorization suite, and the gated-LoRA counterfactual. I think that framing is genuinely new relative to gradient routing and adapter gating, and it is useful.\n\nThe evidence is better than I expected. Three matched seeds, public fingerprints unchanged, all 32 private experts routed and updated, 96 deny/fail-closed events with zero private selections, independent hooks exactly matching 11,616 routed rows, and exact recovery. The gated-LoRA comparison is the right control: 1,225 adapter calls under deny shows why a logical switch is not the same as physical non-participation. They also report a valid sealed CCTU result that is near-neutral, and they do not spin it. That is honest, and it should count in their favor.\n\nThe legitimate soft spot is the one the stress-test note flags. Eq. (1) claims the invariant for every trace, but the audit evidence is Python-level hooks and route logs on the same software stack that implements masking. DeepSeek runs under torch.compile and FlashAttention-2; fused or compiled kernels can read or invoke private weights without calling a hooked nn.Module.forward. The paper explicitly says the audit is not kernel-level (App. F.1), so the universal quantifier in G1 is stronger than the evidence. This is not a fatal flaw for a systems paper—the TCB includes the audit instrumentation, and the claim is conditional on that TCB—but it is the load-bearing assumption, and the authors could either scope Eq. (1) to the audited stack or add a kernel-level fault-injection check. Also, the independent hook audit is described for the Qwen checkpoint only; DeepSeek's route invariant appears to rely on the logger alone. Minor points: no public artifact URL, and the task-aligned p is one-sided .03125 (two-sided .0625), which is borderline—though they present it as directional and the external benchmark is much stronger.\n\nWho it is for: systems and security people working on LLM access control, not ML theory. It deserves a serious referee. I would send it out, and ask the authors to either narrow the claim or close the audit gap. Given the honesty of the limitations section, I would expect revision rather than rejection.","headline":"A narrow, well-scoped execution-control claim with unusually honest evidence; the main weakness is the software-level audit, which the authors themselves disclose.","tokens_in":18770,"tokens_out":1666,"would_cite":true,"duration_ms":15829,"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":"Private experts can be made unreachable for unauthorized requests by masking them out before top-k routing, with zero denied executions across adversarial tests.","keywords":["mixture of experts","capability access control","module non-participation","training isolation","sparse MoE","LoRA baseline","routing audit","tool-use benchmarks"],"falsifier":"Install a kernel-level or hardware-level monitor independent of the route logger, such as memory-access tracing on the private expert weights, and issue denied requests with missing, malformed, and adversarially imitated metadata; any observed private-expert computation while $\\tau=0$ would refute G1.","tokens_in":17747,"feed_emoji":"🔒","tokens_out":7860,"duration_ms":63000,"temperature":0.7,"pith_summary":"This paper tries to establish a narrow systems claim: if a sparse mixture-of-experts language model is given a separately trained private expert pool, and trusted authorization selects between the public and private pools before top-$k$ routing, then an unauthorized request executes no private expert. The claim is deliberately separate from capability removal, since the frozen public path may still produce similar behavior and the paper makes no promise that deny removes knowledge. The reason this matters is that conventional access controls regulate model output, whereas this design regulates parameter reachability and gives an operator a deterministic, log-verifiable boundary rather than a behavioral hope. The authors test the boundary in two open MoE models, with zero unauthorized private execution across adversarial scenarios and exact recovery after allow-deny-allow, while showing that the private branch's usefulness on benchmarks varies by distribution.","feed_headline":"Zero private experts execute under deny in masked MoE serving","feed_subtitle":"A hard policy mask before top-k expert routing gives auditable zero-execution, with exact recovery across two models.","key_machinery":"The load-bearing mechanism is a hard policy mask inserted before top-$k$ expert routing at selected wrapped layers. With public pool $E^{\\mathrm{pub}}_{\\ell}$ and private pool $E^{\\mathrm{priv}}_{\\ell}$, the mask sets $m_{\\ell,e}(\\tau)=0$ for the eligible pool and $-\\infty$ for the ineligible pool, then computes top-$k$ on $z_\\ell(h)+m_\\ell(\\tau)$; missing or malformed metadata resolves to deny, so a private index never enters the candidate set. Route logs record every selection, and independent forward hooks on the private modules check that the physical computation matches the log, converting the guarantee into an auditable serving invariant.","core_discovery":"The central claim on the paper's own terms is G1, module non-participation: for any request trace $T(x,\\tau)$, $\\tau=0$ implies $\\mathrm{Exec}(T)\\cap E^{\\mathrm{priv}}=\\emptyset$. This is a deterministic statement conditional on the trusted computing base, and it is verified from route events rather than inferred from generated text. A second claim, G2, says that training touches only the private weights, so every public parameter's fingerprint stays unchanged; a third, G3, says the private branch may improve a declared task distribution, and that is an empirical matter that can fail even when G1 holds. The experiments report all three separately: all 32 Qwen private experts received routes and gradients, deny and fail-closed events recorded zero private selections, independent hooks matched 11,616 routed rows, allow-deny-allow recovery was exact, and utility was positive on two Qwen roles and one DeepSeek role while a valid sealed benchmark was near-neutral.","pith_inferences":["Beyond the paper, the mechanism suggests a multi-tier design where several mutually exclusive expert pools are keyed to different authorization levels, with route logs serving as the per-tier audit trail.","The strongest testable extension would combine the route-log boundary with hardware attestation or kernel-level tracing, closing the side-channel gap the paper explicitly leaves open.","Because the audit records every policy decision, route logs themselves become sensitive policy metadata; deployments would need access controls and retention limits on those logs, a point the paper itself flags.","Since the public path may already implement similar behavior, deny cannot be marketed as capability removal; a deployment evaluation should separately measure public-path leakage rather than rely on the access boundary alone."],"forward_implications":["Operators can treat deny as a deterministic serving invariant rather than a behavioral outcome: if route logs show zero private selections, the private branch was not part of the computation.","The same checkpoint can offer allow and deny arms without retraining, so upstream access changes are reversible and auditable through the allow-deny-allow protocol.","A request-gated adapter is not a substitute: the paper's gated LoRA left 1,225 physical adapter calls under deny, so parameter-level exclusion is what gives the clean audit surface.","Private training can be mixed with a frozen public model without touching public weights, giving a localized, verifiable increment.","Useful capability uplift does not follow automatically from the access boundary; it held on three frozen roles but not on the sealed CCTU benchmark, so deployments still need task-specific evaluation."],"supporting_citations":[{"why":"supplies the Qwen3-30B-A3B model on which the primary private-expert branch and all three training seeds run.","marker":"[21]"},{"why":"supplies the DeepSeek-V2-Lite model that reproduces the route invariant and task effect in cross-model transfer.","marker":"[3]"},{"why":"provides the sparse-gated MoE mechanism that lets a forward pass choose a small set of experts, the substrate the policy mask modifies.","marker":"[15]"},{"why":"defines the LoRA adaptation used for the parameter-matched baseline and the gated-adapter audit that fails the zero-execution endpoint.","marker":"[7]"},{"why":"provides the ToolMind training targets and the held-out task-aligned benchmark used for the +5.0 pp result.","marker":"[22]"},{"why":"provides the fresh external ToolFailBench benchmark and its deterministic Clean Tool-Use Rate used for the +21.3 pp result.","marker":"[16]"},{"why":"provides the sealed CCTU benchmark whose valid near-neutral result delimits the utility claim.","marker":"[23]"},{"why":"documents gate-guided attacks on MoE routers, motivating the hard mask rather than a learned router as the security boundary.","marker":"[19]"},{"why":"documents routing-aware attacks on MoE routers, further supporting the requirement of pre-routing authorization.","marker":"[20]"}],"fun_headline_variants":["Policy masks zero out private experts for unauthorized MoE requests","Deny means zero private-expert execution in sparse MoE serving","Auditable, reversible MoE gating: zero private execution under deny","Private experts stay untouched: policy-masked MoE zero-execution","Unauthorized MoE requests execute zero private experts, exactly"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the masked top-$k$ router is the only execution path into the private experts and that the audit hooks observe every physical private-module invocation; if some runtime path can run private code without a logged route event, the zero-execution claim fails.","fun_headline_variants_meta":{"raw":{"variants":["Policy masks zero out private experts for unauthorized MoE requests","Deny means zero private-expert execution in sparse MoE serving","Auditable, reversible MoE gating: zero private execution under deny","Private experts stay untouched: policy-masked MoE zero-execution","Unauthorized MoE requests execute zero private experts, exactly"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000222,"raw_usage":{"total_tokens":1551,"prompt_tokens":1140,"completion_tokens":411,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":756,"completion_tokens_details":{"reasoning_tokens":323}},"tokens_in":756,"tokens_out":411,"duration_ms":3772,"temperature":1.0,"reasoning_tokens":323,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T14:30:24.067310+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Install a kernel-level or hardware-level monitor independent of the route logger, such as memory-access tracing on the private expert weights, and issue denied requests with missing, malformed, and adversarially imitated metadata; any observed private-expert computation while $\\tau=0$ would refute G1.","supporting_citations":[{"cited_title":"Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, and Weizhu Chen","cited_arxiv_id":null,"evidence_quote":"defines the LoRA adaptation used for the parameter-matched baseline and the gated-adapter audit that fails the zero-execution endpoint."},{"cited_title":"ToolMind technical report: A large-scale, reasoning-enhanced tool-use dataset, 2025","cited_arxiv_id":null,"evidence_quote":"provides the ToolMind training targets and the held-out task-aligned benchmark used for the +5.0 pp result."}],"review_version":3}