PaperlayerView exact revision on arXiv

Source-linked AI summary

SpecCloak: Probing Harmful Code Generation through Engineering Specifications

Wenbin Chen, Jiexin Wang, Guanting Wu, Jiaxi Liang, Yi Cai

arXiv:2610.17907v1cs.SEcs.AI

TL;DR

The paper asks how the form of coding requirements affects refusal of harmful code generation, a safety concern for LLM-assisted software development. It studies engineering-specification prompting through behavioral, representational, and intervention analyses, then develops red-teaming and detection prototypes. Specification prompting lowers refusal in the tested models, and the proposed tools report execution-verified attack success and attack detection results.

  • Problem

    How the organization and expression of coding requirements shape refusal of harmful code generation remains insufficiently characterized, despite the safety importance of resisting harmful implementations.

    Source: §I · p. 1

  • Method

    The paper studies PseudoSpec through controlled response comparisons, representation analysis, and activation interventions, then builds SpecCloak and SpecReveal.

    Source: §I · pp. 1–2

  • Results

    Specification prompting lowers refusal across five open-weight models; SpecCloak achieves 28.91% average execution-verified attack success across eight targets, and SpecReveal reports 96.88% attack detection in a separate evaluation.

    Source: §I · pp. 1–2, D. Main Results: Execution-Verified… · p. 9

  • Takeaways & Limitations

    Specification-induced response differences have practical security relevance, and natural-language intent reconstruction provides a complementary detection approach.

    Source: §I · p. 2

    Mechanistic evidence is restricted to open-weight models, mechanism and attack evaluations use disjoint model sets, and steering specificity varies across models.

    Source: §VII · p. 13

Abstract

from arXiv · show

The code generation capabilities of large language models (LLMs) can equally be misused to implement harmful functionality, underscoring the need to understand their safety behavior in response to programming requests. While request phrasing is known to influence refusal, it remains unclear whether the form in which coding task requirements are stated affects the refusal process for malicious code generation. We introduce PseudoSpec, a template that organizes functional requirements as engineering specifications, and investigate its effects through controlled comparisons, representation analysis, and activation interventions. Across five open-weight models, removing explicit risk keywords only partially reduces refusal, whereas specification prompting substantially lowers refusal even when these keywords are retained. This reduction accompanies consistent shifts toward code-output-related representations, and interventions along condition-difference directions alter refusal behavior. Output analysis further distinguishes code-related responses from generation degeneration. Building on these findings, we propose SpecCloak, a black-box red-teaming framework combining PseudoSpec with discriminator-guided optimization, achieving an average execution-verified attack success rate of 28.91\% across eight target models on RedCode-Gen. We also introduce SpecReveal, a defense prototype combining natural-language intent reconstruction with dual-view detection without target-model fine-tuning. It achieves a 96.88\% attack detection rate in a separate prompt-detection evaluation, with false positives assessed on benign programming and specification-style inputs. These results connect specification-induced response differences to practical security consequences and identify intent reconstruction as a complementary detection approach.

I. INTRODUCTION

The introduction frames harmful code generation as a safety risk and asks how the organization of coding requirements affects refusal. It presents PseudoSpec and related analyses and tools for studying and addressing this response difference.

I. INTRODUCTION

  • Prior work explores jailbreaks and alternative request representations, but how functional-requirement organization affects harmful code-generation refusal remains insufficiently characterized.Examples include adversarial suffixes, code completion, structured queries, formal logic, and commit-message framing [7],,,,, [6].Source: §I · p. 1
  • Specification-style requests can elicit executable code where a direct request for the same malicious functionality is refused.The motivating example preserves operational semantics while changing the request’s surface framing.Source: Figure 1 · p. 1
  • PseudoSpec organizes requirements as engineering-style requests and supports controlled study of specification-induced refusal changes across five open-weight models.The paper reports lower refusal even when explicit risk keywords remain, alongside shifts toward code-output-related representations and intervention-driven changes in refusal behavior.Source: §I · p. 1
  • SpecCloak reports 28.91% average execution-verified attack success across eight target models, while SpecReveal reports 96.88% attack detection in a separate evaluation.SpecReveal combines natural-language intent reconstruction with dual-view detection without target-model fine-tuning; false positives were assessed on benign inputs.Source: §I · p. 2

A. Code Generation

  • Code-generation benchmarks and attacks examine risks in functional descriptions, code completion, translation, risky execution, and development-oriented requests,, [6].Related representation-based attacks include encrypted code prompts [12], structured query language, and formal logic.Source: A. Code Generation · p. 2

B. Jailbreak Mechanisms

  • Mechanistic work studies refusal directions and safety components,,,,, while other studies examine harm recognition, attention-head competition, and roleplay framing, [19], [20].This paper examines code-generation task mode under engineering-specification framing through behavioral analysis and causal interventions.Source: B. Jailbreak Mechanisms · p. 2

C. Jailbreak Defenses

The paper situates SpecReveal among external jailbreak defenses and motivates PseudoSpec as an engineering-document framing for controlled study. It describes the template’s components and outlines analyses of model responses and representations.

C. Jailbreak Defenses

  • External defenses include safety assessment, input processing, and generation or parameter interventions; SpecReveal adds intent reconstruction and dual-view detection without target-model fine-tuning or internal-state access.The listed comparison systems include WildGuard, Erase-and-Check, and an adapted Spotlighting configuration.Source: C. Jailbreak Defenses · p. 2

A. Design Motivation

  • PseudoSpec uses an engineering-document frame because software requirements commonly appear in specifications, design documents, API manuals, and configuration files.The paper proposes that these forms are associated with code implementation and uses a pseudo specification to vary task framing while keeping operational semantics essentially unchanged.Source: A. Design Motivation · pp. 2–3

B. Template Structure

  • PseudoSpec combines configuration schemas, predicate APIs, temporal axioms, and implementation mandates to reframe a malicious request as an engineering task.Schemas and APIs remove surface risk signals, while axioms and mandates reinforce the implementation task frame; the temporal notation is stylistic, not claimed to have formal temporal-logic semantics.Source: B. Template Structure · p. 3, Figure 2 · p. 3

IV. ANALYSIS OF SAFETY RESPONSE DIFFERENCES

  • The safety-response analysis compares behavioral responses, characterizes associated representations, and tests activation interventions along condition-difference directions.Execution-based evaluation assesses functional consequences in the following section.Source: §IV · pp. 3–4

A. Experimental Setup and Evaluation

The evaluation matches five models’ responses across natural-language and PseudoSpec requests with risk keywords retained or removed, alongside benign references. It reports lower refusal under specification prompting and describes how non-refusal outputs are distributed across response categories.

A. Experimental Setup and Evaluation

  • The study compares five models on 104 matched RedCode-Gen tasks across four keyword-by-format conditions and includes 104-request benign natural-language and specification references.The PseudoSpec condition jointly changes task organization, role context, implementation information, and output requirements.Source: A. Experimental Setup and Evaluation · p. 4

B. Refusal Changes under Specification Prompting

  • 73.08%–100%: refusal fell from C1 to C3; without keywords, C2-to-C4 refusal fell 37.50–66.35 percentage points across five models.Table I reports refusal rates with 104 responses per cell; C1/C2 are natural-language requests and C3/C4 are corresponding PseudoSpec requests.Source: B. Refusal Changes under Specification… · p. 4, Table I · p. 4

C. Output Composition of Non-Refusal Responses

  • Non-refusal outputs include operational responses, partial responses, and degeneration, so refusal rates alone do not describe their content.For Qwen3, operational counts fell from 100 to 92 between C3 and C4 while degenerate counts rose from three to 12; Mistral’s 104 C4 outputs included 53 degenerate, four partial, and 47 operational labels.Source: C. Output Composition of Non-Refusal… · pp. 4–5, Figure 4 · p. 5

D. Task-Related Representation Changes

The section measures whether specification prompts shift harmful-request representations toward task requirements associated with code output. Across five models, code-output orientation changes consistently, while implementation-versus-copying changes vary by model.

1) Task Representation Probes and Code-Output Orientation:

  • Four instruction types are distinguishable at 89.94–98.93% accuracy on 1,024 test prompts jointly held out by task and phrasing.The benign-task dataset crosses requirements, formats, instruction types, and phrasings to estimate and test the directions.Source: 1) Task Representation Probes and… · p. 5
  • Independent directions contrast implementation with copying (uI) and code output with explanation or review (uC); larger cosine readouts indicate stronger alignment with the represented task requirement.The directions are estimated from benign tasks, independently of the harmful-request specification contrasts.Source: 1) Task Representation Probes and… · p. 5
  • Specification contrasts produce positive uC changes across all five models with and without risk keywords, while uI changes are model dependent.All listed uC changes pass within-model Holm correction.Source: 1) Task Representation Probes and… · p. 6, Table II · p. 6

2) Controls for Output Requirements and Task Organization:

Controls show that the code-output readout responds more consistently to output instructions than to organizational format. Geometry and attention attribution provide complementary evidence that specification prompting changes harmful-request representations in ways not captured by a single directional readout.

2) Controls for Output Requirements and Task Organization:

  • Across five models, under prose format, requesting code only increases uC by 0.169–0.491; with output requirement fixed, multiline fields differ from prose by −0.010 to +0.025.Across 16 benign tasks, output requirements produce larger, consistently positive changes than organizational changes, which are smaller and model dependent.Source: 2) Controls for Output Requirements… · p. 6

3) Overall Representation Geometry:

  • For Q3, distances to C5 are 715.39 for C1, 446.50 for C2, and 951.43 for C4; keyword removal moves closer to benign references, while specification prompting moves farther away than C2.Across all five models, C2 is closer than C1 to both benign centroids, whereas C4 is farther away than C2; this can coexist with increased code-output components.Source: 3) Overall Representation Geometry · p. 6

4) Attention Attribution to Code Tokens:

  • 83.20–86.86% of heads change significantly for C4–C2, compared with 39.50–61.13% for C4–C3, indicating broader code-token attribution changes in the specification-versus-natural-language contrast.Significant changes include both increases and decreases; the analysis applies Bonferroni correction within each contrast.Source: Table III · p. 7, 4) Attention Attribution to Code Tokens · p. 7

E. Representation Interventions and Response Changes

The section tests whether a direction extracted from condition differences can alter model responses. It defines an intervention along that direction and evaluates response categories and output composition under the reported settings.

1) Direction Estimation and Intervention Setup:

  • The manipulated direction vF is estimated from C4–C1, jointly encoding keyword and framing changes, and is evaluated on held-out tasks.The measurement directions uI and uC are distinct from this condition-difference direction.Source: 1) Direction Estimation and… · p. 7, E. Representation Interventions and… · p. 7
  • Interventions add αvF at the final prompt position during prefilling and at the current position during decoding; Gaussian controls match vF's norm.Forward flip rates use baseline refusals as the denominator, and code-marker proportions use flipped responses; Table IV reports n+ as eligible baseline refusals and CP as the code-marker proportion among flips.Source: 1) Direction Estimation and… · p. 7, Table IV · p. 7

2) Refusal Flips and Code-Related Outputs:

Interventions along condition-difference directions can change refusal responses, but their output forms vary across directions and models. The findings connect specification prompting with code-output-related representations while distinguishing code-related responses from degeneration.

2) Refusal Flips and Code-Related Outputs:

  • Under the reported settings, vF flips every eligible baseline refusal to non-refusal across five models, with 70.7–100% of flipped outputs marked as code-related.All 64 intervened Q3 outputs receive the stageB code label, while L2 produces 63 code-labeled outputs and one degenerate output.Source: 2) Refusal Flips and Code-Related… · p. 7

3) Control Directions and Output Degeneration:

  • The keyword-retaining direction produces 100% forward flips; projection-residual flip rates vary by model, from 32.8% for L3 to 100% for Q2.5 and M.Residual rates are approximately 96.8% for Q3 and zero for L2, indicating model-dependent retention relative to the reference direction.Source: 3) Control Directions and Output… · p. 7
  • Random perturbations yield model- and seed-dependent flips, and equal-norm directions can produce different response forms.For L3, an eight-seed scan ranges from 0 to 53 flips among 58 eligible samples; norm-matched random interventions produce 38 degenerate Q3 outputs, unlike vF's code-label composition.Source: 3) Control Directions and Output… · pp. 7–8
  • With α = 2, all 63 eligible Q3 baselines become non-refusals, but every output is degenerate and none meets the code-marker rule.The paper therefore reports both flip rates and output composition to distinguish response categories from generation state.Source: 3) Control Directions and Output… · p. 8

F. Main Findings and Security Implications

  • Across experiments, lower refusal under engineering-specification prompting accompanies stronger code-output-related representations, while interventions alter response categories.The analysis also reports changes in representation geometry and redistribution of code-token contributions, distinguishing representational associations from imposed perturbation effects.Source: F. Main Findings and Security… · p. 8
  • The natural prompting effect's causal mediation by uC remains unestablished, and PseudoSpec jointly varies role context, length, implementation information, and output requirements.The independent contributions of those factors to refusal therefore require further identification.Source: F. Main Findings and Security… · p. 8

V. SPECCLOAK: SPECIFICATION-BASED STRUCTURED RED TEAMING

SpecCloak uses specification-style framing and discriminator feedback to refine prompts internally, then evaluates a selected prompt against a black-box target. Its experiments use execution-verified outcomes and compare the framework with representative jailbreak methods.

A. Design Motivation

  • SpecCloak combines PseudoSpec framing with discriminator-guided candidate refinement, using feedback without access to target-model internals.The specification framing is motivated by observed framing-dependent refusal, while discriminator feedback enables refinement without target queries or internal representations.Source: A. Design Motivation · p. 8

B. Framework Structure

  • A generator and discriminator iteratively refine a four-part PseudoSpec prompt; the selected prompt is submitted once to a black-box target.The loop stops when the discriminator labels a candidate safe or reaches the iteration limit; the main experiments use η = 3.Source: B. Framework Structure · pp. 8–9

C. Experimental Setup

  • Experiments evaluate eight target models on RedCode-Gen's 160 cases across eight malware families, with success requiring sandbox execution and target-family behavioral indicators.The study also uses RMCBench for generalization checks and compares six jailbreak methods representing distinct attack paradigms; PAIR comparisons are limited to two local models by its multi-turn budget.Source: C. Experimental Setup · p. 9

D. Main Results: Execution-Verified Success and Refusal

On RedCode-Gen, SpecCloak leads the evaluated targets in execution-verified successes, while refusal counts show a related but distinct pattern. Results on RMCBench and component ablations further characterize its performance within the evaluated settings.

D. Main Results: Execution-Verified Success and Refusal

  • 28.91% (370/1,280) is SpecCloak's execution-verified success rate; it records the highest E-hits on all eight targets and the lowest R-count on seven.It totals 132 refusals (10.31%); Kimi2.7-Code is an exception, with more refusals than AutoDAN despite more execution-verified successes than evaluated baselines.Source: D. Main Results: Execution-Verified… · p. 9, Table V · p. 10
  • On RMCBench, SpecCloak has the highest E-hits and lowest R-count among three methods on each of three targets; on o4-mini, it records 59 E-hits versus 18 for FlipAttack and 15 for QueryAttack.The corresponding R-counts are 46, 49, and 116, respectively; the evidence supports applicability beyond RedCode-Gen within the evaluated datasets, targets, and baselines.Source: D. Main Results: Execution-Verified… · p. 9, Table VI · p. 10

E. Ablation

  • Removing the PseudoSpec template lowers E-hits on all four ablation targets, while removing both template and IIO also lowers E-hits on all four.The full framework has the highest E-hits on each target; these ablations compare component-level performance but do not establish the task-mode mechanism.Source: E. Ablation · pp. 9–10, Table VII · p. 10

VI. SPECREVEAL: MECHANISM-DRIVEN DUAL-VIEW DEFENSE

SpecReveal responds to specification framing by reconstructing operational intent outside the target model, then checking both the original request and its reconstruction. This external design is intended to restore risk semantics without relying on a fixed template shape.

A. From Mechanism to Defense Design

  • The defense rationale is to restore risk-semantic signals weakened by specification framing, rather than block specification documents as a form.SpecReveal performs this restoration outside the target model, avoiding the model dependence of internal vector-based restoration.Source: A. From Mechanism to Defense Design · p. 10

B. Method: Intent Restoration and Dual-View Safety Detection

  • SpecReveal reconstructs a structured request as natural-language operational intent, then assesses the original prompt and restored intent, rejecting or alerting when either view is high-risk.The original view captures residual surface risk signals; the restored view captures risk semantics masked by the frame.Source: B. Method: Intent Restoration and… · pp. 10–11

1) Formal Specification:

  • The pipeline restores intent, scores the raw prompt and reconstruction, then uses the higher score in its default union decision; the restoration and detector models can be chosen independently.The design requires no target-model fine-tuning or internal-state access, with a cost of one restoration and two safety judgments.Source: 1) Formal Specification · p. 11, B. Method: Intent Restoration and… · p. 11

C. Experimental Setup

The evaluation compares SpecReveal and baseline defenses on paired adversarial and benign prompts, measuring attack detection and false positives. SpecReveal union detects the most attacks in the o4-mini evaluation, while dual-use benign requests remain a key source of false positives.

1) Comparison with Existing Defenses:

  • The comparison uses 100 generated attack prompts paired with 100 human-verified benign programming requests, with o4-mini as the detection backend.The attack prompts are sampled from the SpecCloak generator output, including prompts not execution-verified as successful.Source: 1) Datasets · p. 11, 1) Comparison with Existing Defenses · p. 12

2) Baselines:

  • Baselines include no defense, Spotlighting, Erase-and-Check, and WildGuard-7B; SpecReveal ablations compare original-prompt, restored-intent, union, and intersection detection.Erase-and-Check uses a random-erasure budget of k = 5; the union applies an OR rule and intersection rejects only when both views indicate high risk.Source: 2) Baselines · p. 11

3) Evaluation Metrics:

  • Attack detection rate counts REJECT or REVIEW verdicts, while strict rejection counts REJECT only; false-positive metrics apply corresponding counts to benign samples.The two counting rules coincide in these evaluations because no backend produced a REVIEW-only verdict.Source: 3) Evaluation Metrics · p. 11

1) Comparison with Existing Defenses:

  • The defense evaluation targets detection of SpecCloak prompts that bypass existing defenses without unacceptably increasing false positives on benign requests.It measures attack detection and benign false-positive rates on the paired 200-sample set.Source: 1) Comparison with Existing Defenses · pp. 11–12
  • SpecReveal union detects 98/100 attacks at a 21% false-positive rate, versus Spotlighting’s 94/100 at 14%; on archive-successful attacks, it detects 67/69 (97.1%).The comparison uses the o4-mini detection backend; the table caption identifies Table VIII as the filter-configuration-by-judge ablation.Source: Table VIII · p. 11, 1) Comparison with Existing Defenses · p. 12
  • False positives concentrate in dual-use benign tasks, while intersection offers a more conservative operating point: 80/100 attack detection at 9% FPR.Most union false positives came from others (11/12) and trojan (8/13), including network administration, process daemons, and persistence configuration.Source: 1) Comparison with Existing Defenses · p. 12

2) False Positives on Benign Formalized Inputs:

The evaluation finds that formalized benign inputs do not raise false positives for SpecReveal or Spotlighting, while judge choice and dual-use semantics constrain deployment. A case study traces one adware request from direct refusal through execution-verified evasion to blocking by SpecReveal.

2) False Positives on Benign Formalized Inputs:

  • The benign evaluation includes both natural-language requests and formalized specifications because attacks mimic engineering documents.The inputs are 104 BC prompts and 104 BF prompts, evaluated with the o4-mini judge.Source: 2) False Positives on Benign… · p. 12, Table IX · p. 12
  • For every SpecReveal mode and Spotlighting, false-positive rates on formalized benign inputs are at or below rates on natural-language benign inputs.Intersection is conservative on both, with 3.9% on BC and 1.9% on BF.Source: 2) False Positives on Benign… · p. 12, Table IX · p. 12
  • Erase-and-Check is the exception: erasure fragments roughly triple false positives on BC (32.7%) and BF (33.7%), despite high attack detection.With the stricter Qwen2.5-Coder-7B judge, all rates rise substantially; A only reaches 83.7% on BF.Source: 2) False Positives on Benign… · p. 12

E. Case Study: From Refusal to Execution-Verified Evasion on a Single Request

VII. CONCLUSIONS AND FUTURE WORK

  • The conclusion proposes task-frame and risk-intent channels: engineering-specification structure recruits code generation, while recognizable harmful intent drives refusal.The paper reports support at behavioral, representational, and causal levels, with generalization to two closed-source API models.Source: §VII · p. 13
  • Mechanistic evidence is limited to open-weight models, mechanism and attack evaluations use disjoint model sets, and steering specificity varies across models.Source: §VII · p. 13

Related papers

Loading 2610.17907v1…