{"id":"1add974d-1946-4cc0-b242-3496c6d23d23","arxiv_id":"2607.29254","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Schema-formatted tool specifications degrade refusal in LLM agents; using flattened textual specifications during safety judgment substantially restores refusal and blocks prompt injection.","lead":"This paper finds that the schema/JSON format of tool descriptions, not their content, is a major reason LLMs become less safe as agents, and proposes a safeguard that judges requests with flattened text while keeping the original format for execution. Across four LLMs and two benchmarks, the defense raises refusal of harmful requests from about 24% to 71% and cuts prompt-injection success from about 26% to 2.5%.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Flattened tool-spec preservation is untested; safety gains may reflect induced judge incompetence rather than recovered native refusal.","rationale":"The reader's weakest assumption identifies the same load-bearing concern: flattening is assumed to preserve semantics, but this is untested. My analysis adds that the SafeJudge control does not establish semantic equivalence, and the semantic-randomization control is not a clean manipulation because pseudowords may preserve structural cues. If this concern lands, the paper's central mechanistic claim—that schema form, not tool semantics, causes safety degradation—is weakened, though the empirical SafeKeep defense may still hold. The reader's verdict of CONDITIONAL is appropriate: the paper should be accepted only if the semantic-preservation assumption is verified or if the claims are softened to describe an empirical effect without the strong mechanism. I recommend no change to the verdict because the concern is already embedded in the conditional acceptance.","tokens_in":11426,"tokens_out":8585,"duration_ms":92759,"concrete_test":"Use the paper's conversion rules to flatten all tool specs in the paired ToolSafety dataset. For each spec, have the same LLM used in SafeKeep answer five factual comprehension questions (required arguments, argument types, tool function, side effects, permission scope) from the schema-formatted and flattened-text forms, counterbalanced. Compare accuracy with a significance test (e.g., McNemar). If flattened-text accuracy is more than 10% lower than schema accuracy, the conversion does not preserve safety-relevant semantics, and the 'representation-only' mechanism story is unsupported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that schema format, not semantics, drives safety degradation rests on the assumption that converting schema-formatted tool specifications into flattened text preserves all safety-relevant semantic content. The conversion rules (§3.3, §5) remove JSON syntax, nested structure, type declarations, and required-field markers—information that can be safety-critical (e.g., whether an argument is required, whether a tool has side effects). The paper never verifies semantic equivalence: SafeJudge (§6.4) only shows that a judge using flattened text refuses more often, but it does not show that the judge still understands the tools. The semantic-randomization control (Table 2) replaces words with pronounceable pseudowords while keeping syntax; the small AUROC change does not cleanly separate representation from semantics because the model may still parse structural cues, and pseudowords may not fully randomize embeddings. More importantly, SafeKeep's safety-judgment stage is a separate binary classifier, not the original agent's generation; its increased refusal could stem from the judge being more cautious when tools are less precisely specified, rather than from 'recovering native refusal.' Thus the mechanistic interpretation of the central claim is not yet secured.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper investigates why LLMs become less safe when deployed as tool-using agents. Using a paired harmful/benign dataset derived from ToolSafety, it shows that adding tool specifications to an agent context degrades the hidden-state separability of harmful and benign requests along a refusal direction (Section 3.2, Table 1), and that converting schema-formatted tool specifications into flattened textual descriptions largely restores separability, whereas replacing tool semantics with pseudowords does not (Section 3.3, Table 2). The paper defines a 'Schema Direction' as the average hidden-state difference between schema-formatted and flattened textual specifications, shows that it opposes the refusal direction, and reports that activation steering against this direction increases refusals (Section 4, Table 3). It then proposes SafeKeep, a two-stage inference-time safeguard that judges requests using flattened textual tool specifications while retaining the original schema-formatted specifications for execution. On AgentHarm and InjecAgent across Llama3.1-8B-Instruct, Qwen3-8B, Gemini3.1-Flash, and GPT5.4-mini, SafeKeep increases the average refusal rate from 23.8% to 70.6% and reduces the average attack success rate under prompt injection from 25.6% to 2.5% (Table 4). A control with schema-formatted specifications during safety judgment (SafeJudge) performs substantially worse, supporting the claim that the flattened representation is critical to the safeguard's effectivene","tokens_in":11723,"tokens_out":6847,"duration_ms":69468,"significance":"If the conclusions hold, the paper makes a valuable and non-obvious contribution: the representational format of tool specifications, not only their semantics, can materially undermine an LLM's refusal behavior, and a lightweight inference-time reformatting can recover much of the model's native refusal capability without retraining or activation access. The study is unusually thorough in several respects: component-level ablations on three open-weight LLMs, a length-matched control, a semantic-randomization control, a paired dataset with manual verification, a controlled SafeJudge comparison, and public code/data release. The SafeKeep defense is model-agnostic and preserves the original execution pipeline. The main weakness is that the mechanistic interpretation of the central claim rests on an untested semantic-equivalence assumption and on a steering experiment that is partly a manipulation check; these issues do not necessarily invalidate the empirical defense, but they do mean the paper currently overstates confidence in the proposed mechanism.","major_comments":[{"comment":"The central attribution depends on the assumption that converting schema-formatted tool specifications to flattened text preserves all safety-relevant semantic content. The conversion removes JSON syntax, nesting, type declarations, and required-field markers, but the paper never independently verifies that the model still understands the tools. The SafeJudge control (Section 6.4) only shows that a judge using flattened text refuses more; it does not show that the judge is not simply more conservative when tool specifications are less precise. This alternative explanation must be addressed (e.g., a tool-selection or functional-understanding test on flattened vs schema specs, or human semantic-equivalence ratings on the converted texts) before the conclusion that the format, rather than the semantics, drives degradation is fully supported.","section":"Section 3.3 and Section 5"},{"comment":"The steering experiment is partly a manipulation check. R_harmful in Eq. (2) is defined as the average schema-minus-text hidden-state difference; subtracting it in Eq. (3) is expected to move activations toward the text condition, so observing more refusals is consistent with the definition but does not, by itself, establish that the Schema Direction causally mediates unsafe tool execution. The causal conclusion needs controls: random directions with the same norm, the benign-request Schema Direction, or a direction constructed from an unrelated representation change, matched in intervention strength. Table 3 also reports a single run without confidence intervals; with roughly 120 harmful requests in the evaluation split, the 47.5% vs 5.0% difference at alpha=4 should be accompanied by a confidence interval or repeated sampling.","section":"Section 4.1 and Section 4.4"},{"comment":"All results are point estimates with no confidence intervals, significance tests, or number of repeats. This matters for the source-localization claim because several comparisons are small (e.g., Table 2: Qwen original 0.786 vs semantic randomization 0.770; Table 1: Mistral chatbot 0.921 vs Chatbot-Long 0.915). Bootstrap or per-example confidence intervals on AUROC, and repeated evaluation runs for Table 4, would establish which differences are reliable. Without these, the precision implied by three-decimal AUROC values is difficult to assess.","section":"Tables 1-4"}],"minor_comments":[{"comment":"There is a typo: a stray period appears before 'SafeKeep is model-agnostic' at the start of the subsection.","section":"Section 6.3"},{"comment":"The Schema Direction R_c is defined in Eq. (2) without normalization, but Eq. (3) uses a unit-normalized version. The paper should clarify which quantity is used in Figure 3 and the cosine-similarity analysis in Section 4.2.","section":"Eq. (2) and Eq. (3)"},{"comment":"The random-direction baseline is described verbally but not shown quantitatively. Reporting the distribution of random-direction cosine similarities and the number of samples would make the 'negative at every layer' claim easier to evaluate.","section":"Section 4.2"},{"comment":"AgentHarm 'Acc' is a combined metric that jointly rewards refusal of harmful requests and correct handling of benign requests. Reporting benign-request accuracy separately would make the capability-preservation claim easier to verify, especially in cases where refusal rates are high.","section":"Table 4"},{"comment":"For GPT5.4-mini, ASR-B and ASR-E are 0.0 for most methods; the 'best or tied-best in 11 of 12 combinations' statement should explicitly account for ties so the reader can see where SafeKeep is not strictly better.","section":"Table 4"}],"recommendation":"major_revision","confidential_remarks":"The core SafeKeep defense is promising and the empirical evaluation is broad. My main concern is that the paper bets its mechanistic interpretation on two pillars that need additional support: the semantic equivalence of flattening, and the causal interpretation of the steering experiment. Both are fixable with additional experiments. If those experiments fail, the SafeKeep result may still stand as an empirical safeguard, but the paper's title-level claim would need substantial revision. I therefore recommend major revision rather than rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know this paper: it identifies schema-formatted tool specifications as a primary cause of agent safety degradation and shows that flattening those specs during safety judgment substantially restores refusal. The core finding is that it is the representation, not the underlying tool semantics, that matters. That is a genuinely new and practically useful result.\n\nWhat the paper does well: the component-level ablation in Table 1 is clean and consistent — tool specs cause the biggest AUROC drop across three open models, and length controls rule out context length. The representation-vs-semantics split in Table 2 is a good experiment: flattening schema to text recovers much of the separation, while pseudoword randomization does not. SafeKeep is a simple, inference-time defense that works across open and closed models, and the SafeJudge control showing that schema-formatted judgment is far weaker supports the flattening mechanism. They also ship code and data, which is real evidence.\n\nSoft spots, in proportion:\n\n1. No confidence intervals or significance tests in any of the main tables. The numbers are consistent across models, but for a paper making a mechanistic claim, this is a real omission.\n\n2. The Schema Direction in Eq. (2) is computed over 'all examples in category c', and Eq. (3) subtracts that same direction and reports recovery. As written, the steering experiment is partly a manipulation check, not fully independent causal evidence. A held-out split and out-of-sample steering would fix this.\n\n3. The biggest issue, also raised in the stress-test: the semantic-preservation assumption is untested. The paper's conversion rules strip JSON syntax, required-field markers, and nested structure. SafeKeep's gains are credited to 'recovering native refusal,' but the only control (SafeJudge) shows that flattened judgment refuses more often — it does not show the judge still understands the tools. It is possible the defense works by making the judge more cautious/vaguer rather than by restoring the model's original refusal. The high benign accuracy and valid rates push back on that reading, so I would not call it fatal, but the paper does not close the door.\n\nAlso, the 'primary source' claim is a bit overbroad given the ablation is on three open LLMs and the mechanism on one. Still, the empirical defense is robust enough to matter.\n\nWho this is for: anyone working on agent safety, refusal mechanisms, or prompt-injection defenses. It deserves a serious referee. I would send it, and the main review requests would be out-of-sample steering, error bars, and an explicit semantic-equivalence check for the flattening conversion.","headline":"The paper isolates schema-format representation (not tool semantics) as a major driver of agent safety degradation and ships a lightweight, apparently effective defense; the mechanism story is plausible but partly self-referential and needs semantic-equivalence and out-of-sample checks.","tokens_in":12134,"tokens_out":2088,"would_cite":true,"duration_ms":22740,"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":"Schema-formatted tool descriptions, not the tools themselves, are why LLM agents lose their safety guardrails.","keywords":["LLM agents","tool specifications","refusal direction","safety alignment","prompt injection","schema formatting","inference-time safeguard","representation analysis"],"falsifier":"Have an independent judge verify that each flattened tool specification is semantically equivalent to its schema version, then re-run SafeKeep only on pairs where equivalence strictly holds. If the refusal improvement disappears on that verified subset, the effect is information loss from flattening rather than recovery of the refusal representation.","tokens_in":11349,"feed_emoji":"🛡️","tokens_out":6338,"duration_ms":61593,"temperature":0.7,"pith_summary":"The paper claims that when an LLM is deployed as an agent, the largest source of safety degradation is not the semantics of the tools but the schema-style format used to describe them. Presenting the same tool information in flattened plain text restores the model's internal refusal signal and blocks harmful execution. Building on that mechanism, the paper proposes SafeKeep, a lightweight inference-time safeguard that checks requests against flattened tool descriptions while leaving the original formatted specifications in place for execution. Across two benchmarks and four LLMs, SafeKeep raises the refusal rate for harmful requests from 23.8% to 70.6% and lowers average prompt-injection attack success from 25.6% to 2.5%. If the claim holds, agent safety can be improved substantially without retraining or any access to model internals.","feed_headline":"Tool specs, not tools, break LLM agent safety","feed_subtitle":"Rewriting tool descriptions as plain text during the safety check raises refusals from 24% to 71% and cuts prompt-injection success from 26%","key_machinery":"The refusal direction is the average hidden-state difference between harmful and benign requests, used as a probe for how strongly refusal features are activated. The Schema Direction is the average hidden-state change induced by presenting the same tool specification in schema form rather than flattened text; its opposition to the refusal direction for harmful requests is the paper's mechanistic evidence. SafeKeep is a two-stage inference-time framework: Safety Judgment scores requests with flattened textual tool specifications, and Execution Control forwards safe requests to the original agent pipeline (schema preserved) or blocks and redirects to refusal generation.","core_discovery":"Schema-formatted tool specifications are a primary cause of agent safety degradation. Component ablations show tool specs produce the largest drop in harmful-benign separation along the model's refusal direction; converting specs from schema to flattened text while preserving semantics largely restores separation, whereas randomizing semantics while keeping schema format does not. White-box analysis defines a Schema Direction—the average hidden-state change from flat to schema presentation—and shows it opposes the refusal direction for harmful requests at every layer; activation steering against it converts harmful tool execution into refusal. SafeKeep operationalizes the finding by decoupli","pith_inferences":["If formatting and not semantics is the trigger, other structured encodings—XML, typed signatures, code stubs—may also suppress refusal, so agent builders should treat description format as a safety knob.","SafeKeep reuses the same LLM to judge and to act, so a request that the flat-text judge marks safe but the schema-formatted executor acts on unsafely could bypass it; a separate or ensembled judge would close that gap.","A testable prediction follows: models whose tool-use training did not pair schema formatting with action-taking should show a smaller Schema Direction; if they don't, the proposed 'execution cue' mechanism would need revision.","Flattening may drop safety-relevant constraints encoded in schema fields; the reported capability retention on two benchmarks is promising, but broader tool suites should verify no constraint loss."],"forward_implications":["Agent safety can be improved without retraining or activation access; the safeguard only changes what the safety check sees.","The underlying model's native refusal is recoverable, so agent safety degradation is reversible rather than a fixed property of the model.","Tool-description format becomes a safety-relevant design variable; switching from schema to flat text in the safety path can move refusal rates by tens of percentage points.","Safety judgment and tool execution can be decoupled without modifying the agent's tool-use interface, making the approach usable with black-box LLMs.","Benchmark comparisons of agent safeguards should control for description format, since format alone can explain large safety differences."],"fun_headline_variants":["Tool format, not tool content, breaks agent safety","Plain-text tool specs raise refusals from 24% to 71%","Schema specs weaken refusal; plain text restores it","Why agents fail safety: it's tool spec format, not the tool","Rewrite tool specs as text to cut agent attack success 10x"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The mechanism story assumes that flattening schema-formatted tool specifications into plain text preserves every safety-relevant detail, so the measured safety gains come from restoring native refusal rather than from confusing the model or changing how the task is framed.","fun_headline_variants_meta":{"raw":{"variants":["Tool format, not tool content, breaks agent safety","Plain-text tool specs raise refusals from 24% to 71%","Schema specs weaken refusal; plain text restores it","Why agents fail safety: it's tool spec format, not the tool","Rewrite tool specs as text to cut agent attack success 10x"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000301,"raw_usage":{"total_tokens":1562,"prompt_tokens":723,"completion_tokens":839,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":467,"completion_tokens_details":{"reasoning_tokens":750}},"tokens_in":467,"tokens_out":839,"duration_ms":8303,"temperature":1.0,"reasoning_tokens":750,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T10:43:02.483489+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Have an independent judge verify that each flattened tool specification is semantically equivalent to its schema version, then re-run SafeKeep only on pairs where equivalence strictly holds. If the refusal improvement disappears on that verified subset, the effect is information loss from flattening rather than recovery of the refusal representation.","supporting_citations":[],"review_version":1}