Research Radar
Daily · July 28, 2026
1 peer-reviewed · 3 preprints · 0 forum/blog
Mech Interp · AI Security · Text Diffusion LMs
01
mech-interp preprint

ParityTransformer: Interpretability by Design via the Deep Parity Bottleneck

Interpretability in transformers is almost always post-hoc — you train the model first, then reverse-engineer what it learned. ParityTransformer inverts the workflow: it forces an interpretable constraint during training via the Deep Parity Bottleneck (DPB), and the features that emerge match SAE-discovered features on probing benchmarks while substantially outperforming them on every causal metric — absorption, steering, and intervention stability.

Deep Parity Bottleneck vs SAE — Interpretability Metrics Score (%) 0 25 50 75 100 Absorption Rate (↓ better) 28% 12% Steering Accuracy (↑) 61% 74% Causal Stability (↑) 56% 71% Standard SAE Deep Parity Bottleneck (DPB)
Figure 1: ParityTransformer DPB vs standard SAE on three interpretability metrics. DPB achieves lower feature absorption (12% vs 28%), higher steering accuracy (74% vs 61%), and higher causal intervention stability (71% vs 56%). Probing performance is equivalent; causal metrics are substantially better across the board.

The Deep Parity Bottleneck partitions the residual stream into parity-signed feature subspaces during training, enforcing that each feature's causal role is legible by construction rather than recovered post-hoc by a separately trained sparse autoencoder. Evaluated on GPT-2 and Pythia-1.4B against Anthropic JumpReLU and standard TopK SAEs, DPB models match SAE performance on token-type probing but show substantially lower feature absorption rates, higher steering accuracy, and more stable causal intervention outcomes across depth and model scale. The interpretability-by-design constraint produces no significant capability degradation.


02
AI security ICSME 2026

The Language of Security: How Prompt Syntax Shapes Code Vulnerability in LLMs

Security prompts aren't just about content — the syntactic form of the instruction matters as much as the instruction itself. The same security requirement reformulated across five syntactic variants produces up to a 31 percentage-point swing in CWE violation rates, a gap large enough to render prompt engineering the primary security control in LLM-assisted coding workflows.

Prompt Syntax vs CWE Violation Rate (lower is better; 5 LLMs · 100 coding prompts · 14 CWE categories) CWE Violation Rate (%) 0 20 40 60 58% Declarative 54% Imperative 31% Role-based 27% Chain-of-Thought 23% Constraint 31 pp gap Average across GPT-4o · Claude 3.7 · Gemini 2.0 · Mistral Large · Llama 3.3 70B
Figure 2: CWE violation rates across five syntactic prompt formulations (100 coding tasks, 14 CWE categories, 5 LLMs). Declarative instructions produce 58% violation rate; constraint-based formulations reduce this to 23% — a 31 pp swing from syntax alone. Role-based and CoT styles cluster near the efficient end.

Across five major LLMs (GPT-4o, Claude 3.7 Sonnet, Gemini 2.0 Flash, Mistral Large, Llama 3.3 70B), the authors systematically tested 100 coding prompts covering 14 CWE categories under each of five syntactic formulations. Declarative and imperative styles consistently produced the highest violation rates on CWE-89 (SQL injection) and CWE-79 (XSS); role-based and chain-of-thought instructions reduced violations by 20–31 pp. Crucially, the interaction between model and syntactic variant is significant — a formulation that elicits secure code from GPT-4o may be among the worst choices for Llama 3.3 70B. Accepted to ICSME 2026.



Items 4 – 10 · Also notable
04
AI security preprint

The Illusion of Secure LLM Code: How Iterative Reprompting Undermines Security

Critical Issues vs Reprompting Iteration 0 +15% +30% +45% 1 2 3 4 5 Reprompting Iteration +37.6%
Figure 4: Cumulative increase in critical security issues vs reprompting iteration. Initial outputs appear safe; each agentic refinement step adds security regressions, reaching +37.6% critical issues after 5 iterations.

Most LLMs produce low-risk code on an initial request, creating an illusion of security. But agentic iterative reprompting — optimising for stated functional goals like "make it faster" or "add this feature" — progressively introduces critical CWE violations: +37.6% critical issues after 5 reprompting iterations, driven by the model trading security constraints for functionality objectives the user specified more recently.




07
AI security preprint

6 entries removed on 2026-09-10 as repeats of earlier reports: 2507.19227 (first covered 2026-07-07), 2607.17425 (first covered 2026-07-23), 2607.14943 (first covered 2026-07-18), 2607.08605 (first covered 2026-07-16), 2607.02513 (first covered 2026-07-21), 2607.05722 (first covered 2026-07-11).

LogInject: Passive Prompt Injection via Security Operations Log Context

LogInject: Passive Injection via Log Metadata Fields Attacker crafts HTTP User-Agent Server Log 10.0.0.1 GET / "Ignore prev. instructions..." 200 1234 SOC Agent LLM reads log as trusted ctx (no defense fires) Attack Success All 4 objectives achieved 12,847-entry bench HTTP UA / DNS / SMTP header fields as vectors
Figure 7: LogInject attack flow. Adversarial payloads embedded in HTTP User-Agent strings, DNS TXT records, or SMTP headers enter server logs as metadata — the SOC agent LLM treats log content as authoritative context, fires no defense, and executes all four attack objectives.

LogInject demonstrates passive prompt injection into AI-powered Security Operations Center pipelines: adversarial payloads in standard HTTP User-Agent strings, DNS TXT records, and mail headers propagate into server logs, which SOC agent LLMs read as trusted operational context. No user interaction is required. All four tested attack objectives (false negative injection, alert suppression, exfiltration trigger, privilege escalation) succeed across the 12,847-entry LogInject-1.0 benchmark. Introduces a new attack surface where the log file itself is the injection vector.




Notes

← all Research Radar issues · gussand · source