{"id":"64cd8e6d-a962-4856-8cdc-176ebf401de0","arxiv_id":"2607.21642","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":7,"one_line_summary":"CARE verifies shell commands from LLM agents in milliseconds, catching dangerous ones with 85.64% F1 and 0.91% false-positive rate while preserving most benign workflows.","lead":"CARE is a new safety layer that checks each shell command an AI coding agent wants to run, blocking dangerous ones before they execute. It combines fast static rules with a selective AI judge, hitting 85.64% F1 with only 0.91% false positives at 2.32 ms per command.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Rule-bank overlap with the main eval source may inflate CARE's headline F1; the paper acknowledges but never quantifies this.","rationale":"The reader's weakest_assumption is about bounded canonicalization, which is a real technical limitation but is explicitly scoped in §III-C as 'bounded normalization, not full semantic recovery' and the paper's central claim is framed as partial risk reduction. The source-overlap issue, by contrast, threatens the empirical validity of the headline numbers that the abstract and strongest claim cite. The paper's own OOD results provide independent support, but they are weaker and higher-FPR; they don't rescue the specific 85.64/0.91 numbers. The reader lists source-overlap in the rationale but not as the weakest assumption, so agreement is partial. Verdict remains CONDITIONAL: the paper should quantify rule-authoring independence before the headline is taken at face value.","tokens_in":24602,"tokens_out":6555,"duration_ms":58272,"concrete_test":"Re-run the main split with a rule bank whose MITRE tier is authored exclusively from the ATT&CK technique pages (or any public source that excludes ART and RedCode-Exec), keeping all other components and thresholds fixed. If F1 on the 549-command split drops more than a few points (e.g., below 80%) or FPR rises substantially, the headline is inflated by source overlap. Alternatively, use leave-one-source-out: author rules only on ART, evaluate on RedCode-Exec and vice versa; if cross-source F1 is far below within-source, the rules are source-specific. This test directly quantifies the overlap the paper leaves open.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central deployment claim rests on the main-split numbers (Table II): 85.64% F1, 0.91% FPR. The dangerous half of that split is 208/220 commands from ART and RedCode-Exec, and the rule bank's largest provenance tier is 92 MITRE ATT&CK rules. Section IV-D says the lexicon and rules were 'curated from public offensive corpora, benchmark-derived error analysis, and expert annotation'; §VI admits 'source overlap is mitigated but possible.' The template-family split prevents dev/eval leakage at the command level, but it does nothing to prevent rule-authoring leakage: if the MITRE rules were written or refined after inspecting ART/RedCode examples, the main-split F1 measures rule memorization rather than generalization. The OOD corpora are cleaner (GTFOBins uses a binary-hash holdout, Exploit-DB is outside the rule bank's provenance tiers), and those numbers are materially weaker: GTFOBins F1 68.91, Exploit-DB 66.33, OOD FPR 8.13–13.04%. The abstract's '85.64% F1' is the headline, so the unquantified overlap is the most load-bearing threat to the claim that CARE is deployment-ready. If the overlap is large, the main-split results are not evidence for real-world performance; if it is small, the paper should show that.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents CARE (Canonicalization, Attribution, and Resolution Engine), a static-first, pre-execution verifier for shell commands generated by LLM agents. CARE canonicalizes each command, extracts deterministic multi-view evidence (syntax, semantic classification, path sensitivity, provenance-tagged pattern rules), and selectively escalates only WARN-band cases to an LLM judge. The main claimed results are 85.64% F1 with 0.91% FPR at 2.32 ms mean latency on a balanced main split, and 84.99% F1 at 0.34 ms in a static-only profile, with a realised-harm reduction on RedCode-gen to 37.33%. The evaluation compares against 12 baselines, including LLM judges, content-safety classifiers, and static rule guards, across a leakage-controlled main split, a utility benchmark, OOD corpora, obfuscation suites, and a Docker-executed attack-command track.","tokens_in":25012,"tokens_out":5490,"duration_ms":52813,"significance":"If the headline results are robust, CARE is a meaningful contribution: it shows that a shell-specific, deterministic, low-latency verifier can occupy a practically useful region of the detection–FPR–latency trade-off, with an auditable evidence trace and a selective LLM escalation mechanism. The paper is unusually transparent: it releases the rule bank, evaluation splits, and prompts; reports Wilson intervals for OOD FPR; and explicitly discusses known threat-model limits (session-level attacks, bounded canonicalization, judge/generator overlap). These strengths make the work reproducible and the claims checkable. The main risk is that the headline performance on the main split may be inflated by rule-bank overlap with the evaluation corpora, and the FPR estimates are based on very few false positives, so the deployment-ready claim is conditionally supported rather than fully established.","major_comments":[{"comment":"The main-split dangerous set is 208/220 commands from ART and RedCode-Exec, while the rule bank's largest tier is 92 MITRE ATT&CK rules. Because ART is MITRE-aligned and RedCode-Exec is also a public offensive corpus, the rule-authoring and evaluation sources overlap. §VI admits 'source overlap is mitigated but possible,' but no quantification is given. The headline 85.64% F1 on Table II could partly reflect rule memorization rather than generalization. Please report: (i) the fraction of main-split dangerous commands that trigger MITRE-tier rules; (ii) an evaluation where rules are re-authored without access to ART/RedCode examples, or a leave-one-source-out analysis; (iii) the same metrics for GTFOBins and Exploit-DB, whose F1 values (68.91 and 66.33) are materially lower. This is load-bearing because the abstract and deployment claims rest on the main-split numbers.","section":"§IV-B, §IV-D, Table II"},{"comment":"With 329 safe commands, the 0.91% FPR is 3 false positives and 1.82% FPR is 6 false positives. No confidence interval is reported for these main-split FPRs; a 95% Wilson interval for 3/329 is approximately [0.2%, 2.7%], which overlaps rates that are not 'low' in absolute terms. Moreover, Appendix Table VIII reports p=0.25 for CARE vs. CARE (w/o Resolution), so the Resolution-stage FPR halving is not statistically significant. The paper correctly states this in the text, but the abstract's unqualified '0.91% false-positive rate' overstates precision. Report Wilson intervals for the main-split FPR and explicitly present the 0.91% as a noisy point estimate.","section":"§V-A1, Table II, Appendix Table VIII"},{"comment":"On the three OOD mixed-label corpora, CARE's FPR is 13.04%, 11.60%, and 8.13% (full) and 15.94%, 13.20%, and 8.94% (static-only) — roughly 10–100 times the 0.91% main-split FPR. The deployment-oriented discussion in §V-C acknowledges this, but the abstract and introduction present the 0.91% rate without this qualification. The main-split FPR is an in-distribution diagnostic, not a credible deployment FPR under distribution shift. Please add a sentence to the abstract/introduction noting that OOD FPR is in the 8–16% range, and clarify that the headline FPR is specific to the balanced, leakage-controlled split.","section":"Table V, §V-C"}],"minor_comments":[{"comment":"Reference [25] is titled 'Qwen3-4B-Instruct' but the text and Appendix A.6 use Qwen3-Coder-30B-A3B-Instruct. The reference does not match the model actually used.","section":"References [25]"},{"comment":"Figure 3 contains garbled placeholder strings (e.g., 'out: ? ? , ???????') that appear to be rendering artifacts. The figure should be regenerated so labels are legible.","section":"Figure 3"},{"comment":"The sentence 'Full CARE is 15.17 pp higher than CARE (w/o Resolution)' should specify 'realised-harm rate is 15.17 pp higher' to avoid ambiguity with F1.","section":"§V-C3, paragraph after Table V"},{"comment":"The limitation that canonicalization is bounded and not full semantic recovery is correctly stated, but a concrete example of a command class outside the rewrite families (e.g., deep custom eval loops or novel encoding) would help readers calibrate the residual evasion surface.","section":"§VI, Scope and limitations"}],"recommendation":"major_revision","confidential_remarks":"The paper is a solid systems contribution with a high level of transparency. The key condition for acceptance is a quantitative treatment of the rule-bank/eval overlap and statistical precision of the headline FPR. If the authors can add a provenance-disjoint evaluation and report confidence intervals for main-split FPR, I would be willing to accept. The OOD results already provide a partial check, but the abstract currently overstates the strength of the main-split evidence."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: CARE is a plausible static-first guard for shell dispatch in LLM agents, and the paper deserves a serious referee. But the abstract overstates the result. The main-split F1 of 85.64% is built on a rule bank curated from the same public offensive corpora (ART, RedCode) that form the dangerous half of that split. The authors acknowledge the overlap in Section VI but never quantify it. The held-out GTFOBins bucket and Exploit-DB shift are cleaner, and there CARE lands at 68.9 and 66.3 F1, with OOD FPR at 8-13%. That is still useful, but it is a different claim than “deployment-ready.”\n\nWhat is actually new: the integration. Bounded canonicalization, multi-view static attribution, and selective LLM escalation on just the WARN band is a sensible design that no prior shell guard puts together. The paper is transparent about its internals — weights, thresholds, rule provenance, prompts are all in the appendix, and the artifact is released. That reproducibility is real credit. The ablation shows the semantic layer does the heavy lifting, and the sensitivity sweep is honest about the DR/FPR trade-off.\n\nWhere it is soft, in proportion:\n\n1. Overlap quantification. The rule bank carries 92 MITRE rules; 208 of 220 dangerous main-split commands come from ART and RedCode-Exec. The template-family split prevents command-level leakage but not rule-authoring leakage. This can be fixed in revision — the rule bank is public — but it is the load-bearing threat to the headline.\n\n2. Tiny FPR counts. A 0.91% FPR on 329 safe commands is three false positives. They report Wilson intervals for some OOD buckets and McNemar for headline comparisons, but the main table has no CI. That should be added.\n\n3. RedCode-gen harm trade-off. The static profile cuts realised harm to 37.33%; full CARE is 52.5%. The abstract highlights the static profile but does not flag that the Resolution judge over-allows on paraphrase-shared attacks. It is a real finding and they report it, but the presentation buries the trade-off.\n\n4. The judge-sharing caveat is handled honestly with Qwen3-independent anchors, so I do not count it heavily.\n\nIs it a new result? Yes, as a system. Each component is known; the combination with this evaluation is not. The math is procedural, not deep, but internally consistent.\n\nWho is this for? Anyone building runtime guards for coding agents. A security venue referee would find it concrete and a good basis for follow-up, especially if the overlap question is answered.\n\nMy recommendation: send it to peer review with a request for quantitative overlap analysis and error bars. Not a desk reject. The paper’s own OOD results are the strongest evidence it deserves a shot — if it were pure memorization, the held-out numbers would collapse harder.","headline":"Real system, credible engineering, but the headline F1 rests on an unquantified rule-bank overlap with the main eval source; the OOD numbers tell a more honest story.","tokens_in":25505,"tokens_out":3131,"would_cite":true,"duration_ms":26940,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A static-first verifier can block dangerous LLM-agent shell commands at the dispatch boundary in milliseconds while preserving most benign workflows.","keywords":["shell command safety","LLM agents","pre-execution verification","canonicalization","static analysis","runtime guardrail","command dispatch","false positive rate"],"falsifier":"Construct a destructive `rm -rf` equivalent using an obfuscation technique not in CARE's rewrite list—for example a new encoding, an unusually deep command-substitution nest, or a custom eval loop—and check whether the guard denies it before execution. If such a command is allowed and executes harmful behaviour, the bounded-canonicalization assumption is violated. A systematic version would measure recall on a held-out corpus of adversarially novel obfuscations.","tokens_in":24507,"feed_emoji":"🛡️","tokens_out":6380,"duration_ms":49986,"temperature":0.7,"pith_summary":"The paper argues that shell command dispatch is the critical safety boundary for LLM agents, and that a shell-specific, static-first verifier can mediate individual commands before execution. CARE canonicalizes each command into a stable non-executed form, then derives deterministic evidence over syntax, command semantics, path targets, and provenance-backed risk patterns, escalating only borderline commands to an LLM judge. On a balanced split, CARE reaches 85.64% F1 with a 0.91% false-positive rate at 2.32 ms mean latency; a fully static profile retains 84.99% F1 at 0.34 ms and reduces realised harm on LLM-generated attack commands in a container sandbox to 37.33%. If these results hold, a cheap deterministic filter can catch most dangerous commands with a very low burden on safe work.","feed_headline":"Shell guard stops 76% of unsafe LLM commands at 2 ms","feed_subtitle":"Static-first verifier keeps 85% F1 and 0.9% false positives, preserving most benign workflows.","key_machinery":"The Canonicalization–Attribution–Resolution pipeline is the load-bearing object. Bounded canonicalization unwraps shell wrappers, normalizes quoting and whitespace, and applies light deobfuscation to produce a stable verification target without executing it. Attribution combines L1 structural (AST) penalties, L2 semantic risk scores, L3 path-context scores that treat reads and writes asymmetrically, and L4 provenance-tiered pattern rules into an additive composite score; L5 maps the score to ALLOW/WARN/DENY thresholds. Resolution preserves high-confidence verdicts and uses skip predicates to deny conclusively dangerous WARN cases without an LLM, reserving the judge for residual ambiguity.","core_discovery":"CARE's central claim is that a layered deterministic analysis of the canonicalized command string is sufficient to assign most commands a high-confidence verdict, and that neural adjudication is only needed for genuinely ambiguous cases. The system computes a composite risk score from four evidence signals: AST structure, a curated semantic lexicon over command heads and flags, a path-sensitive read/write analysis of file targets, and a provenance-weighted pattern bank. Provisional ALLOW and DENY decisions are finalized statically; only WARN-band commands are escalated, and skip predicates ensure that commands with already-conclusive static evidence never incur an LLM call. The paper reports","pith_inferences":["The bounded-canonicalization assumption could be stress-tested by generating novel obfuscation families (new encodings, deep nesting, custom eval loops) and measuring whether CARE's static signals still fire; this is the most direct way to probe the method's limit.","A natural extension is to make the Resolution policy conditional on the command generator: if generator and judge share the same model distribution, the static-only profile may be safer, as the paper's RedCode-gen result suggests.","The provenance-weighted rule bank is a transferable design: assigning authority weights to rules based on external catalogs could be adapted to other agent tool boundaries, not just shell dispatch.","Because CARE sees only the command and bounded path context, risks carried in shell state, environment variables, or multi-command trajectories remain out of scope; an adversary could attempt to shift harm into those channels."],"forward_implications":["Deployments can choose between two profiles: full CARE for low false-positive benign-task recovery and static-only CARE for zero-LLM, conservative harm reduction.","Because the guard is a single-command, stateless check, it composes with trajectory-level defenses and OS-level sandboxing rather than replacing them.","The static evidence stack alone accounts for most of the detection, implying deterministic analysis can handle the common case without a model call.","The read/write path asymmetry prevents a common false positive (blocking `cat /etc/os-release`) while still flagging writes to sensitive files.","The paper's finding that the LLM judge sometimes over-allows commands on paraphrase-shared attack shifts suggests that resolution should be tuned per deployment context."],"fun_headline_variants":["Shell guard screens unsafe LLM commands in 2ms with 85% F1","CARE static verifier for shell commands: 0.9% false positives","LLM shell command mediation cuts RedCode harm to 37%","Pre-execution shell verification for LLM agents: 2ms fast, 85% F1"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that the fixed, bounded set of canonicalization rewrites is sufficient to expose the underlying risk in adversarial commands; a command using an unlisted encoding, deeply nested substitution, or a custom eval loop may be analyzed in a form where the static signals are absent and could reach execution.","fun_headline_variants_meta":{"raw":{"variants":["Shell guard screens unsafe LLM commands in 2ms with 85% F1","CARE static verifier for shell commands: 0.9% false positives","LLM shell command mediation cuts RedCode harm to 37%","Pre-execution shell verification for LLM agents: 2ms fast, 85% F1"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001123,"raw_usage":{"total_tokens":4540,"prompt_tokens":805,"completion_tokens":3735,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":549,"completion_tokens_details":{"reasoning_tokens":3646}},"tokens_in":549,"tokens_out":3735,"duration_ms":26145,"temperature":1.0,"reasoning_tokens":3646,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T12:22:15.473557+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Construct a destructive `rm -rf` equivalent using an obfuscation technique not in CARE's rewrite list—for example a new encoding, an unusually deep command-substitution nest, or a custom eval loop—and check whether the guard denies it before execution. If such a command is allowed and executes harmful behaviour, the bounded-canonicalization assumption is violated. A systematic version would measure recall on a held-out corpus of adversarially novel obfuscations.","supporting_citations":[],"review_version":1}