{"id":"ce9beb3d-c48c-4c64-9a29-3c0b8ca841da","arxiv_id":"2608.06690","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A hard mask applied before top-k MoE routing lets trusted authorization choose between a frozen public and a newly trained private expert pool, giving auditable zero private execution under deny.","lead":"This paper adds a separate pool of private expert modules to a frozen sparse Mixture-of-Experts model and uses trusted authorization metadata, not prompt text, to decide whether the public or private pool is reachable during routing. Under the model's declared trusted base, unauthorized requests execute zero private experts; the paper tests this with adversarial scenarios, route logs, cross-model replication, and a sealed benchmark.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Physical-execution guarantee is validated only at Python module level; fused MoE kernels could touch private weights under deny invisibly to hooks and route logs.","rationale":"The reader identifies the instrumentation completeness of Section F.1 as the weakest assumption; I agree with that direction. My concern sharpens it into a concrete, testable failure mode: modern MoE serving can execute fused kernels that consume private-expert weight tensors without invoking any Python module forward hook. This is not an inconsistency in the mask logic—given Equation 4 and the declared TCB, Equation 1 follows for the logical candidate set. Rather, the load-bearing empirical question is whether 'Exec(T)' in Equation 1 is measured at the right abstraction level. The paper's own honest limitation statement in F.1 leaves exactly this gap open, and the absence of a public artifact link makes it impossible to inspect the serving stack for such fused execution paths. The proposed CUPTI test settles the question without requiring a formal proof, and it would tell us whether the guarantee needs rewording from 'executes no private expert' to 'routes no token to private experts.' I therefore keep the reader's CONDITIONAL verdict unchanged rather than moving to ACCEPT: the kernel-level check is a condition that should be discharged before the physical-execution wording is taken at face value. The rest of the paper's evidence—matched seeds, exact recovery, adversarial scenarios, and the gated-LoRA contrast—is strong and honestly delimited, but it does not bear on this specific instrumentation-level concern.","tokens_in":16147,"tokens_out":6543,"duration_ms":77600,"concrete_test":"Run the Qwen E4 64-scenario/96-deny suite under CUPTI/Nsight Compute (or CUDA sanitizer) with kernel-level tracking of all loads and writes to the 32 private expert weight tensors. If no kernel reads or writes those buffers during any deny/fail-closed event, the hook-based zero-execution evidence is complete. If any kernel touches a private buffer (for example, a grouped-GEMM launch with zero valid tokens or an all-to-all copy), the paper must either qualify G1 to 'no token is routed to private experts' or move the audit boundary to kernel-level tracing; the conditional verdict should hold until that check is run.","verdict_should_be":"UNCHANGED","load_bearing_attack":"G1 (Eq. 1) claims that deny executes no private expert, and the physical-execution evidence in Section 5.2 is forward-pass hooks on the 32 private modules, with Section F.1 conceding this is not a kernel-level or formal proof. In any serving stack that fuses expert computation (grouped GEMM, CUDA graphs, torch.compile/Inductor—the latter explicitly used for DeepSeek in Section 4.1), a zero-token private expert can still be included in a kernel's weight-tensor read or a zeroed group, producing no routed rows yet consuming the private weights. Module-level hooks and route logs would both report zero. The paper's TCB includes the routing implementation and audit instrumentation, so the logical mask is not at issue; but the auditable 'physical non-participation' endpoint is only as strong as the assumption that every execution path passes through the hooked Python modules. This is not a formal flaw in the mask construction; it is a gap between the claimed physical guarantee and the measurement surface.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper proposes Policy-Masked Private Experts, a capability access-control mechanism for sparse MoE LLMs. The authors freeze a base MoE, add a disjoint trainable private expert pool at selected layers, and place a trusted Boolean policy mask before top-k routing, so that allow routes exclusively to the private pool and deny routes exclusively to the frozen public pool. They formalize three claims: G1, module non-participation under deny (Eq. 1); G2, training isolation of the added increment (Eq. 2); and G3, empirical capability uplift on a declared distribution (Eq. 3). They evaluate the mechanism on Qwen3-30B-A3B and DeepSeek-V2-Lite, using three matched seeds, a parameter-matched LoRA baseline, a 64-scenario adversarial suite (96 deny/fail-closed events), independent forward hooks that match 11,616 routed rows, allow-deny-allow recovery, a sealed CCTU benchmark, and a clean-lock reproducibility audit. The route invariant holds across all audited deny/fail-closed events; utility results are mixed, with positive effects on three roles and a null sealed CCTU result. The paper is careful to distinguish execution control from semantic capability removal and to disclose the boundaries of the TCB.","tokens_in":16280,"tokens_out":13131,"duration_ms":126368,"significance":"If the central claim holds, the paper provides a concrete, auditable mechanism for request-time control over which trained MoE parameters participate in the forward pass, with the security endpoint separated from task utility. The strengths are substantial: independent hook corroboration, three-seed training isolation with unchanged public fingerprints, a broad adversarial authorization suite, exact allow-deny-allow recovery, a valid sealed null result, a detailed failure ledger, and a clean-lock evidence rebuild. The authors also state their limitations clearly, including the absence of kernel-level proof, side-channel analysis, and human annotation. The main contribution is an auditable non-participation boundary rather than universal utility gains, and the utility claims are honestly delimited. The remaining concern is that the physical-execution wording is stronger than the module-level measurement surface, especially for the compiled DeepSeek path.","major_comments":[{"comment":"The headline claim that an unauthorized request 'executes no private expert' is presented as a physical-execution guarantee, but the evidence is forward-pass hooks on Python modules and the paper itself concedes in F.1 that this is 'not a kernel-level or formal proof.' DeepSeek is served with torch.compile (§4.1), so a fused/Inductor kernel could in principle read the private expert weight tensors in a zero-token group without invoking module-level hooks; both route logs and hooks would report zero private execution. The empirical result is therefore as strong as the assumption that every computation path passes through the hooked Python modules. Please either narrow G1 to 'no private module forward pass is invoked' and qualify the 'physical non-participation' language in the abstract and contributions, or add a kernel-level audit for at least the DeepSeek path (e.g., memory-trace inspection of weight-tensor reads or inspection of the generated Triton/Inductor kernels to confirm that private weight tensors are not loaded under deny). This is not a defect in the mask construction, but it is a load-bearing gap between the claimed guarantee and the measurement surface.","section":"§5.2/F.1 and §4.1"},{"comment":"The independent forward-hook audit is reported only for the Qwen SDPA path (32 private modules, 931 calls, 11,616 rows). For DeepSeek, which is the compiled torch.compile configuration, the G1 evidence in Table 5 rests on route logs alone, and route logs cannot detect fused-kernel reads of private weights. The cross-model G1 row is therefore supported to a strictly weaker evidentiary standard than the Qwen row. Please either report the same hook-based physical audit for DeepSeek or explicitly mark the DeepSeek G1 evidence as route-level only in Table 5 and in the main text.","section":"§5.2 and Table 5"}],"minor_comments":[{"comment":"The set Exec(T) is not defined; please state whether it denotes module-level forward invocations or all memory accesses by the serving stack, since the interpretation is central to the physical-execution wording.","section":"§2.2, Eq. (1)"},{"comment":"The independent-hook numbers (931 calls, 11,616 rows) are for the Qwen model; state this explicitly in the sentence where they are introduced to avoid implying that the audit covers the DeepSeek path.","section":"§5.2"},{"comment":"The three 'arm-blinded model evaluators' are not identified; please name the models and versions, since the sensitivity analysis depends on their reliability.","section":"§F.2"},{"comment":"The phrase 'A veraging' appears to be a typo for 'Averaging'; please correct.","section":"§6"},{"comment":"The labels E3, E6, and E7 appear before they are defined; add a one-line explanation of the naming scheme or a pointer to the appendix.","section":"§4.2/§4.3"},{"comment":"The statement that the confidence interval excludes a previously reported five-point decline should cite the prior report or otherwise identify the comparison.","section":"§5.4"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is unusually transparent: preregistrations, failure log, clean-lock rebuild, and hashes are all in place. The main obstacle is not the mask logic, which is sound, but the mismatch between the 'physical non-participation' language and module-level measurement in compiled serving. I would accept a revision that either adds a kernel-level audit for the compiled DeepSeek path or restricts G1 to module-forward non-participation. The task-aligned Qwen p-value is borderline (one-sided .03125, two-sided .0625), but the authors report this honestly, and it does not affect the G1/G2 conclusions. I do not see a circularity or novelty problem; the work fits a security/systems audience."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Worth your time. The core idea is simple and useful: put a hard -infinity mask over a disjoint private expert pool before top-k routing, so authorization decides which parameters can be selected at all. That turns 'the model behaved safely' into 'the private branch was not reachable,' which is a much cleaner claim for access-tiered serving. The paper also does the right kind of work around it: three claims (G1/G2/G3) are separated, benchmarks are preregistered, a sealed CCTU run is reported as near-neutral rather than spun, and the clean-lock rebuild with hashes is a serious reproducibility effort.\n\nThe strongest evidence is for the route invariant: 96 deny/fail-closed events with zero private selections, independent hooks matching 11,616 routed rows, exact allow-deny-allow recovery, unchanged public fingerprints across seeds, and a DeepSeek replication. The LoRA counterfactual is also genuinely informative: a post-hoc gate recovers exactly but still leaves 1,225 adapter calls under deny, so the paper earns its point that logical switching and physical non-participation are not the same thing.\n\nWhere it gets soft: the physical-execution claim is only as strong as the instrumentation. Forward hooks on the 32 private modules will not see a fused kernel (torch.compile, grouped GEMM, CUDA graphs) that reads private weights in a zeroed group without producing routed rows. Section F.1 concedes this is not kernel-level proof. So Equation 1 is precisely a claim about the declared TCB and the audit surface, not absolute physical isolation. The stress-test note lands, but it does not break the paper, because the paper already scopes the guarantee that way. It does mean the title's 'private experts' should be read as 'private modules as observed by the route logger and hooks.' A revision should either measure at a lower level or state the limitation more prominently in the abstract. Also, there is no public artifact link, only hashes; that is a reproducibility gap for a paper this dependent on exact rebuilds.\n\nThe utility results are mixed and honestly reported; the sealed null is a feature, not a flaw. Overall the paper is a solid, well-reasoned contribution that deserves serious peer review. A referee should push on the measurement surface and the missing artifact, but the central route-invariant result holds up as stated.","headline":"A well-scoped, honestly delimited systems paper: hard mask before top-k makes private-expert non-participation under deny an auditable invariant, with the caveat that the audit surface stops at Python modules, not kernels.","tokens_in":16810,"tokens_out":1721,"would_cite":true,"duration_ms":20092,"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":"This paper claims that a trusted authorization mask applied before top-k routing makes unauthorized requests execute zero private experts, an invariant auditable from route logs and independent hooks and exactly reversible across two MoE…","keywords":["sparse mixture of experts","capability access control","policy masking","model authorization","execution audit","training isolation","tool-use benchmarks","parameter reachability"],"falsifier":"Run a denied request under hardware performance-counter or memory-access tracing targeted at the private expert weight pages; any sampled read or execution of those pages during a deny event would falsify the claim that an unauthorized request executes no private expert.","tokens_in":15911,"feed_emoji":"🛡️","tokens_out":9684,"duration_ms":81907,"temperature":0.7,"pith_summary":"This paper tries to establish that capability access control for large language models can be reframed as a reachability problem: which newly trained parameters may the forward pass execute. The proposed mechanism freezes a pretrained sparse Mixture-of-Experts model, adds a disjoint private expert pool, and uses trusted authorization metadata, never prompt text, to select either the public or private pool before top-k routing. The core claim is that under the declared trusted computing base, an unauthorized request executes zero private experts, an invariant verified from route logs and independent forward hooks, with allow-deny-allow recovery exact. The paper deliberately separates this execution-control claim from task utility: the private branch improves some frozen tool-use benchmarks but is near-neutral on a sealed benchmark, so the access boundary holds even when knowledge transfer does not. If the paper is correct, operators can obtain an auditable, reversible guarantee that a newly trained parameter branch did not participate in a denied request, without claiming the public path lacks the capability.","feed_headline":"Denied requests execute zero private MoE experts","feed_subtitle":"Trusted metadata, not prompt text, picks the expert pool; deny leaves the private branch untouched.","key_machinery":"The load-bearing mechanism is the hard policy mask inserted between the router logits and top-k selection at wrapped MoE layers: $m_{\\ell,e}(\\tau)=0$ for the eligible pool and $-\\infty$ for the ineligible pool, making the public and private expert pools mutually exclusive for each row and token. Because an ineligible private index never enters the candidate set, prompt text cannot steer a denied request into a private expert, and missing or malformed authorization resolves to deny. The companion audit machinery consists of route logs recording every token–expert selection plus independent forward hooks installed directly on all private modules, which together make the zero-execution invariant measurable rather than inferred from generated text, and a fixed allow–deny–recovery toggle protocol that tests reversibility of the same checkpoint. The mask carries the security argument; the logs and hooks carry the auditability claim.","core_discovery":"The paper's central claim is that a trusted authorization decision can determine which parameters a forward pass may execute, not merely how the model behaves. In a frozen sparse MoE, the authors add a disjoint private expert pool and apply a hard mask $m_{\\ell,e}(\\tau)$ to the router logits before top-$k$ selection: $\\tau=1$ exposes only the private pool, $\\tau=0$ exposes only the public pool. This yields the invariant $\\tau = 0 \\Rightarrow \\mathrm{Exec}(T) \\cap E^{\\mathrm{priv}} = \\varnothing$ for any request trace $T(x,\\tau)$, so prompt text, role imitation, and malformed metadata cannot alter the decision and all failures resolve to deny. The paper treats this zero-execution statement as the primary security endpoint and audited it through 96 deny/fail-closed events, 11,616 routed rows exactly matched by independent hooks, and exact allow–deny–allow recovery on Qwen3-30B-A3B and DeepSeek-V2-Lite. It also shows the guarantee is narrower than capability removal: a post-hoc gated LoRA still recorded 1,225 adapter calls under deny while the disjoint expert branch recorded none, and a valid sealed benchmark was near-neutral.","pith_inferences":["Going beyond the paper, the same mask mechanism could support multiple private tiers by letting trusted metadata select among several disjoint pools, turning a binary allow/deny into a tiered capability policy.","Because the paper's zero-execution measurement relies on in-process hooks, a natural next step is to anchor the invariant in hardware memory protection or attestation so the audit does not share a failure mode with the route logger.","The distribution-dependent utility results imply that operators should validate private-pool training on their own target distribution before deployment; the access boundary can hold while the capability increment is useless on a given task.","The gated-LoRA negative result suggests a testable standard for other parameter-efficient adaptation methods: any adapter claimed to be access-controlled should be held to a physical non-participation audit, not just a logical gate."],"forward_implications":["Operators can verify from route logs and independent hooks that a newly trained private expert branch never participated in a denied request, making capability tiers inspectable at the parameter level rather than inferred from output behavior.","The same checkpoint can be toggled allow, deny, and back, with recovery reproducing the allowed route and matched outputs exactly, so the control is reversible without retraining or re-serving.","A logical or behavioral gate is not enough: the gated LoRA control recorded 1,225 adapter calls under deny, so parameter non-participation must be audited separately from output-level policy.","Private-branch training can improve task utility on some frozen benchmarks while being near-neutral on a sealed benchmark, so the access boundary and the utility claim stand or fall independently.","Because the policy decision is made by trusted metadata before routing, prompt-based attacks such as instruction override, role imitation, and private-name imitation cannot change the expert pool a request may reach."],"supporting_citations":[{"why":"Supplies the primary Qwen3 model and its MoE architecture used for the main experiments.","marker":"[10]"},{"why":"Supplies the DeepSeek-V2 model and MoE architecture used for cross-model replication of the route invariant.","marker":"[3]"},{"why":"Establishes sparse MoE conditional computation as the substrate the mechanism modifies.","marker":"[4]"},{"why":"Provides a sparse MoE architecture whose top-k routing the hard mask overrides.","marker":"[7]"},{"why":"Defines the parameter-matched LoRA baseline and the gated-adapter audit target.","marker":"[5]"},{"why":"Provides the task-aligned ToolMind benchmark used to measure private-branch utility.","marker":"[13]"},{"why":"Provides the fresh external ToolFailBench benchmark and its deterministic CTUR scoring rule.","marker":"[14]"},{"why":"Supplies the sealed CCTU benchmark whose near-neutral result bounds the utility claim.","marker":"[18]"},{"why":"Shows learned MoE routers can be attacked, motivating the hard mask rather than router-based gating.","marker":"[16]"}],"fun_headline_variants":["Zero private MoE experts on denied requests","Denied requests execute zero private experts","Access control that blocks private expert execution","No private expert execution without authorization"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The zero-execution guarantee is measured through route logs and forward hooks installed on the private modules, so if those instruments miss an execution path or share a common failure mode, a denied request could execute a private expert even though the mask logic in the declared trusted computing base is correct.","fun_headline_variants_meta":{"raw":{"variants":["Zero private MoE experts on denied requests","Denied requests execute zero private experts","Access control that blocks private expert execution","No private expert execution without authorization"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000246,"raw_usage":{"total_tokens":1663,"prompt_tokens":1194,"completion_tokens":469,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":810,"completion_tokens_details":{"reasoning_tokens":418}},"tokens_in":810,"tokens_out":469,"duration_ms":4800,"temperature":1.0,"reasoning_tokens":418,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T22:23:48.498766+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a denied request under hardware performance-counter or memory-access tracing targeted at the private expert weight pages; any sampled read or execution of those pages during a deny event would falsify the claim that an unauthorized request executes no private expert.","supporting_citations":[{"cited_title":"Fedus, B","cited_arxiv_id":null,"evidence_quote":"Establishes sparse MoE conditional computation as the substrate the mechanism modifies."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the parameter-matched LoRA baseline and the gated-adapter audit target."},{"cited_title":"ToolFailBench: Diagnosing Tool-Use Failures in LLM Agents","cited_arxiv_id":"2607.04686","evidence_quote":"Provides the fresh external ToolFailBench benchmark and its deterministic CTUR scoring rule."}],"review_version":2}