Papers for

software security teams

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Tracekit secures autonomous coding agents by detecting tampering

Tracekit: Tamper-Evident Intent-Reasoning-Action Auditing for Autonomous Coding Agents

Abstract: Autonomous coding agents read untrusted files, run shell commands and spawn sub-agents with little supervision, yet their record is usually an editable log. We present Tracekit, an open-source, dependency-free system that captures three channels for every agent session: what the human asked (intent), what the model said of its reasoning (self-report), and what it actually executed (actions). These are written to a hash-chained, externally anchorable ledger and cross-checked. Tracekit hooks into Claude Code's lifecycle events, reconstructs multi-agent hierarchies, gates tool calls with a pre-execution policy, accepts events from other agents via an SDK or HTTP API, and renders a live observer that re-verifies the ledger in the browser. We evaluate Tracekit in five experiments. (1) Across 1,600 random mutations, the chain detects every edit, deletion, reordering, forged insertion and torn write; tail truncation and full re-chaining are caught only by anchors, with detection falling to 0.47 at an anchoring interval of 300 records, matching a closed-form model. (2) A hook costs 23.9 ms median, flat up to 100,000 ledger records, and the chain stays correct under 16 concurrent writers. (3) A regular-expression gate blocks only 18 of 44 harmful tool calls (41%) while wrongly blocking 3 of 40 benign ones; trivial rewrites evade it. (4) In 14 real Claude Code runs, the agent never acted on four planted indirect prompt injections and disclosed each. The provider withheld the text of all 27 thinking blocks, so self-report was limited to visible prose. (5) With seeded-fault splicing, a new method that inserts concealed misaligned steps into real traces, over 63 traces and 126 reviewer calls, rule flags caught 40/49 (82%) of faulted traces and an independent LLM reviewer caught 98/98 (100%), with a false-positive rate of 1/14 on unmodified traces. We release the system, harness and all traces.

Mon 28 SeptComputational Engineering, Finance, and ScienceCryptography and Security
The gist
Autonomous coding agents do complex work but their activity logs can be changed, making it hard to trust what they did. The authors present Tracekit, a system that records what the user wants, what the agent thinks, and what it actually executes, all linked securely to prevent tampering. The system finds edits and fakes in these records and helps spot suspicious alterations. It works with multi-agent setups and shows good detection in tests. Tracekit is open source for others to build on.
Open → 2609.35659v1

ProofWeave improves real-time trust evidence for AI actions

Poster: Towards ProofWeave: A Privacy-Minimised, Integrity-Anchored Evidence Plane for Continuous Agentic Assurance

Abstract: Agentic AI systems increasingly act via tools, memory, delegation, and external services. Existing observability and provenance mechanisms can reconstruct events post hoc, but they rarely show, at the time of the record, whether each policy-relevant action was checked by the intended control before execution. This leaves a trust-observability gap for continuous monitoring, detection, and response: later assurance may rest on evidence that is incomplete, privacy-leaking, mutable, or detached from the policy context that governed the event. What's missing in the literature is contemporaneous, policy-bound evidence that the intended control was evaluated under the policy in force at the time. We introduce ProofWeave, a record-time chain-of-evidence concept for agentic AI assurance. At each policy-relevant action boundary, ProofWeave generates a privacy-minimised and integrity-anchored evidence transaction that binds (i) agent intent or action, (ii) control response, and (iii) a policy-at-time snapshot. Each transaction is committed to an append-only ledger and materialised into a derived proof graph. A bounded Weaver Agent translates policy intent into proof obligations, while deterministic validators check evidence completeness, privacy minimisation, policy binding, and integrity. In the minimal scenario, an agent attempts to transmit a secret to an unapproved external sink. The audit compares a logs-only correlation baseline with ProofWeave across verdict latency, join ambiguity, privacy exposure, tamper detection, and resistance to graph-only proof injection. ProofWeave reduces candidate bindings per verdict from up to `10,201` to one, validation operations from up to `10,201` to approximately `26`, and assurance evidence storage from `0.79`MiB to `0.15`MiB per project.

Mon 28 SeptCryptography and Security
The gist
Keeping track of what AI systems do is tricky because existing tools only show what happened after the fact, and they might miss whether proper checks were made before an action. The authors introduce ProofWeave, a way to record real-time proof that each AI decision was properly controlled according to current rules, while protecting privacy. This system links the AI’s intent, the controls’ response, and the rule set they used at that moment, storing this in a secure, easy-to-check form. Their tests show it reduces confusion, speeds up verification, and saves storage compared to just relying on logs.
Open → 2609.35234v1

LLM coding agents measured for security issues along code progress

Trajectory-Level Security Debt in LLM Coding Agents

Abstract: LLM coding agents can traverse hundreds of intermediate code states before submitting a solution. Evaluating only the final artifact leaves the evolution of security findings unmeasured. We introduce the Security Debt Line Integral (SDLI), which accumulates static-analysis risk when an agent reaches a new best test pass ratio. We instantiate it with four static application security testing (SAST) tools and study artifacts from 830 passing SWE-bench runs, 712 ProgramBench final workspaces, and 13 public MirrorCode trajectories. The two large populations use the final-state special case of SDLI. Two-tool Common Weakness Enumeration (CWE) class agreement occurs in 3.9% of SWE-bench runs and 26.2% of the 80 ProgramBench runs passing at least 90% of official tests. These are scanner findings, not validated vulnerability rates. Excluding three advisory-heavy classes reduces the latter rate to 6.2%. Same-task runs differ in their measured scores, while one reconstructed ProgramBench run exposes persistent findings from its first implementation write. A repair case study reduces the scanner signal while preserving tested behavior, but also reveals sensitivity to equivalent API rewrites. SDLI offers a way to study progress and security findings together. Its value for steering agents and confirming exploitable vulnerabilities remains to be established.

Mon 28 SeptCryptography and SecuritySoftware Engineering
The gist
Software tools powered by large language models (LLMs) often create many versions of code before settling on a final answer. The authors found that just checking the finished code misses security risks that appeared and changed along the way. They propose a new way to track and add up potential security problems throughout these coding steps instead of only at the end. This measure, called the Security Debt Line Integral, helps understand how security issues develop as code improves but still needs testing for guiding fixes or confirming real dangers.
Open → 2609.35199v1

LLM agents often fail to protect private information across communities

CoSec: Benchmarking Agent Security in Communities

Abstract: LLM agents operate in persistent collaborative environments involving multiple users, communities, memories, files, and tools. Community boundaries may remain fixed or evolve with changes in membership, roles, composition, and relationships. Agents must complete legitimate tasks and prevent unauthorized disclosure of protected information. Existing evaluations do not fully examine these risks in agent systems. We introduce \textbf{CoSec}, an executable benchmark for evaluating privacy and authorization enforcement in LLM agent systems operating within and across communities. CoSec contains 208 canonical scenarios spanning fixed and evolving boundaries, protected information belonging to the agent owner or other participants, and attacks through dialogue, environmental content, persistent memory, and composed workflows. CoSec executes complete agent systems with persistent sessions, memory, files and tools. It verifies information flows against the active authorization state using execution traces and artifacts. Across harness and model configurations, agents frequently complete benign tasks but violate privacy and authorization boundaries. Privacy behavior varies across harnesses, attack surfaces, and community states, revealing how memory, files, tools, and workflows can carry protected information beyond its authorized scope. These findings show that task utility does not imply privacy or authorization compliance and that authorization in community settings remains an unresolved security challenge for persistent LLM agents.

Mon 28 SeptCryptography and SecurityArtificial Intelligence
The gist
Large language model (LLM) agents work together in groups that can change over time and involve shared information like files and memories. The paper introduces CoSec, a test system that checks how well these agents keep private information secure and follow rules about who can see what. The authors found that while agents usually complete their tasks, they frequently expose private data or break authorization rules. This shows that being useful doesn't mean they are safe, and securing these agents in shared settings is still a big challenge.
Open → 2609.34790v1

SecProbe method improves testing for coding agents’ cybersecurity skills

SecProbe: Adaptive Evaluation of Coding Agents on Cybersecurity Vulnerabilities

Abstract: Assessing cybersecurity vulnerability awareness in coding agents requires evaluations that reveal capability gaps and remain informative as models evolve. Static benchmarks offer fixed coverage and difficulty, while scarce vulnerable repositories and costly expert authoring limit their renewal at scale. We introduce SecProbe, a framework for adaptive evaluation that combines Item Response Theory (IRT) with on-demand synthesis of repository-scale vulnerability-repair tasks. From observed performance, \textsc{SecProbe} estimates agent ability and identifies where additional evidence is most informative, selecting existing tasks or synthesizing new ones accordingly. As one use case, we construct 353 tasks spanning six programming languages and 151 CWE types and evaluate nine frontier models with two agent harnesses. Success rates peak at 28.33\%, highlighting substantial gaps in vulnerability recognition and repair. Compared with random and one-shot baselines, \textsc{SecProbe} achieves comparable agent ability estimates while requiring agents to solve up to 29.5\% fewer tasks. These results support adaptive evaluation as an efficient and discriminative approach to assessing cybersecurity vulnerability awareness.

Sun 27 SeptCryptography and SecurityArtificial Intelligence
The gist
Checking how well computer programs recognize and fix security problems in code is hard because existing tests are fixed and don’t change as programs get better. The authors created SecProbe, a system that picks or generates coding tasks based on how well an AI is already doing, focusing on areas where more testing is most useful. They tested it with hundreds of tasks and found that current models still struggle to find and fix many security issues. SecProbe uses fewer tasks yet gives a similar understanding of an AI’s ability, making security testing more efficient.
Open → 2609.33763v1

Call graph analysis improved for c programs without type info

Neuro-Symbolic Indirect-Call Analysis under Opaque Pointers

Abstract: Resolving indirect calls is central to call-graph construction for C. Scalable type-based analyses such as MLTA use type information in LLVM IR to associate indirect calls with functions assigned to the corresponding structure fields. However, a single pointee type often misrepresents the memory a pointer addresses, and LLVM 17 removed pointee types in favor of opaque pointers. Therefore, field-sensitive analyses lose their matching key. Recovering the erased types restores the matching key but still misses the relation that the type encoded: which functions the program assigns to the field. We present Facet, to our knowledge the first analysis that reconstructs this dispatch relation over opaque IR. Facet identifies the structure field from which an indirect call loads its function pointer. It separately recovers the functions assigned to that field through initializers, stores, and aggregate copies. It then joins the two by field identity, without requiring an end-to-end value-flow path. Facet classifies proposed call-graph changes under distinct evidence rules for edge addition and removal and records the assumption behind each refinement. An LLM decides only the residual cases among symbolically bounded candidates. One analysis yields both a recall-preserving call graph and a refined call graph. On 14 C programs, Facet reduces the mean target-set size from 25.9 to 5.2 and raises observed recall from 0.79 to 0.99. Its recovered field identities agree with typed IR at 98.1% of jointly resolved sites. Applied to bug detection, the refined call graph found 17 deep bugs in C software from nginx to the Linux kernel, three of them latent for over a decade; 12 are confirmed.

Sun 27 SeptSoftware EngineeringProgramming Languages
The gist
Indirect function calls in C programs are hard to analyze precisely when key type information is missing, as happened with recent changes in LLVM. The authors present Facet, a new technique that recovers important information about which functions are assigned to specific memory fields, even when type details have been erased. Facet does this by identifying and matching structure fields and the functions stored in them without needing full value tracking. This method results in more accurate call graphs that greatly reduce confusion about which functions might be called, improving bug detection in real-world software.
Open → 2609.33547v1

On-policy distillation students leak membership of teacher training data

Leaky Students: Membership Inference against On-Policy Distillation

Abstract: On-policy distillation (OPD) trains a student to match a teacher's next-token distributions on student-generated trajectories. However, privileged information supplied to the teacher for OPD training may contain sensitive data. Whether the student leaks private information about the records supplied to the teacher during distillation remains poorly understood. To the best of our knowledge, we present the first systematic study of membership inference in this setting. We find that fresh student trajectories expose sparse membership signals that fixed reference-answer losses often miss. These signals are mixed with probability changes caused by training on other records. We introduce Leaky, which samples fresh trajectories from the target model and compares its token log-probabilities with the maximum across matched reference models trained without the candidate records. It applies Leaky ReLU to the resulting gaps, preserving positive gaps and downweighting negative gaps as an approximate correction for incidental positive gaps in non-members. Across fifteen targets spanning mathematics, medical question answering, and code generation, Leaky outperforms all evaluated baselines and achieves mean AUROC 0.875, compared with 0.614 for the strongest baseline on each target in the main evaluation. On the same sampled trajectories, the strongest baseline achieves mean AUROC 0.826. These results show that students trained through OPD can expose the membership of records used for teacher supervision, even when fixed reference-answer losses provide little evidence of membership.

Sun 27 SeptMachine LearningCryptography and Security
The gist
When training a small model (student) to mimic a bigger model (teacher) using examples generated by the student, the small model can unintentionally reveal if specific data was used during training. The authors found that using new examples created by the student exposes these membership leaks better than traditional methods. They created a tool called Leaky that detects these leaks by comparing likelihoods between the target and reference models. Tests across different question types show Leaky detects data membership more accurately than existing methods.
Open → 2609.33136v1

Function level scores measure flag rate more than vulnerability detection quality

A Function-Level Vulnerability Score Measures Flag Rate More Than the Model: Protocol Effects on Paired Benchmarks

Abstract: Language models are increasingly evaluated as vulnerability detectors, and scores reported for similar models differ widely between papers. We measured how much of that difference evaluation protocol accounts for, with model outputs held fixed. In a paired test, a model must flag a vulnerable function and clear its version after a fixing commit. Three choices that published evaluations make differently were varied one at a time: metric, verdict extraction and output budget. Seven frontier and large open models were evaluated on five released pair benchmarks and a set pooled for this work under one protocol, and 61 open models of 1.5B to 36B parameters on the pooled set. Function-level F1 follows how often a model flags both functions of a pair (Spearman $+0.86$ over 42 combinations) and is nearly unrelated to pair-level correctness ($+0.16$). On the pair score, extraction changes a model's number by $+0.001$ at the median and budget by $+0.02$ with an interval through zero, whereas the model changes a benchmark's number by up to 0.18 and the benchmark a model's by up to 0.16; a function-level score therefore measures flag rate more than model. For 37 of 68 models the difference between correct and reversed pairs is within its 95% interval of zero, the value for a null model that flags each function at a fixed rate, while both-flagged and both-cleared rates exceed that null by 0.055 on median, and for 64 of 68 both functions of a pair receive one answer more often than independence predicts: verdicts are determined by the text common to both functions. On length-matched pairs a linear probe on activations separates 0.78 by within-pair ranking, against 0.64 for a tf-idf baseline and 0.5 for length; the generated verdict is near chance for three of six models and at 0.55 to 0.57 for the other three, and a prompted logit is at chance for all six.

Sat 26 SeptMachine Learning
The gist
Detecting software vulnerabilities using AI language models involves checking if the model flags functions as risky and then clears them after fixes. The authors found that the way these models are evaluated affects the reported scores more than actual model differences. They show many scores mostly reflect how often the model flags code rather than how accurately it detects vulnerabilities. Also, judgments about paired code snippets tend to depend on shared text rather than deeper understanding.
Open → 2609.32890v1

Benchmark reveals gap in coding agents finding versus reporting security flaws

VulContextBench: A Benchmark for Security Context Retrieval in Coding Agents

Abstract: Vulnerability-detection benchmarks score the verdict an agent reaches, not the evidence it gathered. A model that recalls a CVE from pretraining therefore scores the same as one that traced the data flow. We study a task where this difference matters, deciding whether a commit introduces a vulnerability. Instead of scoring the verdict, we score whether the agent retrieved the code its conclusion depends on. We present VulContextBench, a benchmark of 111 vulnerability-introducing commits (VICs) across 83 repositories, 63 CWEs, and five languages. Existing datasets label such commits by tracing a fix back through the version history, which often points to the wrong commit. We therefore audit every case by hand against an explicit four-criterion definition of a VIC, so the benchmark does not inherit that label noise. Each case is annotated with gold context, 464 code blocks in total, each tagged by its role in the evidence for the vulnerability. We evaluate seven frontier models with precision, recall and F1 at three granularities (file, block, and line), scored separately on the context an agent viewed while exploring and on the context it finally declared as evidence. The gap between the two is the main finding. Every model opens most of the gold context while exploring, but reports only part of it as evidence. At the level of code blocks, the share of the gold context a model reports is 37 to 73 percentage points below the share it viewed. Qwen3-Coder-Next views 86.3% of the lines in annotated code blocks but cites only 12.9% in its final report. GPT-5.5, which cites the most, views 73% and reports 36%. These results highlight a gap between finding relevant code and selecting it for the final report, which verdict-level benchmarks cannot reveal.

Sat 26 SeptCryptography and Security
The gist
Some computer programs try to find security problems in software changes but only get scored on their final answer, not how they get there. The authors created VulContextBench, a new test set that checks if these programs look at the right parts of code that actually cause the problem. They found that while programs often look at most relevant code, they only mention a small part when explaining their decision. This shows that current tests miss an important step and programs need to get better at explaining the evidence behind their judgments.
Open → 2609.32601v1

Ai safety framework enforces action limits through monitoring roles

Contract monitoring: governing AI via separation of powers

Abstract: We propose an AI safety framework that binds worker agents to contracts specifying their permitted actions. We show how these contracts can be enforced and specified by assigning distinct responsibilities to monitor agents and judges, and asymmetric computational resources to monitors and workers. Our framework allows us to empirically measure statistical safety guarantees. The framework applies to a wide range of settings, including code security and escape-the-box scenarios.

Fri 25 SeptArtificial Intelligence
The gist
AI systems can sometimes do things they shouldn’t, which can cause safety problems. This paper presents a way to keep AI workers in check by giving them contracts that limit what they can do. Special monitors and judges watch over the workers and make sure they follow these contracts using different computing powers. This lets us measure how safe the system is in a clear way, and the approach works in many situations, including software security and keeping AI contained.
Open → 2609.32061v1

AgentXploit improves security testing for AI agent software

AgentXploit: Autonomous Repository-to-Runtime Red-Teaming for AI Agents

Abstract: AI agents combine language models with external data and tools that can modify files, call APIs, or execute code. Security failures can arise when adversarial content changes an agent's tool use or when the surrounding software contains vulnerabilities such as path traversal or command injection. We study authorized white-box pre-deployment auditing, where the auditor has access to the target repository and a controlled runtime, but successful attacks must still act through the task-defined attacker interface and be confirmed by an external verifier. We present AgentXploit, a two-role auditing system that separates repository-level attack-path discovery from runtime exploitation. The Analyzer Agent traces attacker-controlled inputs to sensitive operations and records code-supported candidate attack paths; the Exploiter Agent turns these paths into concrete attacks and revises them using runtime feedback. We also introduce AgentXploit-Bench, containing 72 reproducible vulnerabilities across 12 open-source AI-agent systems and frameworks. Across three runs, AgentXploit reaches 59.3% end-to-end success, compared with 38.4% for Codex. Under a token-budget-matched comparison, Codex reaches 46.3%. On AgentDojo, where injection points are provided, the Exploiter Agent reaches 79.2% attack success versus 52.7% for AgentVigil. These results highlight repository discovery and runtime exploitation as distinct challenges in end-to-end agent security auditing.

Fri 25 SeptCryptography and SecurityArtificial Intelligence
The gist
AI agents use language models that interact with software tools and data, but this can lead to security risks if harmful inputs manipulate the agent's behavior or exploit software flaws. The paper presents AgentXploit, a two-part system that finds how attacks could happen in the code and then tries to carry out those attacks in a safe testing environment before deployment. The authors also provide a benchmark with multiple real-world vulnerabilities in AI agent frameworks to evaluate such attack methods. Their system outperforms previous automated approaches in finding and verifying these security issues. This work helps make AI agents safer by detecting risks early in development.
Open → 2609.31318v1

Blockchain secures AI agents protecting software development processes

Resource-Optimized and Energy-Aware Agentic AI Framework Anchored on Blockchain for Secure Software Supply Chains

Abstract: This paper proposes a blockchain-backed agentic security framework designed to safeguard the complete software development lifecycle (SDLC) while also securing the agentic AI components responsible for monitoring it. The framework coordinates a set of specialised security agents, covering source integrity, dependency and SBOM analysis, CI configura tion auditing, artifact verification, and runtime policy evaluation, each supported by a large language model (LLM) that interprets artefacts, reasons over tool outputs, and produces structured security reports. To ensure agent trustworthiness, every agent generates a cryptographically signed attestation that is recorded in a permissioned blockchain via smart contracts, including an agent registry, an immutable attestation log, and an enforceable release-policy module. Communication among agents and with blockchain nodes is secured using a consortium-operated certificate authority, ensuring authenticated and tamper-resistant interactions. A detailed use-case and sequence flow demonstrate how a source code security agent performs analysis, anchors its attestation on-chain, and triggers a verifiable allow/block deployment decision. The proposed framework of fers decentralised integrity transparent provenance, uninterrupted security assurance and a generalisable architecture to incorporate the agentic AI into the modern software supply chain security.

Fri 25 SeptCryptography and SecurityArtificial Intelligence
The gist
Software development involves many steps that need protection from security problems. The paper by the authors presents a system where special AI agents watch over these steps and produce security reports. These agents use blockchain technology to record trustworthy proof of their checks, making sure their work can’t be faked or altered. This helps teams know if their software can be safely released, improving overall software safety.
Open → 2609.31282v1

Skill based agents vulnerable to harmful hidden cross skill attacks

Stealth Apart, Harm Together: Skill Cascading Attacks on Skill-Based Agent Systems

Abstract: A skill is a modular package of natural-language instructions, executable scripts, and reference resources that an agent can load at runtime to extend its capabilities for a specific task. Skill-based agent systems therefore enable flexible reuse of third-party capabilities, but the openness of this skill ecosystem also opens up a new attack surface. Prior work has focused on vulnerabilities within individual skills, but little attention has been paid to risks that arise from interactions across skills. In this paper, we introduce skill cascading attacks, a threat paradigm in which a malicious objective is distributed across multiple skills so that each modification looks benign in isolation, yet their combined execution is harmful. For instance, in a prescription-review pipeline, the first skill weakens signals of recently discontinued medications in the extracted history, the second downgrades the severity of any drug interaction tied to them, and the third suppresses the resulting low-priority alert in the final summary, so that a severe drug-interaction warning silently disappears before reaching the physician. To systematically study this safety blind spot, we develop SkillCascade, an automated multi-agent red-teaming framework, and release SkillCascade-Bench, a benchmark of 213 validated cascading test cases across multiple agent systems and domains. Across representative agents (e.g., OpenClaw, Claude Code, Codex) and LLM backbones, cascaded interactions reliably induce harmful behaviors while evading existing per-skill scanners and runtime monitors. Our findings highlight a gap between component-level integrity and system-level safety, and call for defenses that reason over cross-skill interactions rather than individual skills in isolation.

Thu 24 SeptArtificial Intelligence
The gist
Skill-based agents use small sets of instructions called skills to perform different tasks. The authors found a new kind of attack where harmful actions are split across several skills, appearing safe individually but dangerous together. They showed that these hidden combined attacks can trick current safety checks and cause serious problems, like hiding drug interaction warnings in medical systems. Their work points out that checking each skill alone is not enough to keep these systems safe.
Open → 2609.30383v1

Language models identify code style not author identity in zero-shot tests

Style, Not Self: Surface Cues Explain Zero-Shot Code Attribution by Large Language Models

Abstract: If a language model can recognize code it wrote, it may favor that code as a judge, and instances of one model monitoring each other could collude. We test this zero-shot on current commercial models. Five LLMs generate solutions to MBPP, HumanEval, and DS-1000, seven more to MBPP, and models act as evaluators in four tasks: picking their own solution from a pair, judging whether a single solution is their own, identifying which of two solutions a named model wrote, and judging quality blind. In the single-solution task, balanced accuracy is 49-58% for all 15 model-benchmark combinations, while raw accuracy (38-67%) mostly reflects how readily a model claims authorship. In the pairwise task, accuracy across 14 evaluator-opponent combinations correlates at r=0.93 with how often the evaluator's solution is longer. Attribution to a named model succeeds on some pairs and is consistently inverted on others. A rule-based normalization that strips docstrings, comments, type hints, and local names preserves Pass@1 and leaves ten of twelve re-tested results at chance; the other two follow a length difference it leaves, although a trained classifier still separates most normalized pairs. Claude Haiku's self-preference also disappears. We recommend reporting balanced accuracy, heuristic baselines, and label consistency.

Thu 24 SeptArtificial IntelligenceComputation and LanguageSoftware Engineering
The gist
Sometimes computer programs try to guess if a piece of code was written by themselves or another program. This study found that large language models don’t really recognize their own code but instead rely on surface details like length and style. When these obvious clues are removed, the models perform no better than guessing. The authors suggest using balanced accuracy and simple baseline tests to report these results more clearly.
Open → 2609.30048v1

Malicious NPM package detection with lightweight static and AI analysis

DistillGuard: Malicious NPM Package Detection and API Attack Chain Analysis via Static Graph and LLM Distillation

Abstract: The Node.js ecosystem heavily relies on NPM packages, and software supply chain attacks targeting malicious NPM packages are rampant. Malicious code primarily triggers during package installation, import, and runtime. Traditional static analysis fails to understand code semantics; machine learning-based methods rely on feature extraction, which suffers from concept drift; existing LLM solutions suffer from high invocation costs, high data security risks, and poor performance. To overcome these limitations, we propose DistillGuard, a lightweight malicious NPM package detection framework that combines static graph semantic analysis and LLM knowledge distillation. DistillGuard first acquires multi-granular features through three static analysis modules. Then, it leverages online LLM to distill high-quality security knowledge and structured labels. Finally, it uses LoRa to efficiently fine-tune the open-source Qwen3-8B model to support offline deployment. Experiments show that DistillGuard achieves an accuracy of 95.3\%, a precision of 99.4\%, and an F1 score of 93.8\%, outperforming state-of-the-art tools, improving the F1-score by 11.1 to 30.0 percentage points over the baselines. Our empirical research further reveals the stages of malicious attacks and the distribution of malicious behaviors. We also summarized eight typical API attack chains for malicious activities, providing practical insights for NPM supply chain security defense.

Thu 24 SeptCryptography and Security
The gist
NPM packages are used widely in software, but some contain harmful code that can cause damage when installed or run. Existing methods to find these bad packages either miss important details or are too costly and risky to use. The authors developed DistillGuard, a tool that uses detailed code analysis and a small AI model to detect malicious packages accurately and quickly. Their tests show DistillGuard works better than previous tools and also helps understand how these malicious packages attack systems.
Open → 2609.28996v1

Soundness checking boosts precision of taint flow models from AI

Soundness Checking of Taint Flow Models

Abstract: Existing state-of-the-art static taint flow analyses for imperative programming languages can scale to large applications by using precise user-provided taint flow models of library methods. However, manually and precisely modeling a method's taint flows is tedious and potentially unsound. Furthermore, automatically modeling the method via an inter- procedural taint analysis can be inefficient. To solve this problem, we propose a guess-and-check approach: (1) an LLM agent that generates a precise taint flow model of a method and (2) a symbolic algorithm to check the soundness of the model. The algorithm deduces which taint flows must not occur in the method for the LLM's taint flow model to be sound, and uses lightweight static analyses (e.g., type system and pointer analysis) to prove these must-not-flows. When these analyses are insufficient, the algorithm deduces maximally-general callee models and recursively verifies their soundness, avoiding a full inter-procedural taint analysis in most cases. Since a more precise model requires fewer must-not-flows to be verified, the precision of the LLM's model directly determines the efficiency of our approach. We evaluate our approach on 97 LLM-generated taint flow models for methods in 6 large Go codebases and prove the models sound for 93% of the methods they cover. The proven-sound LLM-generated models are also precise, resulting in no new false-positives when proving taint flow properties.

Wed 23 SeptSoftware Engineering
The gist
Finding errors when tracking unsafe data in code is hard, especially when code libraries are involved. The authors used an AI to guess how data flows through library methods, then checked these guesses carefully using special math and simple program checks to make sure they're accurate. This way, they avoid slow checks of the whole program while still catching almost all errors. Their approach works well on many real computer programs and keeps false alarms low.
Open → 2609.28750v1

Control tokens can block reasoning in AI tool-using agents

Control-Token Injection Suppresses Chain-of-Thought and Defeats Reasoning-Based Oversight in Tool-Using Agents

Abstract: The safety of a tool-using language model agent is usually treated as a property of the model alone. We give controlled, full-precision evidence that it is instead a joint property of the model and the software that renders its chat template and parses its tool calls, the decoding harness, and that both halves are attackable from untrusted input. On the released gpt-oss-20b reasoning model under its published tool sandbox, appending a single string of the model's own channel-control tokens to a user message makes the tokenizer render a reasoning turn that is already complete, so the model writes no chain-of-thought and proceeds directly to the tool call. Across forty tasks the model already completes, the reasoning channel falls from a mean of 52.5 tokens to zero on every trial while the http.post still fires on every trial. A rule monitor and a cross-family language-model monitor detect the unsafe request on all plain trials and no forged trials, and on overtly malicious requests the attack converts 39.6% of the model's refusals into completed exfiltrations. Separately, whether an identical tool-call generation fires is decided by the harness parser, not the model: a truncation-tolerant regular expression fires a call whose closing token is missing while a strict one drops it, and two parsers shipped for the Gemma agent give opposite outcomes on identical greedy generations, firing on all twenty-four trials and on none. We show the suppression can be delivered indirectly and characterize its dependence on the chat template across two more reasoning models, and we evaluate input sanitization, parser hardening, and empty-reasoning detection as defenses; flagging an absent trace catches the basic attack but not an adaptive benign decoy. All measurements use greedy decoding on publicly released models. Code and per-trial logs: https://github.com/Usama1002/deleting-the-trace

Wed 23 SeptCryptography and Security
The gist
Sometimes AI systems that use tools are expected to think step-by-step before acting, which helps keep them safe. This paper shows that by adding a special hidden signal called control tokens to the input, someone can make the AI skip the thinking part and jump straight to using a tool. This trick fools safety checks and lets the AI do unsafe actions unnoticed. The authors tested this on public large language models and examined ways to stop or detect the trick, finding some methods work only partially.
Open → 2609.27542v1

Latent reasoning improves single-shot JavaScript code deobfuscation accuracy

Stage-Supervised Latent Reasoning for Single-Shot JavaScript Deobfuscation

Abstract: JavaScript obfuscation is widely used to protect code, but it also makes program analysis and security review substantially harder. Existing LLM-based deobfuscation methods usually treat the task as one-step translation, ignoring the staged structure of practical deobfuscation pipelines. This WIP paper proposes a stage-aware latent reasoning framework that converts intermediate outputs from a deterministic deobfuscation tool into supervision for Coconut-based training. The model learns from multi-stage rewrites during training but generates the final cleaned program in a single shot at inference time. Preliminary results on JsDeObsBench show that the Coconut-based model improves syntactic validity to 50%, compared with 15% for direct fine-tuning and 25% for a zero-shot baseline, and reaches 80% semantic correctness among valid outputs, indicating better semantic faithfulness than either comparison model in deobfuscation.

Tue 22 SeptSoftware Engineering
The gist
JavaScript code can be purposely scrambled to hide what it does, which makes it harder to study or fix. The authors propose a method that learns from step-by-step cleaning examples but produces a fully clean version in one try. Their approach uses intermediate hints from existing tools to train a model that better understands how to undo the scrambling. Tests show it creates more syntactically correct and semantically faithful versions of code than simpler methods.
Open → 2609.27058v1

Open privilege measurement shows gaps in agent tool defenses

Ajar: Measuring Open Privilege in Agent Defenses

Abstract: A language model agent acts through the tools it is given. The data it reads while working on a task can redirect what it does with those tools. A growing set of techniques for safe and secure agent execution therefore sits between the agent and its tools, aiming to enforce access control, information flow or isolation at that boundary. Today these techniques are evaluated on agent-security benchmarks built around indirect prompt injection. Those benchmarks judge a defense by how far it brings the number of successful attacks down while preserving the agent's utility. A defense is judged only on the agent's execution. It can score well on both metrics while holding open a transfer, a deletion or a broad read that no task needed. Ajar measures that open privilege directly using the existing benchmarks. It attaches to an agent-security benchmark that already exists and reuses the tasks, tool schemas, reference solutions and goal states that benchmark uses to grade its own runs. For each benign task it builds candidate tool calls the task does not need, so allowing one is privilege left open. These calls are presented to the defense at every point where the agent could act. We evaluate Ajar by attaching it to AgentDojo, where open privilege becomes a third axis beside the existing attack success and benign utility. We run it on five defenses: Progent, CaMeL, AC4A, Permission Assistant, and Claude Code's Auto mode. We observed that they leave widely different amounts of privilege open. Two defenses leak by almost the same amount yet differ widely in the benign tasks they finish, and one defense buys part of its tightness by refusing calls its tasks were entitled to make. This open privilege cannot be derived from the measured attack success or benign utility. The source code of Ajar is available at https://github.com/reSHARMA/Ajar.

Tue 22 SeptCryptography and SecurityArtificial IntelligenceSoftware Engineering
The gist
Computer programs called language model agents use tools to complete tasks, but they can sometimes access more data or perform actions they shouldn't. Existing tests check how well defenses stop attacks without hurting normal use, but they miss when extra permissions are still left open accidentally. The authors created a new way to measure exactly how much extra access these defenses leave open by trying out tool calls the task doesn’t need. They tested this on five popular defenses and found some let through much more open access than others, even if they stopped attacks well.
Open → 2609.26900v1

Code evolution tracing improves finding vulnerability commits

TraceVIC: Causal Reasoning over Code Evolution for Identifying Vulnerability-Inducing Commits

Abstract: Software vulnerabilities are often discovered long after they are introduced, making it difficult to identify the vulnerability-inducing commit (VIC) responsible for introducing the underlying vulnerable condition. Existing VIC identification techniques largely rely on git blame to trace vulnerable code through revision history and use positional heuristics, such as selecting its earliest or most recent modification. However, the true VIC may occur anywhere within this history, and vulnerable behavior may depend on code that evolves across multiple revisions. We therefore argue that VIC identification requires reasoning about how vulnerability-relevant code evolves, rather than simply where a candidate commit appears in the revision history. We present TraceVIC, a temporal graph-based approach for identifying and ranking VICs by reasoning over code evolution. TraceVIC first localizes likely root-cause lines and traces their histories across revisions, constructing graph representations that capture program structure within each revision and the evolution of vulnerability-relevant code across the history. It reasons over the resulting revision history, using temporal edges to preserve correspondences between program elements across consecutive revisions, and directly ranks candidate commits according to their contribution to the vulnerable condition. Ablation results show that modeling the full revision history improves F2 from 0.637 to 0.814. TraceVIC improves F2 by up to 28.7% over state-of-the-art methods and identifies a valid VIC for 78 of 79 vulnerabilities across four unseen C/C++ projects.

Tue 22 SeptSoftware EngineeringArtificial Intelligence
The gist
Software bugs that cause security problems often creep in during code changes but are discovered much later, making it hard to find the exact change that introduced them. The authors propose TraceVIC, a tool that looks at how code changes over time rather than just the earliest or latest related code. TraceVIC builds a detailed map of code evolution and uses this to better identify which change caused the vulnerability. Their method outperforms previous techniques and reliably finds the problematic changes in different C and C++ projects.
Open → 2609.26711v1

Authorization checks must match executed actions after reconstruction

From Approval to Execution: Reconstruction-Aware Repair Analysis for LLM-Agent Software

Abstract: Approval mechanisms have become a primary safeguard for consequential actions in LLM-agent software. Yet the action shown for approval is often not the object ultimately consumed: workflow reload, transcript projection, argument rebinding, and durable-state lookup may reconstruct it before execution. Existing fieldflow and check-coverage analyses can establish that expected fields were inspected, but not that the inspected object version reaches the sink or that no replacement intervenes between check and use. Consequently, a locally complete repair may still leave a residual authorization bypass after reconstruction. We address this problem through three designs. (1) We formulate reconstruction-stable authorization (ReSA) over representation transitions, sink dependencies, consumed versions, and grant scope. (2) We derive obligations that judge candidate repairs and expose residual sink suffixes. (3) We implement the analysis in APAS-Finder and freeze predictions before an independent sink oracle observes execution. Predictions agree with all 28 controlled outcomes. Four matched pairs require opposite judgments despite identical field-flow and check coverage; a CodeQL composite recovers all eight when supplied object flow, dominance, interference, and the same grant contract. Two analysts agree on all four model-validation dispositions and 19/20 sink dependencies. On released consumers, five repairs prevent 60/60 tested out-of-scope effects, while three mechanism contrasts expose the predicted residual effects. Repair sufficiency therefore depends on the reconstructed action consumed, not merely on an approval record or earlier checked representation.

Tue 22 SeptSoftware Engineering
The gist
The paper shows that when AI agents ask for permission to act, what you see for approval isn't always what the system finally executes. The authors explain how changes made behind the scenes can let unauthorized actions slip through. They created a method to analyze if the final action truly matches what was approved, catching hidden authorization bypasses. Their approach was tested and confirmed to catch issues missed by earlier techniques.
Open → 2609.26529v1

Automatic c to rust refactoring tools do not ensure memory security

C-to-Rust Fallacy: Automatic Refactoring != Memory Security

Abstract: Rust has emerged as the leading system programming language, offering strong memory and type safety guarantees without compromising performance. This positions it as a compelling alternative to traditional languages like C and C++, which are susceptible to memory security bugs. However, manually transforming C to Rust requires in-depth domain knowledge of the Rust language features, which requires significant effort for developers. To address this, tools for automatic C-to-Rust refactoring aim to generate safe Rust code leveraging static analysis and Large Language Models (LLMs). While these tools claim to achieve safety by reducing the unsafe Rust, the correlation with improving security is not clear. In this paper, we conduct a comprehensive empirical study on the reliability, safety, and correctness of various C-to-Rust refactoring methods. Specifically, we evaluate C2Rust-analyze, CROWN, C2SaferRust, and FLOURINE using a dataset of 116 C programs with memory security bugs from the NIST Juliet Test Suite. Based on 464 Rust programs generated by these tools, our evaluation focuses on three key aspects: the compilation correctness of the refactored programs, the effectiveness in mitigating original C bugs, and the tendency to introduce additional Rust bugs. The results indicate that 342 Rust programs fail to compile, 177 Rust programs inherit memory security bugs from the original C programs, and 77 new Rust bugs are introduced. We examine the rationale behind tool design and analyze the root cause of errors across various refactoring methods. Our findings indicate that current automated refactoring tools deliver memory safety as they define it, but not the broader memory security when adopting them.

Tue 22 SeptCryptography and Security
The gist
Many tools try to automatically convert C programs to Rust to fix memory safety bugs, since Rust is known for better memory safety. The authors tested several popular automatic refactoring tools on programs with known memory bugs. They found that many converted programs either fail to compile, still have memory bugs, or even gain new bugs. The study shows that while these tools reduce certain unsafe Rust code, that doesn’t guarantee the Rust code will be truly secure from memory errors.
Open → 2609.25682v1

LLM agent actions controlled by runtime policy enforcement system

ActGov: Governing LLM Agent Actions via Policy-Constrained Validation

Abstract: Large language model (LLM) agents increasingly execute long-horizon workflows through external tools, allowing untrusted outputs to influence subsequent actions and exceed user authorization. Existing defenses isolate injected content or constrain execution with predefined plans and static policies, but these approaches are brittle under dynamic workflows and scale poorly across extensible tool ecosystems. In this work, we present ActGov, a runtime enforcement framework that validates each LLM-proposed tool action before it causes external effects. Built on a unified semantic model of authorization, actions, runtime context, and security constraints, the ActGov-Policy component iteratively constructs a policy set from tool specifications, benign tasks, and observed failure traces, with each update verified through SMT-based counterexample checking. At runtime, ActGov-Runtime abstracts each tool call into finite policy records and permits it only if it remains within the task-scoped authorization boundary and satisfies all applicable policies. This per-action enforcement preserves authorization throughout long-horizon, dynamically branching workflows. We evaluate ActGov on the AgentDojo and AgentDyn benchmarks across multiple models and attack configurations. It shows that ActGov consistently reduces the success rate of indirect prompt-injection attacks while preserving task utility, significantly outperforming existing defenses. These results demonstrate that ActGov can enforce fine-grained authorization over dynamic agent executions without relying on the underlying LLM to correctly identify malicious instructions.

Mon 21 SeptCryptography and SecurityArtificial Intelligence
The gist
Large language models (LLMs) can run complex tasks by using external tools, but sometimes they do things outside what they're allowed to do, which can be risky. The authors created ActGov, a system that checks every action an LLM wants to take before it actually happens, making sure it follows set rules and permissions. It updates these rules dynamically and stops bad instructions even when the LLM doesn’t recognize them as harmful. Their testing showed ActGov effectively blocks common attacks while still letting useful tasks finish.
Open → 2609.24446v1

Control flow graph neural networks vary in malware detection over time

Temporal Generalization and Explanation Stability of Control Flow Graph Neural Networks for Malware Detection

Abstract: Malware detection is a critical task in cybersecurity, and graph neural networks over control flow graphs have shown promising results for it. However, detectors are usually evaluated on a random split of a corpus collected over a single period, which cannot show how well a model generalizes to later samples. This study addresses that limitation with a strict temporal split: every model is trained on one period and scored once on a later one. Two corpora of control flow graphs, each node carrying 37 features, were extracted statically from 1,989 Windows portable executables: 459 graphs from 2024-2025 for training and 223 from 2026 for evaluation. Twelve variants and a flat-feature control were trained on the earlier corpus. The choice of message-passing operator changes robustness to the shift significantly, and every pairwise gap that survives correction separates an aggregating architecture from one built around a learned attentional readout. The ranking also reverses: the flat control, which sees node features but no topology, is the best in-distribution model and among the worst across the boundary, so a conventional benchmark would have rejected message passing. Neither recalibration nor ensembling substitutes for the operator choice. Attributions do not shift, but explanation validity is architecture-specific, and the most accurate operator on the later corpus is the hardest to explain. An architecture derived from the finding matches the best searched operator without search. The shift affects both malware and benign classes alike, so these are results about robustness to distribution shift, not malware evolution.

Mon 21 SeptCryptography and SecurityArtificial IntelligenceMachine Learning
The gist
Malware detection helps computers spot harmful software, but models tested only on past data might fail on newer malware. The authors studied how well graph-based neural networks, which analyze program structure, perform on malware from a later time. They found the choice of neural network design greatly affects how well the model handles new data. Surprisingly, simple models ignoring graph structure do best on past data but fail on future samples. This means testing malware detectors over time is crucial to find designs that remain accurate and explainable.
Open → 2609.24280v1

Combining defenses improves language model safety against jailbreak attacks

CASCADE Against Jailbreaks: Combination Across Stages with Controlled Attack-Defense Evaluation

Abstract: Defenses against jailbreak attacks on Large Language Models (LLMs) operate at different pipeline stages, such as input modification or output guard, but it remains unclear which defenses to deploy at each stage and how to combine them. Prior empirical studies, fragmented by inconsistent attack-success-rate definitions and experimental settings, have evaluated defenses largely in isolation. Here we present the first systematic study, to our knowledge, of defense combinations both within and across pipeline stages, under a consistent threat model of direct, black-box, single-turn attacks. Our decision framework standardizes evaluation through a principled attack-success-rate formulation with controlled query budgets, together with explicit fairness rules. Across 19 attacks and 15 defenses, we find that no single defense is universally best, but well-chosen combinations achieve substantial safety with minimal utility degradation, yielding practical recommendations for layered defense pipelines.

Fri 18 SeptCryptography and SecurityComputation and Language
The gist
Some people try to trick large language models (LLMs) into giving harmful or unintended answers, called jailbreak attacks. Defenses exist that work by changing the input or blocking bad outputs, but it’s not clear which work best or how to combine them. The authors studied 15 defenses and 19 attacks together under consistent conditions to figure this out. They found that no single defense stops all attacks, but using multiple defenses in a careful way can make models much safer without making them less useful.
Open → 2609.21793v1

Code vulnerability models struggle with harmless code edits causing errors

Embedding Drift in Code Vulnerability Models Under Intended Behaviour-Preserving Transformations

Abstract: Code edits that preserve program behaviour can shift frozen code embeddings across classifier decision boundaries, causing correctly detected vulnerabilities to be predicted as benign. Such instability is problematic because semantically neutral changes, including comment removal, insertion of unreachable code, variable renaming, and loop rewriting, should not alter a model's security judgment. We investigate this issue using 15,000 C/C++ functions organized as 7,500 vulnerable-patched pairs from the Big-Vul dataset. Four mutation tracks are applied to both vulnerable and benign samples: comment removal, unreachable code insertion, variable renaming, loop rewriting, and a combined setting that applies all transformations. Using frozen microsoft/codebert-base embeddings with six downstream classifiers, we evaluate the robustness of vulnerability predictions and introduce a train-only defence that projects clean and mutated representations closer together while preserving vulnerability-class information. Under combined mutations, the baseline Vulnerable Flip Rate (VFR) ranges from 35.55% to 42.15%. The proposed defence reduces the mean common-set VFR from 22.60% to 11.32% and improves mean mutated accuracy from 55.33% to 57.10%. For Logistic Regression, VFR decreases by 17.29 percentage points, although benign-to-vulnerable flips increase by 11.95 percentage points. These results indicate that the defence improves robustness to semantics-preserving code transformations but introduces a false-positive trade-off and does not fully eliminate prediction instability.

Fri 18 SeptSoftware Engineering
The gist
Sometimes, small changes to computer code that don't actually affect how it works can confuse models that try to find security problems. The authors studied how edits like removing comments or renaming variables cause these models to change predictions mistakenly. They tested a defense that helps the model stay more stable and keep similar predictions even after these harmless changes. However, this fix makes the model slightly more likely to incorrectly label safe code as vulnerable. Overall, the problem isn’t fully solved but the defense improves reliability.
Open → 2609.21203v1

Cashews improves large file scanning for malicious npm packages

CASHEWS: Source Preprocessor for LLM-based Malicious Package Detection

Abstract: Malicious npm package detection tools now leverage LLMs' semantic understanding of source code to detect malicious intent at scale. This capability has proven invaluable in identifying packages involved in recent supply-chain attacks such as Shai-Hulud. However, threat actors exploit the limited context windows of LLMs through JavaScript techniques such as code obfuscation that yields high token density and bundling malicious code with benign packages, causing detectors to skip large files or miss malicious behavior. This creates an attack surface for evading detection. In this paper, we present CASHEWS, a JavaScript preprocessor that reduces file size by rewriting source code to remove code that is irrelevant to analysis or likely to mislead the model. Given a package source file, CASHEWS deobfuscates it through iterative decoding, extracts bundled modules and dynamically executed code, identifies malicious sinks and computes backward slices that reach them, and abbreviates long literals and identifiers to produce a compact representation for the detector. Across 512 large package files, two scanner types, and three LLMs, CASHEWS increases analysis coverage from 69.1--85.7% to 98.8--100% and reduces the false-negative rate by up to 18.6 percentage points. CASHEWS also has a median preprocessing time of 30 seconds while reducing net analysis cost by 34.6%, making registry-wide LLM-based analysis more practical. By preprocessing source code before analysis, CASHEWS enables researchers and industry practitioners to use more powerful models for malicious package detection at the same or lower analysis cost as less powerful models.

Wed 16 SeptCryptography and Security
The gist
Detecting harmful code in software packages is hard because bad actors hide their malicious code in large or confusing files that AI tools can't fully analyze. The authors created CASHEWS, a tool that cleans up and simplifies JavaScript code files by removing irrelevant or misleading parts and extracting hidden modules. This makes it easier for AI detectors to understand and check the code more thoroughly. CASHEWS helps catch more malicious packages while also saving time and computational resources.
Open → 2609.18862v1

CaMeLoT checks AI agent plans for safety before execution

CaMeLoT: CaMeL orchestrated with Temporal logic for static verification and liveness

Abstract: LLM-based agents generate and execute multi-step plans that invoke external tools which can access private data or execute commands. In this setting, security is a property of the entire execution that a plan creates, not just any single step. The plan itself is a critical artefact that captures the tool calls, control flow, and data dependencies. We present CaMeLoT, a complement to CaMeL, an existing defence against prompt injection in tool-using LLM agents. CaMeLoT extends CaMeL by adding a static verification layer that checks an agent's plan before any tool is invoked. CaMeLoT translates a generated plan into a finite-state transition system, labels it with tool calls, provenance and taint information, and checks it against temporal policies expressed in CTL using the nuXmv model checker. Because verification happens before execution, unsafe plans are rejected without using LLM calls or tool calls, saving tokens that runtime could have cost, as well as the need to unwind changes or teardown temporary sandboxes. When a verification fails, the model checker returns a counterexample to give feedback to the agent to repair the plan. We evaluate CaMeLoT on policies derived from the AgentDojo benchmark, SOC workflows, and prompt-extraction experiments, showing that it verifies a broad class of temporal properties before execution while preserving CaMeL's runtime-checkable coverage.

Wed 16 SeptCryptography and SecurityLogic in Computer Science
The gist
Large language model (LLM) agents use tools that can handle sensitive data or commands, so it’s important to ensure their entire plan is safe, not just each step. The authors present CaMeLoT, a system that examines the agent’s plan before any action happens, verifying it against rules expressed in temporal logic. If the plan is unsafe, CaMeLoT rejects it early and provides feedback for correction, saving resources and preventing harmful tool use. They tested CaMeLoT on various benchmarks and confirmed it can verify many safety properties efficiently before execution.
Open → 2609.18674v1

AI systems generate annotations to guide software testing efficiently

AIJon: Automated Generation of Annotations for Fuzzing

Abstract: Modern fuzzers use code coverage as feedback to guide their exploration which has proven to be an effective strategy for driving exploration. However, this strategy overlooks inputs that may be interesting to the target program even without uncovering new code paths. Fortunately, prior research has shown that annotations generated by human domain experts can provide additional feedback, guiding the fuzzer towards interesting parts of the program. In this paper, we replicate experiments presented in IJON and extend them to real-world vulnerability detection at scale. To mitigate the scalability challenge, imposed by the need for human domain expertise, we propose utilizing LLMs to automatically generate annotations. We demonstrate the applicability of LLMs for this purpose and observe that LLMs can generate annotations that perform comparably to human-generated annotations. Motivated by this finding, we design AIJON, a system that leverages LLMs to automatically generate IJON-style annotations. We evaluate AIJON on the Magma benchmark and surprisingly observe that annotation-based fuzzing does not perform strictly better than AFL++. We conduct several experiments to identify the cause of our results and identify key insights regarding the impact of annotations on fuzzing campaigns, including their effect on the energy distribution of the fuzzer. Notably, we observe that LLMs can generate annotations that achieve comparable results to human generated ones, thus opening the door for future research to perform further studies on the impact of annotations at scale.

Wed 16 SeptCryptography and SecuritySoftware Engineering
The gist
Software testing programs called fuzzers usually try out many inputs to find bugs by looking for new ways the program runs. But some useful inputs don’t lead to new ways of running code, so they can be missed. The authors studied a method where notes (annotations) help guide fuzzers to interesting parts. They found large language models (LLMs), a type of AI, can create these notes almost as well as humans. Although using these AI-generated notes didn’t always improve testing, the work shows it’s possible to automate this part and suggests future research to see when annotations help.
Open → 2609.18457v1

Software agent tracks third-party components across development stages

From Component Snapshots to Lifecycle Traces: Agent-Based Software Composition Analysis

Abstract: Software supply-chain security requires accurate identification of third-party components and an understanding of how they evolve from development to execution. Existing software composition analysis (SCA) approaches examine manifests, build environments, release artifacts, containers, or runtime states, but typically produce only stage-specific views of software composition. As dependencies are resolved, removed, repackaged, and transformed across lifecycle stages, a single snapshot cannot capture both where a component originates and where it ultimately ends up. Combining snapshots from multiple stages still leaves their cross-stage relationships unresolved. We present SCA-Agent, an agent-based approach to lifecycle-aware SCA that reconstructs evidence-backed component lifecycle traces across Code, Build, Release, Deploy, and Runtime. SCA-Agent adaptively explores project-specific analysis paths, gathers stage-specific evidence, and correlates observations across stages to recover component identities, versions, introduction paths, propagation relationships, and final lifecycle states. We evaluate SCA-Agent on 105 real-world projects from the Java, JavaScript, and Python ecosystems. SCA-Agent achieves the highest component detection F1 across all lifecycle stages and ecosystems. For vulnerability exposure assessment, it reaches an F1 score of 96.69%, exceeding the best traditional SCA tool by 18.76 percentage points. These results show that lifecycle-aware SCA supports traceable component provenance and more accurate software supply-chain risk assessment.

Wed 16 SeptSoftware Engineering
The gist
Knowing exactly which third-party software pieces are used and how they change throughout development is hard. Existing tools look at only one point in the software's life, missing the full story. The authors created SCA-Agent, a tool that follows components from coding through to running the software, gathering clues at each stage. It helps identify component versions, origins, and changes better than previous methods. This gives a clearer picture of software risks from third-party parts.
Open → 2609.18391v1

AI coding agents exposed to poisoned tests can self-insert security flaws

Reflections on Trusting Trust, Revisited: Contaminating Self-Modifying AI Coding Agents with Poisoned Benchmarks

Abstract: Thompson's "Reflections on Trusting Trust" showed that a compiler can be poisoned to reinsert its own backdoor, so that even recompiling clean source reproduces the Trojan. Today, substantial coding work is done by AI coding agents -- and increasingly, those agents generate new versions of themselves. We reconsider Thompson's attack when the "compiler" is a self-modifying coding agent. Can an adversary supply poisoned benchmarks to the agent's self-evaluation and self-improvement process to induce future versions of the agent to write vulnerable code on clean, held-out tasks? We instantiate this attack against three recently proposed self-modifying coding agents: the Darwin Gödel Machine (with our experimental modifications), the Self-Improving Coding Agent, and Hyperagents (both substantively unmodified). We demonstrate successful proofs-of-concept: for example, with Hyperagents powered by Sonnet 4.5, our poisoned benchmark leads the agent to self-evolve instructions that disable HTTPS certificate validation on neutral URL-fetching tasks. From our experiments, we distill properties of the vulnerability, benchmark, model, and agent scaffolding that are sufficient to enable a benchmark poisoning attack. Moreover, we show that contamination often persists even when a poisoned agent is subsequently evolved against clean benchmarks. We discuss defensive directions and argue that self-modifying coding agents must be designed to be more resilient to such attacks.

Tue 15 SeptCryptography and SecurityArtificial Intelligence
The gist
Old computer viruses could hide in compilers and keep coming back even when the code looked clean. The authors show that modern AI programs that write and improve their own code can be tricked in a similar way by giving them bad test examples. These poisoned tests cause the AI to add hidden security problems in future versions, like turning off website certificate checks. The problem can persist even if the AI later works only on good tests. The authors suggest AI coding tools need better defenses against these sneak attacks.
Open → 2609.17817v1

AI agent skills boom shows challenges in governance and cleanup

After the Party: Governing What a Viral Agent-Skill Ecosystem Left Behind

Abstract: AI agents increasingly act through agent skills, i.e., natural-language instructions, that direct a host agent toward shell, network, credential, file, and process actions, and public registries distribute them at scale. In the first half of 2026, the OpenClaw AI agent went viral, and its public skill registry boomed: the observable stock nearly doubled in 91 days, and a majority of the listings visible in June were created in just two months. By the end of our study window, the wave had crested, and monthly listing creation and core-repository activity were falling from their spring peaks. This paper measures what the boom left behind, drawing on the OpenClaw Git history, its GitHub issues and pull requests, and three ClawHub registry snapshots. Attention is concentrated: the top 10% of skills received 46.93% of all downloads. No simple skill features (like size or download counts) remained a stable predictor of continued listing once creation cohort and skill age were controlled. Human scrutiny did not stay: 77.86% have zero stars and zero comments, while 85.06% of the readable skills carry privilege evidence. And automated cleanup is not ready: the three security scanners disagreed on 23,702 of the 61,990 skills they all cover. After human adjudication, weighted scanner sensitivity against the reference standard ranged from 21.67% to 61.06%. Governing fast-growing agent-skill registries cannot rely on simple metadata or single scanner scores; it requires robust, transparent measurement and independent validation.

Tue 15 SeptSoftware EngineeringArtificial IntelligenceComputers and Society
The gist
AI tools called agent skills help automate many computer tasks, and a popular one called OpenClaw saw a huge rise in new skills in early 2026. The authors found that most of these skills got little attention or review, many had risky permissions, and tools to automatically check their safety often disagreed. This means keeping these AI skill collections safe and well-managed is more complicated than just looking at download numbers or simple checks.
Open → 2609.17274v1

Memorization floor reveals limits of ai code refinement gains

A Memorization Floor for LLM Refinement of Decompiled Code

Abstract: We introduce a memorization floor: a within-item control separating what LLM refinement of decompiler output recovers from its input from what it recovers from its prior. Refine a function, then refine it again from an input whose identifiers have been destroyed, and measure what survives. Because the comparison is within-item, corpus difficulty cannot contribute; it costs twenty API calls. Applied to functions written after our analysis plan was committed, so no released model could have memorized them, it reports two things. Recovery is real: refined output sits +0.072 to +0.137 above an arm-matched permutation null built from its own output vocabulary. But it does not depend on the input we ablate: destroying the input's dataflow changes the naming gain by +0.001 (95% CI [-0.026, +0.026]), and removing type prefixes or permuting names changes it by no more. A second refiner from another vendor, registered in advance and given byte-identical inputs, reproduces this -- twelve contrasts, two models, twelve nulls. Readability stays at ceiling throughout, so a reader is given no signal. The null is bounded, not absolute: contributions under 0.056 are invisible, and the ablation leaves operations intact, so naming from those alone remains a competing reading. No registered hypothesis was confirmed, and we report the five instrument failures behind that in full, including a reassembly harness biased against the treated arm and an equivalence checker we registered without checking it worked on our inputs.

Tue 15 SeptSoftware Engineering
The gist
Improving decompiled computer code using large language models (LLMs) may seem promising, but the authors found that much of what these models add comes from memorizing patterns rather than understanding the input code. By destroying the input's identifying features and testing the model’s ability to recover names, they showed that the improvements don't rely on the input itself. This suggests that current LLM refinements of decompiled code might not truly understand or improve the code as much as hoped. The study carefully tested multiple models and conditions, but no strong benefits based on input code were confirmed.
Open → 2609.17236v1

Ganadi tracks c and c++ open source reuse to improve security

GANADI: Uncovering C/C++ OSS Reuse Genealogies via Pivotal Function-Based Clustering to Enhance Supply Chain Security

Abstract: We present GANADI, a systematic approach for identifying C/C++ OSS reuse genealogies to enhance software supply chain security. Understanding OSS reuse genealogy is crucial for improving SBOM completeness and prioritizing security remediation across supply chains. Although existing approaches can identify reused compo- nents and vulnerabilities within a project, they fail to trace OSS reuse paths through intermediate projects, limiting their effectiveness in securing supply chain ecosystems. To address this limitation, GANADI constructs reuse genealogies by clustering downstream projects based on shared characteristics of origin-derived code (called pivotal functions), and then inferring reuse direction among the projects within each cluster. When applied to 20 widely reused OSS projects with over 1,500 propagation paths, GANADI achieved 84.85% precision and 95.76% recall in identifying reuse genealogies, outperforming existing approaches that achieved at most 23.21% recall. Leveraging OSS reuse genealogy for vulnerability detection, we identified 48 unpatched vulnerabilities in real-world popular C/C++ projects. Among them, 23 were patched following our responsible disclosure (including one CVE ID assigned), demonstrating the practical impact of genealogy-based vulnerability management.

Tue 15 SeptSoftware Engineering
The gist
Software projects often borrow code from others, especially in open source. This makes it hard to know where code really comes from and where security issues might spread. The authors created GANADI, which groups projects by key shared code pieces and figures out who copied from whom. GANADI found reuse links more accurately than previous methods and helped find real security problems in popular projects, some of which were fixed after being reported.
Open → 2609.17018v1

Lossless tokenization stops forged control tokens in open language models

Nameless Tokenization: A Lossless Tokenizer-Level Defense Against Control-Token Forgery in Open-Weight LLMs

Abstract: Open-weight language models publish the strings their chat templates use to mark turns, roles and tool results, which the tokenizer maps back to the reserved identifiers the model obeys. Anyone who controls text in a prompt can therefore write a turn boundary indistinguishable from one the serving stack wrote. We audit 256 deployed chat tokenizers. All are forgeable, and the flag usually recommended as a fix leaves 56.6% forgeable because it misses the tool and reasoning markers agent systems rely on. We propose nameless tokenization, which leaves the control entries with a reserved identifier and no surface string, so the content encoder cannot emit one and message content reaches the model unaltered. Across five tokenizer families it reproduces the standard token stream exactly on attack-free data and lifts accuracy on a probe of delimiter-bearing text from 8.5% to 59.9%, where sanitizers lose it. Separating a delimiter's appearance from its identifier shows the identifier matters little against a bare task instruction, but carries most of a forged tool result and most of any forged turn once the system message tells the model to treat user content as data.

Tue 15 SeptComputation and Language
The gist
Language models use special tokens to mark parts of a conversation or tool outputs, and anyone can fake these tokens in prompts, tricking the model. The authors found that all 256 tested language model tokenizers can be fooled this way, even when common fixes are applied. They created nameless tokenization, which hides these special tokens from the input text so the model only sees genuine content. This method keeps normal behavior intact but greatly reduces errors caused by fake tokens in tests.
Open → 2609.16984v1

GitHub projects mostly use simple delays for Dependabot cooldown

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

Abstract: Automated dependency updates can rapidly propagate malicious package releases before maintainers and the broader community have enough time to detect them. In July 2025, GitHub made Dependabot cooldown generally available as a defense against software supply chain attacks. However, the effects of its early adoption remain unknown. In this exploratory study, we empirically examine how popular open-source GitHub repositories adopt and configure the feature and investigate their motivations. We find that security concerns motivated 83 of 92 adoption events with known motivations. Security linter warnings triggered 43 of 75 security-only adoptions. Among 251 ecosystems within repositories that retained cooldown, 97.2% set a general delay. Of these, 64.3% used seven days, while use of each update type setting was below 10%. Early adopters therefore favor simple default delays over fine-grained controls. These findings suggest that tools could provide robust defaults reflecting ecosystem support and reserve fine-grained controls for dependencies with clear update priorities.

Tue 15 SeptSoftware Engineering
The gist
Updating software packages automatically can sometimes spread bad updates too quickly. The authors looked at how popular GitHub projects use a feature called Dependabot cooldown, which slows down automatic updates to give people more time to check for problems. They found most projects used the default pause time of seven days instead of customizing settings. This shows that simple default options are usually preferred over complicated controls when protecting software.
Open → 2609.16605v1

NIST Bugs Framework offers clearer automated vulnerability classification than CWE

Evaluating the NIST Bugs Framework Against CWE as a Successor for Automated Vulnerability Classification

Abstract: Vulnerability classification based on root cause weaknesses is essential for numerous cybersecurity activities, where the Common Weakness Enumeration (CWE) serves as a public repository of such flaws. However, its overlapping entries create a non-orthogonal structure. The result is the same vulnerability being mapped to multiple weaknesses, complicating Root Cause Analysis (RCA) and triage. To address this, NIST Special Publication 800-231 introduces the Bugs Framework (BF), which organizes vulnerabilities into <cause, operation, consequence> triples and links such triples into a causal chain, so that a vulnerability carries its root cause and its sink together instead of a single terminal label. To date, however, BF has been specified but not evaluated regarding its performance against the challenges to automated classification. The evidence required for adoption has not been investigated empirically. We evaluate BF as a classification target and a complement to CWE using a systematically screened corpus of automated Common Vulnerabilities and Exposures (CVEs) linked to CWE research. We assess the reproducibility of CVE-to-BF classification through two evaluations. The first is qualitative: an anonymized inter-rater study in which 2 subject-matter experts (SMEs) independently mapped 13 CVEs onto the four BF axes. Annotators showed strong agreement on the cause and operation axes, while the attribute axis indicated fair agreement. We also tested our automated framework across two large language model (LLM) deployments under different budgets for reproducibility analysis. Despite limitations, such as evidence availability and the absence of retrievable fix commits for closed-source software, our findings support the claim that BF is a more structured and automation-friendly framework than CWE. Our exploration reveals specific gaps in BF, including under-specified guidance on attributes.

Mon 14 SeptCryptography and SecuritySoftware Engineering
The gist
Classifying software vulnerabilities helps cybersecurity teams understand and fix problems quickly. The existing system, called CWE, often assigns multiple overlapping labels to a single vulnerability, making it confusing. The authors studied a new system called the Bugs Framework that organizes vulnerabilities by cause and effect in a structured way. They found it easier to automate classification with this new method, though some parts need clearer guidelines. Overall, the Bugs Framework could improve how computers sort and explain vulnerabilities.
Open → 2609.16433v1

Metacognitive steering enables AI to control scientific reasoning processes

Metacognitive Steering: Learning the Structure of Scientific Judgment

Abstract: Long-horizon scientific discovery requires agents to alternate between exploration, disciplined execution, and critical reassessment as evidence changes. Current language models are trained primarily on the products of science and optimized using outcome-level signals, providing limited supervision for these process-level shifts in scientific judgment. We investigate whether such judgment can be recovered from scientist interaction traces and used to control the internal computation of a frozen frontier model. Using contrastive interventions collected during real scientific research, we identify a coordinated, low-dimensional control structure within Kimi 2.6, a trillion-parameter mixture-of-experts model. Residual analysis, attention-weight subspace alignment, and cross-layer singular value decomposition converge on a mid-depth control surface spanning key layers. We introduce Metacognitive Steering, an inference-time controller that reads the model's cognitive regime and dynamically composes layer-specific interventions for exploration, procedural convergence, or critical reassessment without modifying model parameters. Behavioral analyses show that this control produces more sustained exploration, explicit pruning, and evidence-responsive synthesis. We operationalize the method in Columbus-1, an autonomous research system that identified eight independently reproduced, attacker-reachable vulnerabilities in BlueZ and directed the design, simulation, and fabrication of a ten-foot rocket intended to land propulsively using non-throttleable solid motors. Together, these results show that process-level scientific judgment can provide supervision for interpretable, dynamic control over a model's reasoning strategy.

Mon 14 SeptArtificial Intelligence
The gist
Scientific discovery often requires exploring ideas, following strict methods, and rethinking conclusions as new evidence appears. The authors studied whether a very large AI language model can learn to shift its thinking process based on data from real scientists. They found a way to detect and control the AI's thinking style in the middle of its layers, allowing it to explore ideas, focus on following steps, or critically reassess results without changing the model itself. This new control method helped an AI system discover software vulnerabilities and design a rocket, showing that managing an AI’s reasoning steps can improve how it does scientific tasks.
Open → 2609.16245v1

Automated program repair agents often produce unsafe code when attacked

Adversarial Testing of Automated Program Repair Agents for Security Vulnerabilities

Abstract: Software agents with Large Language Models (LLMs) are designed for Automated Program Repair (APR) tasks, raising the possibility that, in the near future, APR agents will fix bugs automatically without much human intervention. Can we trust an APR agent to produce both functionally correct and secure code in such situations? What if attackers target production APR agents with adversarial issues that seem benign but may influence the agents to produce correct but insecure code? In this paper, we took a first step towards answering these questions by conducting an empirical study. First, we created SWEADV, a benchmark of 750 adversarial issue descriptions constructed from 150 repair tasks in SWE-bench Verified. For each repair task, we created five adversarial issue descriptions, one for each attack type: command execution, deserialization, path traversal, denial of service, and weak hashing. Second, we evaluated mini_swe APR agents from three LLM backends on SWEADV: GPT-5-Mini, MiniMax-M2.5, and DeepSeek-R. We found that on average, adversarial issue descriptions can induce malicious behaviors with successful repair in 51.7% of cases. Third, we investigated whether typical detection mechanisms are sufficient to prevent such malicious patches from being accepted. Pre-repair detection with LLM-as-judge on the adversarial issue descriptions resulted in an average detection accuracy of only 62.3%. Post-repair detection on adversarial APR patches using static analysis tools and LLM-as-judge achieved average detection accuracies of only 39.4% and 55.4%, respectively. We conclude that autonomous APR agents cannot be trusted yet in production deployment, given their susceptibility to adversarial attacks.

Mon 14 SeptCryptography and SecuritySoftware Engineering
The gist
Software tools that automatically fix bugs using advanced AI models might not always create safe code. The authors tested these tools with specially designed tricky problems meant to fool them. They found that about half the time, the AI fixed the code but introduced security risks. Current methods to detect these unsafe fixes are not very reliable. This means we cannot yet fully trust these automatic bug-fixers to safely repair code without human checks.
Open → 2609.15963v1

Language model systems struggle to find vulnerable code in big software projects

Vulnerability Localization Benchmark: Measuring Agentic Security Analysis at Repository Scale

Abstract: Language-model agents increasingly operate over complete software repositories, yet cybersecurity evaluations primarily measure whether they can detect, reproduce, or repair vulnerabilities rather than whether they can locate the relevant code. We study vulnerability localization: given a weakness class and an unfamiliar repository, identify the implementation files associated with that weakness. We introduce the Vulnerability Localization Benchmark (VLoc Bench), comprising 500 real world vulnerabilities from 290 repositories across six package ecosystems and 147 CWE categories. Each task pairs repository snapshots immediately before and after a security fix. On the vulnerable snapshot, an agent receives only the CWE description and read-only terminal access and must return the affected files; on the patched snapshot, it must determine that the recorded vulnerability is no longer present. We evaluate 27 language models and four static-analysis tools under a common agent interface. Repository-scale vulnerability localization remains difficult: the strongest system achieves 0.229 File F1, and 38.4% of tasks receive no correct localization from any evaluated model. We further find that stronger localization does not imply reliable behavior after remediation: systems that identify vulnerable files effectively can still report unsupported locations on patched repositories. These results establish vulnerability localization as a distinct repository-scale capability and provide a setting for studying both how security agents search for vulnerable code and when they should refrain from reporting it.

Mon 14 SeptCryptography and SecurityArtificial Intelligence
The gist
Finding exactly which files in a large software project are vulnerable to security issues is hard. The authors created a new benchmark called VLoc Bench using 500 real security problems in popular software repositories. They tested 27 language models and several code analysis tools on how well they could pinpoint the exact files with vulnerabilities. The best system could only correctly identify vulnerable files about 23% of the time, and many tasks were missed completely. This shows that locating vulnerable code is a difficult but important capability that is different from just detecting or fixing problems.
Open → 2609.15939v1

HazardAuditor improves safety for computer-use agents across platforms

HazardAuditor: From Executable Threats to Safer Computer-Use Agents

Abstract: Computer-use agents increasingly interact with browsers, terminals, file systems, and external services, introducing safety risks that emerge through runtime behavior rather than generated content alone. Existing guard models target static prompts and responses and are poorly suited to agent execution; existing executable safety platforms produce evaluation verdicts rather than the normalized supervision a guard model needs to learn across heterogeneous agent frameworks. We introduce HazardAuditor, an execution-grounded framework that closes both gaps. Its infrastructure runs heterogeneous agents (Claude Code, Codex, Hermes, and OpenClaw) in controlled environments and normalizes their interactions into a canonical event representation for cross-framework supervision. We further observe that token-level post-training objectives create a structural mismatch for generative guards, causing longer rationales to dominate gradient updates. Guard Policy Optimization (GuardPO) addresses this by converting deterministic safety outcomes into sequence-level advantages and normalizing rationale and verdict regions, making the safety decision the effective unit of optimization. Across multiple benchmarks and heterogeneous computer-use systems, HazardAuditor improves accuracy by up to 16.5 percentage points over the strongest prior guard. Code, models, and evaluation artifacts will be available at https://yunhao-feng.github.io/HazardAuditor/.

Mon 14 SeptArtificial Intelligence
The gist
Computer-use agents that interact with software like browsers and terminals can sometimes behave unsafely at runtime, which is hard to detect. The authors present HazardAuditor, a system that runs different agents in controlled setups and standardizes their actions to better supervise safety. They also introduce a method called Guard Policy Optimization to improve how safety decisions are learned, focusing on the final safety outcomes rather than long explanations. Their approach improves accuracy in identifying unsafe behaviors across various agent frameworks.
Open → 2609.15134v1

Python imports trigger bugs and security issues before application runs

Python Import as an Execution Boundary: An Empirical Study of Bugs, Vulnerabilities, and Analysis Gaps

Abstract: Python import does more than resolve dependencies: it executes code during module and package initialization. This behavior can trigger failures, load dynamic or native code, access resources, or change security-sensitive state before an application calls a package API. Prior work studies package selection, malicious packages, or package vulnerabilities. We present ImportMine, a study of import-related bugs and security vulnerabilities in Python software. We combine security advisories with PyPI project histories and use source and patch evidence to confirm how import activates cases, why the problem occurs, how developers fix it, and what program information is needed to explain the behavior. We retain 31 import-related advisory vulnerabilities and 38 application-data boundary cases and confirm 1,429 project-history bugs across 1,302 repositories. Among the project-history bugs activated during initialization, 97.6% stop or disrupt normal execution. In contrast, 90.0% of the 20 initialization- activated advisory vulnerabilities are High or Critical. Module-level code and package initialization activate 98.3% of the analyzed history cases. Dynamic loading is much less common, but most of its cases perform security-sensitive actions. We also find that many fixes change when an import becomes active instead of removing the dependency. Finally, we derive ImportVulBench, 228 paired pre-fix and fixed programs covering all 11 bug types.

Sun 13 SeptCryptography and Security
The gist
Python imports don’t just bring in code—they actually run code when loading modules, which can cause bugs and security problems even before your program starts doing its main work. The authors studied many cases where these import-time actions caused failures or vulnerabilities, finding that nearly all bugs disrupted normal execution and many vulnerabilities were severe. They also showed that developers often fix these problems by changing when imports happen rather than removing dependencies. The authors provide a dataset of real bug fixes to help improve tools that find or prevent these issues.
Open → 2609.14791v1

Model context protocol servers face silent endpoint changes risks

Same Name, Different Server: A Security Census of Silent Drift in the Model Context Protocol Ecosystem

Abstract: The Model Context Protocol (MCP) has become the common interface through which large language model applications reach external tools, and its public registry now distributes thousands of community-built servers with little of the vetting infrastructure that mature package ecosystems have accumulated. This paper reports a census of that ecosystem. We harvested the full public MCP registry (21,643 servers, 72,606 version records, August 2026 snapshot), fetched source code for 14,353 servers, and applied a pattern-based scanner covering an eight-class threat catalogue whose accuracy we measured against 414 hand-labeled findings. Observed prevalence is dominated by unauthenticated network exposure (9.57% of scanned servers); after correcting each class by its measured precision, 11.14% observed high-severity prevalence reduces to roughly 7.6%. The central finding concerns instability rather than any single weakness: 51.1% of multi-version servers changed what they advertise between versions, 40.6% did so silently, and 4.2% redirected their remote endpoint to a different host while keeping their registry identity, a change the protocol never surfaces to installed clients. Silent drift is associated with nearly threefold higher odds of a high-severity finding (OR = 2.96, 95% CI [2.56, 3.42]). Popularity offers only weak protection (OR = 0.78 per unit of log stars), so star counts are a poor proxy for safety. We derive concrete recommendations for registry design, client-side pinning, and scanner triage, and release an anonymized artifact.

Sat 12 SeptCryptography and SecuritySoftware Engineering
The gist
Large language model applications use many external tools registered in a public directory. The authors found that over half of these tools frequently change their advertised addresses without warning, sometimes redirecting traffic to new hosts silently. These hidden changes make the tools almost three times more likely to have serious security problems. They also show that popularity ratings don’t reliably indicate safety. The researchers suggest ways to improve registry design and client protections.
Open → 2609.14119v1

TyPatch improves Linux kernel bug detection using patch-based typestate rules

TyPatch: Transforming Patches into Typestate Rules for Kernel Bug Detection

Abstract: Historical Linux kernel patches capture defect knowledge that applies beyond their original repair sites. Recent work has shown that large language models (LLMs) can generate static-analysis checkers from historical patches and use them to uncover new kernel bugs. However, complete-checker generation requires the model both to recover the defect semantics expressed by a patch and to implement sophisticated program-analysis machinery, including object tracking, alias analysis, path-state maintenance, and interprocedural propagation. Coupling these responsibilities in a single end-to-end code-generation task can turn a simple defect rule into an unstable and expensive analyzer-implementation problem. To address this problem, we present TyPatch, which decouples patch-specific defect semantics from analyzer implementation. An LLM translates each patch into a typestate rule specifying its tracked object, actions, guards, transitions, and violations. A shared backend then executes these rules, binding their actions to program events, tracking object identity across aliases, propagating typestate along program paths, and producing reports for all rules. On Linux v6.16, TyPatch finds 559 distinct bugs, 121 of which have been confirmed by kernel developers. In a matched 38-patch comparison with the state-of-the-art complete-checker construction workflow, TyPatch uses 88.3-90.1% fewer generation tokens, while its initial report pools achieve 3.42-14.95$\times$ the precision of those produced by that workflow.

Sat 12 SeptSoftware EngineeringArtificial IntelligenceCryptography and Security
The gist
Detecting bugs in the Linux kernel is hard because some bugs involve complex interactions within the code. The authors created TyPatch, a tool that turns past bug fixes into clear rules about how objects in the code should behave. Instead of building big, complicated checkers for each bug, TyPatch separates the bug knowledge from the checking process. This approach helps find many bugs more efficiently and with fewer mistakes than previous methods.
Open → 2609.13728v1

Forecasting future security risks in open source software dependencies

PatchRisk: Forecasting Future Vulnerability Exposure in Open-Source Dependency Networks

Abstract: Open-source software ecosystems are web-scale dependency networks. A downstream package can become exposed to security risk not because its own source code changes, but because one of its transitive dependencies later receives a vulnerability advisory. Existing vulnerability-detection work often focuses on whether code is currently vulnerable or whether a known vulnerable dependency is already present. We study a different problem: future transitive vulnerability exposure. Given a package-version dependency graph observed at release time, the task is to predict whether any non-root dependency will receive a vulnerability advisory within a future horizon. This problem is important for Web intelligence and software supply-chain security because it supports proactive dependency triage before future exposure is visible. It is also easy to evaluate incorrectly: current vulnerable dependencies can leak the label, and different versions of the same root package can create package-level memorization across train and test splits. We therefore construct PatchRisk, a leakage-aware benchmark from Open Source Vulnerability advisories and deps.dev dependency graphs for npm and PyPI. The benchmark uses filtration-aware labels, package-disjoint evaluation, temporal testing, and nested 1K, 3K, 5K, and 10K sampling scales. The largest cleaned setting contains 9,007 root package-version graphs spanning 4,157 root packages. We evaluate three feature families: TimeOnly, GraphStruct, and HistoryGraph. On the 10K temporal-test benchmark, HistoryGraph improves AUPRC over the strongest TimeOnly baseline from 0.351 to 0.640 for 90-day forecasting and from 0.473 to 0.813 for 365-day forecasting. The improvement remains stable across smaller scales and package-group shuffle robustness tests.

Sat 12 SeptCryptography and SecuritySoftware Engineering
The gist
Software projects often rely on other software packages to work properly. Sometimes, those packages can have security problems that are not obvious right away. This paper studies how to predict if any of these dependent packages might get security warnings in the future, even before those problems appear. The authors created a special test set to avoid mistakes when predicting and developed new methods that improve forecasting accuracy. This helps developers prepare and reduce risks before vulnerabilities actually show up.
Open → 2609.13719v1

Hieronym improves function naming in stripped binary code

Hieronym: Leveraging Hierarchical Multi-Source Information for Function Renaming in Stripped Binary

Abstract: Function renaming in stripped binaries can substantially assist reverse engineers by improving code readability, yet it is a challenging task. The difficulty stems from the need to accurately capture function semantics from low-level binary code across diverse instruction sets, architectures, and compiler optimizations, and to express these semantics in concise, human-readable names. Existing approaches either inadequately capture comprehensive function semantics or exhibit limited generalization to previously unseen binaries. In this paper, we present Hieronym, a generative large language model (LLM)-based framework for stripped binary function renaming. Hieronym adopts a hierarchical summarization-driven domain adaptation strategy and integrates multi-source information, including global binary context, local calling context, and intrinsic function semantics, to enhance the LLM's understanding of binary code. To enable systematic evaluation, we further propose a dual-layer evaluation framework that incorporates both token-level and whole-name-level metrics. We evaluate Hieronym on binary functions compiled with four compiler optimization levels (O0-O3) for four architectures (x64, x86, ARM, and MIPS). Experimental results demonstrate that Hieronym significantly outperforms state-of-the-art methods, achieving token-level improvements of 50.12% in precision, 41.75% in recall, and 45.10% in F1-score, as well as a 79.94% improvement in name-level accuracy, while also exhibiting strong generalization capability. Moreover, experiments on real-world malware samples further validate the practical effectiveness of Hieronym in security-critical scenarios.

Fri 11 SeptSoftware Engineering
The gist
Stripped binaries remove helpful function names to protect or reduce programs, making it hard for people to understand the code. Hieronym is a new tool that uses a large language model to suggest accurate and readable names for these functions by combining different information sources from the program. It works well across several computer architectures and optimization levels, making reverse engineering easier and more reliable. The authors also tested Hieronym on real malware, showing it can help in security situations.
Open → 2609.12457v1

Dataset reveals security flaws in AI generated C and C++ code

LLMVul: A Vulnerability-Labeled Dataset of LLM-Generated C/C++ Functions from Real Production Repositories

Abstract: Large language models (LLMs) are increasingly used to generate and assist with software development, yet existing vulnerability datasets largely focus on human-written code or controlled prompting environments. This limits the ability to study security weaknesses in LLM-generated code as it appears in real-world software projects. We present LLMVul, a vulnerability-labeled dataset of LLM-generated C/C++ functions mined from real production repositories. We mine AI-assisted development activity from GitHub over a 4 year period, from November 13, 2022 to September 3, 2026, using provenance signals such as commit metadata and AI-related authorship evidence. After filtering and deduplication, LLMVul contains 21,430 unique C/C++ functions from 226 repositories, together with repository, commit, function, provenance, and AI-tool metadata. We establish vulnerability labels using an ensemble of complementary static-analysis and pattern-based techniques and assign Common Weakness Enumeration (CWE) categories to confirmed vulnerable functions. To assess labeling reliability, we additionally conduct independent manual annotation and measure inter-rater agreement using Cohen's kappa ($k=0.79$). LLMVul contains 1,540 ensemble-vulnerable functions spanning 17 unique CWE categories, providing substantially more real-world LLM-generated vulnerable C/C++ functions than existing vulnerability-oriented LLM code benchmarks. By preserving both code-level vulnerability labels and generation/provenance metadata, LLMVul enables reproducible research on vulnerability detection, security evaluation of LLM-generated code, and analysis of vulnerability patterns in AI-assisted software development. The LLMVul dataset is publicly available at https://doi.org/10.5281/zenodo.22668216.

Thu 10 SeptSoftware Engineering
The gist
Software developers increasingly use AI tools to write code, but the security risks of AI-generated code are not well understood. The authors created LLMVul, a large collection of real-world C and C++ functions written by AI from public software projects, labeled with known security problems. This dataset helps to identify common mistakes AI makes and supports better detection of vulnerabilities in AI-assisted coding. They verified the labels by combining automatic analysis with human review to ensure accuracy. LLMVul is publicly available to support safer AI-powered software development.
Open → 2609.10945v1

A2A protocol security flaws exposed through systematic analysis

A2ABreak: Systematic Security Analysis of the A2A Protocol

Abstract: The Agent2Agent (A2A) protocol, now governed by the Linux Foundation, is an open standard that enables autonomous AI agents to discover, authenticate with, and delegate tasks to one another across organizational boundaries. Designed to complement the Model Context Protocol (MCP) for tool integration, A2A is rapidly emerging as the horizontal communication layer of the multi-agent ecosystem. Yet the protocol's security has received no systematic analysis. This paper presents A2ABreak, the first rigorous systematic security analysis of the A2A protocol. We introduce a novel framework that utilizes an LLM-assisted extraction of a verified finite-state machine directly from the natural-language specification, producing a unified model of 37 states and 76 transitions from 929 formalized statements, and then systematically reasons over this model to discover protocol-level vulnerabilities through adversarial verification, under a full-compliance assumption. Our analysis uncovers 11 new vulnerabilities, each exploitable by a specification-compliant adversary without requiring any implementation flaw. Among the findings are cross-client context injection through unprotected context identifiers, credential harvesting via multi-hop identity loss in delegation chains, and data exfiltration through rogue agents advertising unattested capability claims. A2ABreak achieves 73.3% precision and 84.6% F1 against independent expert review, while a zero-shot LLM baseline operating over the same specification produces zero confirmed findings, demonstrating that explicit formal grounding is essential for sound protocol security analysis.

Wed 9 SeptCryptography and SecuritySoftware Engineering
The gist
The Agent2Agent protocol lets AI agents talk and share tasks safely, but its security had never been fully checked. The authors created a detailed model from its written rules using AI help, then tested it for weaknesses. They found 11 security problems that could be used by attackers following the rules, such as stealing credentials or injecting false data. Their method was much better than using AI alone, showing that formally analyzing the protocol is crucial for finding hidden risks.
Open → 2609.10871v1

Static code checks miss many exploitable vulnerabilities in Python code

Beyond Static Guarantees: Measuring the Static-Pass Dynamic-Fail Gap in Security-Sensitive and LLM-Generated Python Code

Abstract: Advances in large language models (LLMs) fuel the quest for scalable methods to assess the security of generated and security-sensitive software. Static analysis is widely adopted as a scalable, reproducible, and inexpensive security gate, but cannot directly observe runtime exploit behaviour. Vulnerabilities dependent on adversarial inputs, execution context, or exploit chaining may evade static checks while remaining exploitable in practice, yet passing static analysis is often treated as evidence of secure behaviour. This paper introduces the Static-Pass Dynamic-Fail (SPDF) phenomenon and a three-stage agentic pipeline combining static scanning, LLM-driven Common Weakness Enumeration (CWE) reasoning, and autonomous exploit verification in isolated Docker containers. We evaluate 1,355 Python samples from SecurityEval, RedCode, and CyberNative datasets. Of the 654 samples producing no findings under the composite Bandit-Semgrep gate, the LLM detection stage identified 394 candidate vulnerabilities across 235 files. Dynamic verification confirmed or partially confirmed exploitability in 95 files, yielding an inclusive pipeline rate of 14.53% (roughly 1 in 7 statically clean samples). This rate represents the proportion of Bandit-Semgrep-clean samples for which the pipeline identified a candidate vulnerability and obtained runtime evidence supporting exploitability. Outcomes varied by dataset: among candidate file--CWE pairs, confirmed exploitability was 33.7% for RedCode, 28.6% for CyberNative, and 5.4% for SecurityEval. Several frequently confirmed classes, including CWE-338 and CWE-916, were flagged by neither Bandit nor Semgrep. These findings indicate that static-analysis success and runtime security are hierarchical layers of software assurance rather than interchangeable measures, and have the potential to reshape how AI-generated and security-sensitive code is evaluated.

Wed 9 SeptCryptography and SecurityArtificial IntelligenceSoftware Engineering
The gist
Static code analyzers, tools that scan software before it runs, often miss vulnerabilities that only show up during execution. The authors studied Python code, including AI-generated samples, and found that many pieces of software passing static checks still had real security problems when tested in action. They created a system combining static scans, AI reasoning about common weaknesses, and live testing to find these hidden issues. Their results suggest that passing static analysis does not guarantee real-world security.
Open → 2609.10762v1

Coding agent trajectory watermarking detects edits and proves ownership

TrajMark: Ownership Attribution and Segment-Level Tamper Localization for Coding-Agent Trajectories

Abstract: Watermarking the final patch produced by a coding agent provides provenance evidence for the submitted artifact, but does not authenticate the visible process that produced it. Behavioral watermarking methods primarily provide a global detection or identifier-recovery signal, so a locally edited trajectory may retain sufficient ownership evidence without revealing which protected region has become inconsistent. To address this limitation, we propose TrajMark, a training-free, symmetric-key, visible-only trajectory watermarking framework that separates robust ownership attribution from fragile local integrity verification. Our framework consists of two complementary layers: a sparse owner layer that encodes a six-bit deployment identifier by rewriting a keyed subset of naturally occurring READ actions into masked linear equations, and a localization layer that inserts linked Q12 ordinary, group, and terminal seals to commit to protected critical-action segments. This separation allows ownership evidence to accumulate robustly across trajectories, while local modifications perturb nearby keyed commitments and expose the affected protocol region. We further provide a design-level analysis of owner recoverability, integrity collision probability, structural overhead, and localization behavior. Across three coding-agent frameworks and three LLMs, TrajMark recovers the exact owner in all evaluated clean full-watermark batches. Under exhaustive eligible single-site attacks it detects 95.5%-100% of edits, and under random single-action corruption it localizes 95.8% of modified sites to an accepted protocol region rather than to the individual action. Owner marking adds no trajectory actions; the integrity layer adds explicit read-only seals, and matched Pass@1 is 26.9% versus 26.3% for unwatermarked runs.

Wed 9 SeptCryptography and SecuritySoftware Engineering
The gist
When software agents write code, it's important to prove who created the final work and to tell if someone changed parts of the process. The authors propose TrajMark, a system that adds hidden marks to the agent’s sequence of actions to identify the owner and to flag exactly where changes were made. This system doesn’t need special training and doesn’t add extra steps to making code. Their tests showed it can reliably find the owner and detect or locate modifications in the process.
Open → 2609.10416v1

Llms improve cost-efficient large-scale software vulnerability detection

Towards Scalable and Cost-Efficient Vulnerability Detection: A Study on Automatic Query Generation

Abstract: Static analysis remains a cornerstone of software security, yet the effectiveness of tools such as CodeQL is often limited by the substantial manual effort required to develop high-coverage query suites. While large language models (LLMs) have emerged as a potential solution for automated code reasoning, their practical utility in generating structured, executable security queries remains underexplored. In this paper, we conduct an empirical study to evaluate the ability of LLMs to synthesize CodeQL queries using vulnerability data from the National Vulnerability Database. Through this investigation, we explore the potential of using LLMs as an automatic CodeQL query generator. Subsequently, we systematically evaluate the performance of various LLM architectures across a diverse set of real-world vulnerabilities, measuring their ability to improve detection coverage and precision. Our findings reveal that LLM-generated queries significantly enhance the baseline CodeQL queries, yielding 82% improvement in average F1-score. Furthermore, we provide a detailed cost- benefit analysis showing that while direct LLM-based scanning of entire repositories is often computationally and financially prohibitive, leveraging LLMs to synthesize CodeQL queries offers a scalable and cost-effective alternative for large-scale vulnerability detection. Our results suggest that LLMs can effectively bridge the gap between unstructured vulnerability reports and formal static analysis specifications, offering a scalable path toward comprehensive automated vulnerability detection.

Wed 9 SeptSoftware EngineeringCryptography and Security
The gist
Finding software problems automatically is important but takes a lot of manual work. The authors studied how large language models (LLMs), which learn from lots of text, can write computer code queries to help find these problems. They showed that queries created by LLMs detect vulnerabilities better and cheaper than traditional ways. However, scanning whole codebases directly with LLMs is costly, so using LLMs to make queries is a practical middle step. This shows a promising way to make security tools smarter and more efficient.
Open → 2609.10412v1

ReDoS vulnerabilities grow and detection tools often disagree

An Empirical Analysis of ReDoS Vulnerabilities and ReDoS Detection Tools

Abstract: ReDoS vulnerabilities are a type of denial of service software weakness that occurs when a regex is used to validate user-supplied input. In some cases, the regex matching process can take exponential time, leading to a denial of service. In this study, we examine and compare the effectiveness of five publicly-available regex detection tools, and one regex correction tool, using three datasets. We further perform an empirical analysis of all ReDoS vulnerabilities reported to the NVD database in order to understand how they differ from non-ReDoS vulnerabilities and glean insights about this type of weakness. We find that ReDoS vulnerabilities are becoming more prevalent and are much more likely to be exploited than non-ReDoS vulnerabilities. We further find that detection tools exhibit substantial disagreement on whether or not a given regex is vulnerable.

Wed 9 SeptCryptography and Security
The gist
ReDoS vulnerabilities happen when a special search pattern called a regex takes a very long time to check bad input, causing websites or services to slow down or stop. The authors studied several tools that try to find these slow regexes and found that the tools often disagree about which ones are risky. They also looked at real cases from a security database and found that ReDoS problems are becoming more common and are more likely to be attacked than other problems. This shows that spotting these vulnerabilities is important but still challenging.
Open → 2609.10294v1

AgentAudit evaluates trustworthiness of AI agents across all steps

AgentAudit: An Open, Extensible Framework for Full-Lifecycle Trust Evaluation of AI Agents

Abstract: Existing evaluation frameworks mostly assess only one part of AI agents, such as task completion (AgentBench) or security robustness (AgentDojo, ASB), rather than the complete pipeline of planning, tool selection, tool execution, memory and reasoning. Failures can occur at any stage, yet existing benchmarks rarely identify their precise source. AgentAudit evaluates the entire execution trace across ten capability, grounding, security and behavioural dimensions, namely instruction integrity, planner, memory, tool selection, tool invocation, tool correctness, alignment, tool faithfulness, security and execution integrity, combined with behavioural classification and failure attribution to pinpoint the exact stage responsible for an observed failure. AgentAudit can evaluate any LLM-based AI agent, since it attaches to the agent instead of replacing it. It reads only the recorded execution trace and does not interfere with how the agent runs, so it places no constraint on the agent's internal implementation. We evaluate five language models (OpenAI GPT-5, Claude Sonnet 5, Sarvam 105B, Llama 3.3 70B and Gemini 2.5 Flash) across nine capability and adversarial tasks. Claude Sonnet 5 and GPT-5 obtain the highest mean Composite Trust Scores (95.1 and 80.6 out of 100, respectively), while Sarvam 105B, Llama 3.3 70B and Gemini 2.5 Flash trail substantially (57.6, 45.7 and 22.6). All traces were scored by a single fixed judge model, which was itself one of the evaluated models, a limitation discussed in Section VII.E. More importantly, models with similar task-completion behaviour can diverge sharply in trustworthiness, as several non-frontier models are repeatedly classified Unsafe_Compliance on adversarial tasks rather than merely failing them, a distinction that pass/fail benchmarks cannot surface.

Wed 9 SeptArtificial Intelligence
The gist
AI agents perform complex tasks through multiple steps like planning, using tools, and reasoning, but most tests only check if they finish the job, not how trustworthy each step is. The authors created AgentAudit, a tool that watches every step in how an AI agent works and checks if it behaves correctly, safely, and as intended. This tool can work with any AI that uses large language models without changing the AI itself. By testing several popular AI models, they found differences in how trustworthy these agents are, even when task completion seemed similar.
Open → 2609.09875v1

Code generation guardrails struggle to block malware requests effectively

CS-Guard: Benchmarking LLM Guardrails for Code Generation Security

Abstract: Large language models (LLMs) have been ex- ploited to generate malware, but the effective- ness of guardrails for code generation secu- rity remains unclear. We introduce CS-Guard, the first benchmark to systematically evalu- ate guardrails for code generation security. It covers 1) text-to-code generation with 1000 high-quality malware-generation prompts, 7 jailbreak attacks, and a novel fictional scenario attack (FSA) that embeds malicious intent in a legitimate fictional software-development sce- nario; and 2) code-to-code generation with 331 code prompts spanning code infilling, code completion, and code translation. We empiri- cally evaluate 9 guardrails across seven LLMs. We find that current guardrails perform poorly against malicious code-generation re- quests: for text-to-code, the average attack success rate (ASR) after jailbreaks reaches about 50% for many guardrails; for code-to- code, average ASR approaches 100% on base LLMs and remains high across many guardrails (14.4% to nearly 100%). Our FSA also achieves ASR close to 100% across many guardrails, raising major reliability concerns for real-world software development. To sup- port future research, CS-Guard uses a modular three-layer guardrail taxonomy that lets devel- opers register guardrails for evaluation. We release the benchmark and data to enable fur- ther community evaluation.

Wed 9 SeptCryptography and SecurityArtificial Intelligence
The gist
Large language models can produce harmful computer code when asked, but it is unclear how well safety controls, called guardrails, prevent this. The authors created a new test called CS-Guard to measure how good these guardrails are at stopping malware code generation. They found that many guardrails often fail, letting dangerous code slip through half the time or more. They also showed some new clever ways to trick these controls, raising concerns for using these models safely in software development.
Open → 2609.09798v1

LLM framework improves automated vehicle software weakness detection

LLMSec-AV: A Vulnerability Taxonomy and LLM-Driven Software Weakness Discovery Framework for Autonomous Vehicles

Abstract: Automated vehicles rely on millions of lines of safety-critical software, yet general-purpose analyzers do not understand which code can affect vehicle motion. This study asks whether large language models (LLMs) with explicit automated-vehicle (AV) security knowledge improve weakness detection beyond rule-based tools. We developed an AV vulnerability taxonomy with 18 weakness classes from vulnerability records, security advisories, and AV-security literature, and integrated it into LLM-based Security Analysis for Automated Vehicles (LLMSec-AV). Evaluated on Autoware, the framework decomposed 770 translation units into 4,673 functions and analyzed 161 functions under four prompting conditions involving taxonomy context, retrieval from 374 prior disclosures, and multi-step analysis. Findings were compared with 46 weakness locations mined from upstream fixes and a flag-volume-matched permutation baseline. CodeQL, Semgrep, cppcheck, and the Clang Static Analyzer evaluated the same code, with AV-specific rules added to CodeQL and Semgrep. Generated fuzzing harnesses were tested using AFL++ and sanitizers. LLM conditions recovered up to 76% of the 46 known weakness locations, outperforming conventional analyzers. CodeQL, Semgrep, and the Clang Static Analyzer matched none, while cppcheck matched one despite 1,301 alerts. Unaided prompting achieved similar detection performance, showing that the taxonomy did not drive recall. However, taxonomy context increased the share of findings assigned to a weakness class from near zero to over 80%, improving interpretability and triage. Six of the 18 classes could not be directly represented as static-analysis rules. LLMSec-AV introduces an AV-specific, machine-readable vulnerability taxonomy for weakness discovery and shows that LLMs can complement conventional analyzers by identifying and organizing safety-relevant findings in real AV software.

Tue 8 SeptCryptography and Security
The gist
Automated vehicles use complex software that must be safe and secure, but existing tools struggle to find dangerous bugs related to vehicle movement. The authors created a way to categorize types of vehicle software weaknesses and used large language models (LLMs) to better spot these weaknesses in real vehicle code. Their approach found many known problems that traditional tools missed and helped organize the findings to make them easier to understand and fix. This shows that combining vehicle-specific knowledge with LLMs can make security checks for automated cars more effective.
Open → 2609.09386v1

Software supply chain security needs unified risk measurement methods

Measuring the Security of the Evolving Software Supply Chain: a Research Agenda

Abstract: Software supply chain security has become increasingly critical due to the widespread reliance on third-party dependencies and the growing attack surface of modern software ecosystems. However, existing quantitative, measurement-based analysis and vulnerability management approaches remain largely fragmented and ecosystem-specific, limiting their ability to provide comparable risk assessments across environments. This paper presents a structured research plan, starting with a Systematization of Knowledge (SoK) to synthesize the current state of research and identify key gaps, highlighting the limitations in dependency modeling and vulnerability propagation analysis, particularly in the treatment of transitive dependencies and their real-world exploitability. Based on these insights, we argue for a unified measurement perspective capable of consistently representing and analyzing the cross-ecosystem dependency structure. We further identify emerging challenges introduced by AI-assisted software development, where coding LLMs are likely to contribute to new dependency patterns that are not captured by traditional Software Composition Analysis (SCA) tools. These shifts motivate a rethink of dependency modeling to account for evolving software-generation practices and their long-term structural impact on software security.

Tue 8 SeptCryptography and SecuritySoftware Engineering
The gist
Modern software relies heavily on code from many other sources, creating a complex web of dependencies that can have hidden security problems. The authors find that current tools to measure risks in these software supply chains don't work well across different software ecosystems and often miss how vulnerabilities spread, especially in indirect dependencies. They suggest a unified way to measure and understand these connections more consistently. Also, they point out that new ways to write code using AI tools may introduce new types of dependencies that existing security checks don't catch.
Open → 2609.08810v1

Authorization state complexity affects language agent permission decisions

ResidualAuth: What Authorization State Must Language Agents Preserve under Revocable Delegation?

Abstract: Tool-using language agents can delegate and revoke permissions while acting through external services. We show that two authorization histories can have identical current permissions and identical all-pairs reachability yet require opposite decisions after the same direct-edge revocation. We formalize the information needed to preserve such distinctions as a residual authorization state. We prove that exponentially many future-distinct states can share one fixed transitive closure, and give exact or tight asymptotic bounds on the state required by an exact monitor as delegation redundancy varies. ResidualAuth compiles these constructions into paired language-agent episodes. Across four open-weight models, a fixed 256-token summary solved 0-2/16 pairs, sham reads solved 0/16, and authenticated current-query reads solved 15-16/16. In a separate held-out online-memory diagnostic, exact ledger serializations fit all 128 four-coordinate pairs at both 768 and 1,024 tokens. At either cap, factually supported model-written memories sufficient for every prespecified continuation solved at most 1/128 pairs per model. A hard gate reduced eight observed unauthorized effects to zero without changing the preceding attempts. These results distinguish required authorization state, usable decision information, online state maintenance, and effect mediation.

Tue 8 SeptArtificial IntelligenceCryptography and Security
The gist
When AI language agents use tools that require permissions, figuring out which prior permissions and revocations they must remember is tricky. The authors show that two seemingly identical permission setups can lead to very different decisions after a permission is revoked. They define a new way to measure what information about past permissions needs to be kept to make correct decisions. They tested this with language models and found that some ways of summarizing past permissions fail, while including authenticated records helped models make better decisions.
Open → 2609.08062v1

Llm agents benchmarked on assessing software supply chain vulnerabilities

VEX-Bench: Benchmarking LLM Agents for Assessing Exploitability of Software Supply Chain Vulnerabilities

Abstract: The software supply chain has become an increasingly exposed attack surface because of its reliance on intricate yet fragile dependencies. Existing defenses such as GitHub Dependabot often raise many false alerts because their coarse-grained matching cannot determine whether a vulnerable dependency is actually exploitable. Security analysts typically spend substantial time assessing vulnerability exploitability case by case. Recent LLM agents have emerged as promising candidates for this task given their advanced capabilities in coding and cybersecurity, yet no existing benchmark evaluates them on it. Prior benchmarks target zero-day settings, where agents detect and exploit previously unknown vulnerabilities. In contrast, software supply chain security focuses on how known vulnerabilities in upstream dependencies affect downstream projects. This requires agents to reason across repositories and determine whether an upstream vulnerability is exploitable in the downstream project. To address this gap, we introduce VEX-Bench, the first benchmark for evaluating LLM agents' ability to assess the exploitability of software supply chain vulnerabilities. It contains 75 real-world cases mined from GitHub and labeled by security experts, covering Python, Java, and Go. We evaluate nine models across three agent harnesses. While GPT-5.5 and Claude Opus 4.6 reach approximately 80% F1 on binary vulnerability-status classification, only GPT-5.5 surpasses 70% macro-F1 on fine-grained justification classification. This gap highlights the challenge of moving beyond binary exploitability assessment to identifying fine-grained exploitability reasons. Code and data: https://github.com/steven1518/vex-bench

Mon 7 SeptCryptography and SecurityMachine LearningSoftware Engineering
The gist
Software projects depend on other software packages, but some of those packages can have security problems that might be exploited by hackers. Figuring out if these vulnerabilities can actually be used to attack a project is hard and usually done manually. The authors created VEX-Bench, a test set that measures how well large language model agents can decide if a known vulnerability in a dependency can affect a project. They tested several models and found that while some do well at saying if a vulnerability is exploitable, fewer can explain in detail why. This helps highlight the challenges in automating this important security task.
Open → 2609.08040v1

Co evolutionary learning defends language agents from hidden attacks

CoRL: Co-Evolutionary Reinforcement Learning for Adaptive Indirect Prompt-Injection Attacks and Defenses

Abstract: Tool-augmented language agents are vulnerable to indirect prompt injection (IPI). Unlike direct prompt injection, IPI hides adversarial instructions in untrusted tool outputs and can covertly alter the execution of a legitimate task. Defenses trained on fixed attacks may fail as an attacker changes its strategy, injection site, and payload. To address this problem, we formulate adaptive IPI as an asymmetric, partially observable, general-sum Markov game: a multi-turn attacker adapts payloads at reached tool-return sites from the public trajectory, while a tool-using defender must block the injected objective and complete the user task. We propose CoRL, a verifier-grounded co-evolution and repair framework with three stages: Attacker SFT initializes multi-turn attacks from successful trajectories; bilateral Co-PPO jointly trains both agents with role-specific rewards and historical opponent populations; and Defender SFT consolidates verifier-accepted teacher repairs for population-discovered failures. Across 1,514 clean, fixed-template, and adaptive executions per defender, CoRL reduces overall ASR by 38.5 points to 0.0% and raises utility by 13.1 points to 76.3%. Stage-wise and controlled ablations show positive contributions from online Co-PPO and population-mined repair, while external-benchmark evaluation indicates transfer in attack resistance. The defender balances safety and task utility under the evaluated attacks, while the retained attackers provide candidates for adaptive red-team evaluation.

Mon 7 SeptMachine Learning
The gist
Language agents that use external tools can be tricked by hidden instructions inside the tools' outputs, which changes what the agent does without obvious signs. The authors study this problem as a game between an attacker and a defender, where the attacker adapts its hidden messages and the defender tries to block them while completing the tasks. They develop CoRL, a three-step method that trains both attacker and defender together and improves defense over fixed attacks. Their experiments show CoRL stops nearly all attacks and keeps the agents working well. This approach also helps create better adaptive tests for these defenses.
Open → 2609.07529v1

Multiple security patches often needed to fully fix software flaws

One Is Not Enough: The Untold Story of Multiple Security Patches for One Vulnerability

Abstract: Security patches (SPs) are the main mechanism for fixing software vulnerabilities, yet a single vulnerability is not always resolved by a single patch: fixes may be completed incrementally, propagated across maintained branches, or replicated across related repositories. When patch records are incomplete, downstream users may observe only part of the required fix set and therefore apply only partial patching. However, comprehensive patch discovery remains difficult because the prevalence and causes of the multi-SP phenomenon are still poorly understood. In this paper, we present the first large-scale empirical study of multi-SP vulnerabilities. By merging four major vulnerability databases, we construct a dataset of 6,053 multi-SP CVEs with 16,260 SPs, showing that 20.6% of CVEs with patches involve multiple SPs and that merging databases increases recognized multi-SP CVE counts by 36-55% over any single source. We further analyze why a vulnerability is associated with multiple SPs and derive a two-level taxonomy with 6 categories and 16 sub-categories. Based on these findings, we develop SPectre, a taxonomy-driven prototype for comprehensive patch discovery. On 300 multi-SP CVEs, after manually verifying ground-truth SPs, SPectre improves multi-SP patch coverage over representative patch localization baselines, achieving 0.927 recall on same-repository cases and 0.873 recall on cross-repository cases after manual ground truth verification. On 100 recent CVEs recorded as single-patch by all public databases, SPectre further discovers 28 previously unreported SPs across 20 CVEs. Our results show that multi-SP vulnerabilities are both prevalent and systematically underreported, motivating stronger patch-completeness awareness, improved vulnerability database curation, and relation-aware security tooling.

Mon 7 SeptSoftware EngineeringCryptography and Security
The gist
Sometimes fixing a security problem in software requires more than one update, but people don’t always realize this. The authors studied thousands of vulnerabilities and found that over 20% needed multiple patches. They also created a new method to better find all the patches needed to fully fix a problem. This can help software teams avoid missing important fixes and protect users better.
Open → 2609.07224v1