Cheap, Fast, and Local: SLMs Rewire Cybersecurity

Agentic security has grown enormously over the past two years — propelled as much by better harnesses wrapped around models as by the models themselves, and on the offensive side as much as the defensive one.

The default architecture for an agentic security tool, until very recently, was one model doing everything. A single cloud-hosted frontier LLM served simultaneously as the human-computer interface and the orchestrator of every tool call underneath it — parsing the analyst's request, selecting the API, interpreting the output, deciding the next step, all inside one continuously-growing context window.

Here's that failure mode as a recorded event, not a hypothesis. In July 2026, Cisco pointed two models at the same unfamiliar codebase — trailofbits/fickling, a Python pickle-safety library — and asked each to localize a real, disclosed flaw: CVE-2026-22607, an incomplete denylist that let a malicious pickle file slip past the library's own safety checks.

• Antares-3B — a 3-billion-parameter model that spent 14 terminal calls tracing a deprecated compatibility shim back to the actual interpreter and submitted both vulnerable files, for perfect precision and perfect recall;
• GPT-5.5 — reportedly around 9.7 trillion parameters (OpenAI has never confirmed a figure; independent researchers reverse-engineered it from factual-recall performance calibrated against 89 open-weight models of known size) — working the identical repository with a full 15-call budget, stopped one layer short: it flagged a delegation wrapper instead of the file underneath it, for half credit.

The frontier model didn't lose on reasoning. At more than 3,000 times the size, it lost on finishing the trace before its budget ran out — and the small model didn't.

01 Breaking up the Monolith

The argument in this post runs through four movements: (1) where the real capability in agentic security already lives, (2) what breaks when a single model tries to hold an entire multi-step loop, (3) what a shipping architecture built around that lesson looks like, and (4) why the smaller models come out ahead once the advantages actually get tallied.

The Harness, Not the Model

Long-range planning is where this argument actually has to start. DARPA's AI Cyber Challenge (AIxCC) spent two years testing whether autonomous systems could carry a vulnerability from an unfamiliar codebase all the way to a validated patch without a human in the loop, and the improvement curve arrived faster than most expected: finalist Cyber Reasoning Systems identified 86% of the competition's synthetic vulnerabilities in the final scored round, up from 37% at the semifinals eighteen months earlier, and patched 68% of what they found.

That's not one inference call — it's building a model of unfamiliar code, fuzzing or analyzing it for weaknesses, triaging what turns up, synthesizing a fix, and validating that the fix doesn't break anything else, a pipeline that runs for hours unattended.

Microsoft's MDASH, covered in more detail later in this post, makes the same shape explicit as an architecture rather than a competition result: five sequential stages — Prepare, Scan, Validate, Dedupe, Prove — where each stage hands the next its accumulated context instead of starting cold. Long-range planning, in other words, is already the operating norm in agentic cybersecurity, on the offensive testing side and the defensive tooling side alike.

That's not a coincidence, and it isn't really about the model at all. Anthropic's own engineering team found that even a frontier coding model like Opus 4.5, run in a loop with no other scaffolding, falls short of finishing a production-quality build from a single high-level prompt: it either over-commits to too much at once, or a later session looks around, sees partial progress, and declares the job done. What closed the gap wasn't a better model — it was harness engineering: an explicit checklist of 200-plus features marked failing by default, one feature per session, and git commits and progress files so the next session picks up cold instead of guessing.

The same lesson holds on the cyber side, offense and defense both. Cato Networks reported that a harness paired with GPT-5.5 strung together complete attack chains to domain-administrator privileges in as little as 40 minutes, and the researchers' own conclusion was blunt: it's not just about the frontier model. Tenable, Proofpoint, and SpecterOps have each since built a proprietary harness of their own. A recent security architecture, SafeHarness, makes the underlying claim explicit: the execution harness — not the model running inside it — is the system layer that actually orchestrates tool use, context, and state.

The most controlled version of that experiment holds the model fixed and only varies the harness. Mayoral-Vilches et al. ran the same mid-capability model behind five different agent harnesses against a 33-challenge cybersecurity benchmark: the best individual harness solved 15/33, and no single harness dominated — different harnesses failed and succeeded on different challenges even though the model underneath never changed. Letting heterogeneous harnesses run in parallel and exchange findings through a shared blackboard pushed that to 19/33, a 27% relative gain over the best solo harness, achieved 25% faster and at comparable cost. The model was constant throughout; only the harness moved.

From Language Model Agency to Code Agency

Run that same multi-stage plan inside one continuously-growing context window, though, with no harness at all, and a different problem shows up. The single-model, no-harness version of this has a name in the literature — language model agency — and a structural flaw that doesn't show up until you push it into production. As the context window fills with tool outputs, error traces, and multi-turn history, computational cost and time-to-first-token scale quadratically, not linearly.

A model that felt snappy on a three-turn demo becomes unusable on the fifteen-turn incident-response session that real triage actually requires — exactly the workload where real-time responsiveness matters most.

The fix isn't a faster frontier model. It's decoupling the interface from the executor: a dedicated, deterministic controller manages the operational control flow, and specialized language models get invoked as plug-ins for discrete, bounded subtasks — code agency instead of language model agency.

Code Agency, Shipping

Parameter extraction, API schema formatting, code-block parsing: routine, narrow, high-volume work gets handled locally by a small model built for exactly that shape of task. A large generalist model is kept in reserve, invoked selectively and only when the local model actually hits a high-complexity edge case it can't resolve. Cisco's open Foundry Security Spec is one shipping version of that shape, not a sketch — a deterministic Orchestrator routing work across eight specialized roles over a shared layer, covered in more detail later in this post.

That single design choice — a harness that decides what gets routed where — is what the rest of this post keeps coming back to, in three different guises: what it costs to run, how well it performs on a narrow slice of the job, and how tightly its behavior can be bounded and checked.

The Case for Going Small

This post takes that claim apart in two moves: first the architectural shift from a single cloud model doing everything to code that orchestrates a swarm of small, specialized ones, then what these swarms actually do on offense and defense, benchmark by benchmark, not just in theory.

Every argument in this post for going small ultimately cashes out into one of four advantages:

• Computational economics — small models are cheap enough to run constantly. A recent long-horizon reasoning study puts a real number on what that buys: ReFlect found that wrapping models in a deterministic reasoning harness raised SWE-bench patch-structural quality from 0% under direct chain-of-thought — every generated patch malformed, every token spent on it wasted — to 82% to 87% depending on the model underneath, and the harness gain was largest for the weakest models: each percentage point a model lost on its own translated into roughly 1.69 points of harness-driven recovery;
• Contextual specialization — a narrow model beats a broad one on a narrow task. A general-purpose model has to spread its parameter budget across the entire space of things it might be asked to do; a small model fine-tuned on one task, with a grammar-constraint layer on top of it, can devote its entire representational capacity to that one bounded problem. Reports from the field back this up directly: a 3-billion-parameter model with targeted instruction tuning and a constraint layer can execute structured tool calls at a higher success rate than a 70-billion-parameter generalist asked to do the same thing zero-shot. Bigger isn't the same axis as better, once the task is this narrow;
• Operational controllability — a bounded output space is one you can actually audit. A model with a genuinely narrow functional scope has a predictable behavioral envelope — its output space can be strictly bounded, which suppresses conversational drift, cuts formatting hallucinations, and, critically, makes it cheap to re-tune with parameter-efficient fine-tuning (PEFT/LoRA) the moment its behavior needs correcting. You cannot say any of that about a 400-billion-parameter black box you're renting by the token;
• Operational privacy — a model you own never has to ship proprietary data anywhere a rented one would. Defensive deployments in particular cannot risk leaking application source code, network metadata, or database schemas to a third-party cloud API just to get an alert triaged — a data-sovereignty pressure covered in more detail later in this post that, by itself, is pushing local SLMs into the core of the enterprise defensive stack, cost and specialization arguments aside.

02 Small Is Beautiful

"Small Language Model" is, in this literature, an operational category, not a marketing term: decoder-only transformers typically in the 1-to-12-billion-parameter range, with effective configurations occasionally stretching to roughly 20 billion — Mistral-NeMo 12B is the usual upper bound cited — specifically so the model fits inside a single-GPU server's constraints.

What defines the category isn't raw capability; it's optimization for a deployment envelope: latency, infrastructure cost, and the ability to run at the network edge rather than across a distributed cloud cluster. The same logic, pushed to its conclusion, is why the frontier of SLM deployment is drifting on-device — fine-tuned for one job, running on the phone in your pocket, no round-trip to a cloud at all.

Large Language Models sit on the other side of that line by definition — tens or hundreds of billions of parameters, hosted on distributed cloud infrastructure, reached through a commercial API rather than a local weights file. The distinction matters operationally, not just numerically: an SLM is a thing you own, version, and can afford to run on every request; an LLM is a thing you rent, and every request has a marginal cost attached.

Dispelling the Myth of Mythos

The starkest test of the specialization thesis wasn't a benchmark table — it was Anthropic's own flagship model. Claude Mythos, announced in April 2026, autonomously found vulnerabilities that had survived decades of expert review: a 27-year-old signed-integer-overflow bug in OpenBSD's TCP SACK handling that could crash any host answering over TCP, and a 17-year-old remote-code-execution flaw in FreeBSD's NFS stack (CVE-2026-4747) that handed an attacker root. Anthropic gated access behind Project Glasswing, an invitation-only consortium that started at eleven organizations before expanding to roughly 150 partners.

Fort himself is careful about what that test actually measured, though: the tests "gave models the vulnerable function directly, often with contextual hints," not a full codebase searched cold, so, in his words, "the models' performance here is an upper bound on what they'd achieve in a fully autonomous scan."

The gap that survived the replication is exactly the one the previous section predicts, not a coincidence: Fort found "excellent sensitivity — 100% detection across all runs — but poor specificity" on patched code. Only the largest of the eight, GPT-OSS-120B, and to a limited degree Qwen3-32B, correctly recognized a fixed version as safe; the rest kept flagging it and fabricating justifications for why. "A model that false-positives on patched code would drown maintainers in noise," as Fort puts it — a precision problem, the same false-positive failure mode the SAST triage table three sections down this post quantifies directly, not a capability ceiling.

That inconsistency has a name too.

Fort calls it the jagged frontier: "There is no stable 'best model for cybersecurity.' The capability frontier is jagged," and "rankings reshuffle completely across tasks."

His own transcript makes the gap concrete. On an OWASP false-positive test tracing tainted data through a Java array, GPT-OSS-20B "correctly traces" the value and "identifies the code as not currently exploitable," while Claude Sonnet 4.5 "confidently mistraces the list," flagging a return value as reachable when, in Fort's words, "it is not."

On the OpenBSD bug, a 5.1-billion-parameter model recovered the full exploit chain, while Qwen3-32B — which had scored perfectly on the FreeBSD bug — declared the same SACK code "robust to such scenarios" and missed it entirely. Same task family, wildly different rankings, and no model held its position across all of them.

AISLE's own conclusion, after finding "15 CVEs in OpenSSL — including 12 out of 12 in a single security release — with bugs dating back 25+ years," using a mixed panel of models where no single vendor consistently outperformed the rest, states the thesis in Fort's own words: "the moat in AI cybersecurity is the system, not the model." It was always the verification harness wrapped around it — which is just the previous section's code agency argument, restated twice now by two different labs. One reaction put it more bluntly: "the defensive layer of Mythos isn't behind the velvet rope. It's on Hugging Face."

His conclusion, after running the same workflow across both paid and open-weight backends, is that vulnerability discovery is an orchestration problem, not a frontier-model problem — the third independent restatement now, and the one that arrives with a working open harness attached. Even Anthropic's own account of Mythos leans on the same logic: a thousand-run scaffold sweep of OpenBSD, or several hundred runs over FFmpeg, rather than a single query to a single model.

XBOW's own read of the post-Mythos landscape pivots the same lesson to the attacker's side of the ledger. Mythos remains the strongest model on their internal ranking, but Muse Spark 1.1 lands just below Opus 4.6 — until recently the best model available for agentic cybersecurity — and GLM performs like a strong closed model from several months ago, at a fraction of the price. An attacker doesn't need the best model in the world, just one that can find a real vulnerability before the cost stops making sense — and that bar keeps getting cheaper to clear.

Small, Not Simple

Standard self-attention scales quadratically with sequence length — a real bottleneck once an agent is chewing through verbose system logs or a multi-file codebase, not a toy sequence. The architectural response has been hybrid sequence-modeling layers that combine attention with alternative primitives, most commonly State Space Models (SSMs), whose cost scales linearly instead.

NVIDIA's Hymba-1.5B is the clearest demonstration: it integrates Mamba-based recurrence with scaled attention heads in the same architecture, reaching roughly 3.5× greater token throughput than a comparably sized pure transformer while outperforming much larger dense models on instruction-following and grammar adherence. The Nemotron-H family (2B, 4.8B, 9B configurations) takes the same hybrid Mamba-Transformer bet further, matching dense 30B-parameter LLM accuracy on instruction-following and code generation at an order of magnitude fewer inference FLOPs.

Grouped Query Attention (GQA) is the other architectural workhorse showing up across nearly every current SLM, Qwen3-4B-Thinking-2507 included, which pairs 32 query heads against just 8 key/value heads. GQA sits between the modeling capacity of full multi-head attention and the inference speed of multi-query attention, and its real payoff is memory: the size of the key-value cache that has to live in accelerator memory scales with the number of KV heads, not query heads, so cutting KV heads from 32 to 8 shrinks the cache proportionally — the difference between a context window that fits on one GPU and one that doesn't. None of these three techniques makes the model simpler — each makes it more architecturally sophisticated specifically so the deployment footprint doesn't have to be.

The Model Roster

Table 1 catalogs the model families that show up repeatedly across the offense and defense benchmarks in the rest of this post — what each one is actually built to do, not just how big it is.

Two families are worth a closer look because they show up on both sides of the offense/defense line later in this post. A third is worth a closer look for a different reason: it's the clearest evidence yet that specialization beats scale outside a benchmark paper, in a shipping product.

• The Qwen3-4B-Thinking line is trained to natively emit visible reasoning steps inside <think></think> tags before it commits to an answer — a small architectural choice with an outsized security payoff, since it means an analyst (or a supervising agent) can inspect the model's intermediate logic before an action executes, rather than trusting a black-box output. On complex reasoning benchmarks it scores 81.3 on AIME25 and 65.8 on GPQA-Diamond, beating many dense 72B models from the previous generation, and hits 71.2 on the Berkeley Function Calling Benchmark v3 — a genuinely strong engine for local tool orchestration at 4 billion parameters.
• Cisco's Foundation-Sec-8B takes the opposite path to specialization: rather than a general reasoning model, it's continued-pretrained from Llama-3.1-8B-Base on 8 billion curated cybersecurity tokens — CVE records, CWE profiles, MITRE ATT&CK techniques, threat-intel reports, product documentation. Its reasoning-tuned companion, Foundation-Sec-8B-Reasoning, is post-trained with supervised fine-tuning and Reinforcement Learning from Verifiable Rewards (RLVR) to instantiate genuine step-by-step reasoning rather than pattern-matching, and on security-specific benchmarks — CTIBench-MCQA, CTI-Reasoning, SecBench — it performs on par with 70B-parameter Llama-3.3-Instruct while clearly outperforming its own non-reasoning predecessor. Cisco has already put the pairing into production rather than leaving it a benchmark result, running Sec-8B as the alert-triage layer inside its own AIPOD SOC platform.
• Google's CodeMender, which entered preview the same week this post went up, is the clearest production instance of the code-agency architecture from earlier in this post. It doesn't run one model end to end — it runs a scan-verify-remediate pipeline: find candidate vulnerabilities, build and execute a proof-of-concept exploit inside an isolated sandbox to confirm the risk is real, then generate a patch and have a second model judge it before a developer ever sees the diff — and routes each phase to whichever model in its stack is sized for that phase. The model doing the routing is the interesting part: Gemini 3.5 Flash Cyber is a cyber-specialized model built on Google's smallest, cheapest tier rather than a frontier flagship, and it found 55 unique vulnerabilities in the V8 JavaScript engine against 47 for standard Gemini 3.5 Flash and just 36 for Claude Opus 4.6 — the same specialization-beats-scale result this section has been arguing from academic benchmarks, now running in a shipping defensive product rather than a paper. Access, for now, is limited to governments and "trusted partners," with broader distribution through the Gemini Enterprise Agent Platform planned later in 2026 — a reminder that the gap between what this literature demonstrates and what a given security team can actually deploy today is still mostly a distribution question, not a capability one.

03 It's the Economy, Stupid

Every comparison this post has made so far — F1, precision, recall, tokens per second — describes model quality. None of it describes what a security budget actually buys, and vendors have every incentive to keep the conversation there instead.

The number that should decide a procurement call is closer to a unit-economics question: what does one confirmed finding cost?

API pricing for the models in this space already differs by two to three orders of magnitude on the same task — GPT-OSS-20B's $0.11 per million tokens against Mythos's reported $25 to $125 for the same unit, a gap wide enough that raw accuracy stops being the deciding variable long before the two systems are anywhere close in quality. The OpenBSD scaffold sweep mentioned one section up puts a real number on what that buys: under $20,000 for a thousand runs and several dozen additional findings — a few hundred dollars per finding, not the tens of thousands the model's own pricing would suggest.

This isn't just an argument this post is making in isolation — the industry is converging on the same metric. Tenzai's autonomous security agent submits validated vulnerabilities to HackerOne at an average cost of $225 each, outperforming more than 125,000 human researchers on the platform by that measure alone.

The inverse failure mode is just as telling: one report found a basic AI scan run against a single 1.8-million-line Java codebase returned 3,560 findings, and at a conservative 30 minutes of triage per finding, clearing that pile would cost roughly $128,000 in labor before a single vulnerability got fixed — proof that raw finding-count is exactly the wrong thing to optimize for. The proposed fix is a small dashboard of derived metrics — time to first validated finding, human minutes per accepted finding, cost per high-impact validated finding — all variations on the same unit-economics question this section keeps returning to.

Revelio makes the specialization argument concrete inside a single pipeline: a cheap model proposes and triages vulnerability hypotheses across an entire repository, tolerating false positives because they get filtered later, and only the small surviving candidate set goes to a stronger model to construct and confirm an executable proof-of-vulnerability. That division finds 175 vulnerabilities on a 100-project benchmark against 55, 39, and 31 for Claude Code, GPT-5.5, and Sorcar respectively — more, not fewer, with zero false positives — and turned up 19 previously unknown vulnerabilities (seven assigned CVEs) in production codebases already fuzzed for years, at roughly $42 per project. Its own conclusion: you don't need access to Mythos to find lots of vulnerabilities.

The same economics cut the other way for attackers. Carlini et al. argue that LLMs collapse a tradeoff attackers used to face between going broad — cheap, shallow attacks on many low-value targets — and deep — expensive, tailored attacks on one high-value target. An LLM that can read and adapt to an arbitrary codebase makes the same kind of tailored attack that used to be reserved for a bank cheap enough to run against a target with a hundred users. In one demonstration, an LLM given no human guidance searched the Enron email corpus on its own and surfaced an executive's affair, sensitive enough to use for targeted blackmail.

Adam Chlipala names the same collapse from the defender's side: security through obscurity was never really about hiding code, it was a bet that nobody could afford to look. That bet held only because finding a bug in some rarely-touched corner of a codebase required scarce, expensive human expertise — "we have lost the old defense that most code isn't economically important enough that its bugs are worth enough to justify the cost of finding them." Once discovery is automated, obscure code stops being cheap to skip and starts being cheap to scan: "if vulnerability discovery can be automated by LLMs instead, it often becomes economical to set them loose on relatively obscure code bases."

Pesoli, Errico, and Cavallaro reframe the whole cost argument a level up: once discovery gets this cheap, the bottleneck stops being how many candidate vulnerabilities a system can generate and becomes how fast a human organization can validate, triage, patch, and ship a fix for each one. Mozilla's Bobby Holley makes the point with real numbers — 271 Mythos-identified Firefox bugs, 180 of them security-high, contributing to 423 total Firefox security bugs fixed in a single month — a volume that strains reviewer and release capacity long before it strains model capacity. Cost per validated vulnerability is the right question for the model; cost per shipped fix is the right one for the organization around it.

04 Cheap, Fast, and Armed

The offensive case for SLMs rests on the same specialization argument as everything above it: general-purpose frontier models are aligned to be broadly conversational, and that alignment introduces semantic noise that degrades performance on precise, low-level technical execution. Train a compact model exclusively on code generation, exploit syntax, and structured tool interaction, and it can outperform a much larger generalist on exactly the narrow task that matters for exploitation.

Offensive Tool Use and Function Calling

On the standard ToolBench evaluation — navigating nested API endpoints and executing real-world functions across multi-turn reasoning chains — a fine-tuned OPT-350M model reaches a 77.55% pass rate, decisively outpacing large general-purpose baselines that struggle with formatting compliance under the same complexity. Salesforce's xLAM-2-8B tells a similar story at slightly larger scale, delivering tool-calling accuracy that outperforms several frontier proprietary models on the same benchmark.

The payoff for an offensive pipeline is speed: an SLM agent running a port scan, reading service banners, and identifying candidate CVEs can parse telemetry, synthesize alternative query parameters, and issue the next diagnostic command in a fraction of a second — fast enough to slip under basic time-based IDS detection thresholds tuned for human-paced reconnaissance.

Knowing Versus Doing

Everything in this section so far assumes a harness, a benchmark built around agentic tool use, or both. Strip both away — no orchestration, minimal tool descriptions, a raw local model against a live target — and a different, more useful signal shows up.

TrustedSec ran six self-hosted models against eight offensive-security challenges spanning four vulnerability classes — SQL injection, JWT manipulation, path traversal, and authentication bypass — a hundred attempts per model, with deliberately minimal tool descriptions and no agent framework between the model and the target. The point wasn't to flatter any model with scaffolding; it was to measure what the weights alone can do.

Easy challenges landed near-universal — 97 to 100% across the board, no differentiation worth reporting. Medium-difficulty challenges are where the models actually split, and the NULL-byte path-traversal bypass produced the widest spread in the whole benchmark: 37% to 100% pass rate, depending almost entirely on whether a given model's training data happened to cover that specific bypass technique.

The finding underneath the pass rates is sharper than any of them: a model can describe an attack perfectly and still fail to execute it. One model correctly explained how an IDOR vulnerability works, then never actually changed the target ID in its own requests. Across every model tested, multi-step attacks requiring structured data extraction — enumeration, character-by-character boolean exfiltration — scored 0%, a hard floor, not a soft spot. Single-shot payload injection is solved; carrying a plan across several dependent steps isn't, and no amount of parameter count in this size class closed that gap on its own.

That gap is also, on the evidence, close to a measurement gap. A survey of the benchmarking practices across sixteen prior offensive-security LLM papers found that only about a quarter evaluated local or self-hosted models at all, defaulting to GPT-4-class cloud APIs the rest of the time.

The offense side of this post's argument is thinner than the defense side for the same reason the literature is: self-hosted models attacking live targets, with no frontier harness babysitting them, is the less-studied half of the specialization thesis, not a settled one.

It's the same gap Fort found from the defensive side, in different words: open models "reason fluently about whether something is exploitable, what technique to use, and which mitigations fail" — right up until the creative engineering step of actually chaining a working attack together.

Knowing and doing split apart the same way whichever direction you approach the line from.

Multi-Agent Orchestration in Exploitation

A single small model, unsurprisingly, struggles to carry a complex multi-stage exploit end to end from a raw binary — the same scope-limit that made code agency beat language model agency three sections up. The response is that argument's opposite: split the pipeline across four specialized nodes, each running a model sized and tuned for its own narrow slice, with a deterministic controller deciding what flows to which.

No single node holds the entire exploit chain in its context at once — the Analyzer hands off a finding, the Generator hands off a candidate, the Validator hands off a diagnostic trace — and that bounded handoff is what lets models too small to carry the whole chain still compromise targets none of them could crack alone. A Supervisor orchestrates the cycle from outside any single model's context, re-invoking Reflection until a candidate validates or the loop gives up. Chen and colleagues' VulnSage wires exactly this shape together end to end, not as a schematic: 34.6% more exploits than comparable tools across their benchmark, and 146 zero-day vulnerabilities found in production software.

The same underlying pattern shows up again in a completely different domain. ARACNE runs the identical bounded-handoff principle for shell-based pentesting instead of binary exploitation, under its own role names: a Planner (GPT-o3-mini) handles strategic decision-making, an Interpreter (LLaMA 3.1) translates each planned step into an executable bash command, an optional Summarizer (GPT-4o) compresses context to preserve token budget, and an Organizer — the controller, not a model — manages the SSH connection and routes messages between the three. Four roles, three different underlying models, none doing another's job. On OverTheWire's Bandit wargame it reaches a 57.58% success rate, edging past the prior state of the art, and the architecture is the reason: route the work, don't broaden the model.

Specialization can go deeper than VulnSage's own general-purpose Analyzer, too. Cisco's Antares is a purpose-built, open-weight system for vulnerability localization specifically — trained to pinpoint where in a codebase a weakness actually lives, not merely flag that the codebase contains one somewhere. That distinction — localization versus detection — is exactly what an exploit-generation pipeline's analysis stage benefits from: a scanner that says "this function is unsafe" is a triage tool, but one that says "this function, this line, this tainted argument" hands the next stage something it can act on without a human closing the gap in between.

The same underlying pattern keeps resurfacing regardless of target. Reentrancy in a smart contract is a third domain entirely: a contract executes an external call to an untrusted address before updating its own internal state, a window an attacker exploits by recursively re-invoking the vulnerable function and draining state before the first call ever finishes.

SCALM (Smart Contract Audit Language Model) combines Step-Back Prompting with retrieval-augmented generation to abstract high-level execution principles out of raw Solidity code, and those findings feed into hybrid tools like ReDetect, which pairs an SLM with a graph neural network operating over abstract syntax trees, control-flow graphs, and data-flow graphs to track the precise propagation of tainted inputs across external message calls — producing verified, executable exploit scripts against real target contracts, not just a flagged line number. The same shape, a different target — one more domain where it generalizes.

05 Defense: Triage, Diagnosis, Query

Defensive deployments face a constraint offense doesn't: organizations cannot risk leaking proprietary application code, network metadata, or database schemas to a third-party cloud model just to get an alert triaged. That data-sovereignty pressure alone is pushing local, privacy-preserving SLMs into the core of the enterprise defensive stack, across three distinct workloads: triaging SAST alerts, diagnosing malware, and generating security queries.

The risk isn't hypothetical. Samsung banned generative AI tools company-wide in 2023 after engineers pasted semiconductor fabrication source code — among the most closely guarded trade secrets in the industry — into ChatGPT to help debug it, in three separate incidents within twenty days of the company lifting its own internal ban. A SAST alert's file path, line number, and surrounding code are exactly the kind of proprietary detail that story is about, and the governance gap it exposed hasn't closed: McKinsey's 2026 State of AI Trust survey found that only 33% of enterprises meet governance standards for autonomous agents, while roughly two-thirds still cite security as the top barrier to scaling agentic AI at all.

Triaging the Noise

Static Application Security Testing tools are effective at flagging candidate weaknesses and notoriously bad at telling flagged from real — false-positive rates routinely exceed 90–92%, because a syntactic pattern match has no way to know a path is unreachable, sanitized upstream, or simply benign in execution.

The fix is a local triage agent that receives the flagged alert's metadata — target file, line range, CWE identifier — and uses ordinary tools like grep and jq to trace the actual data-propagation path and check for an upstream sanitization routine before rendering a verdict: false positive, prune the noise, or true positive, escalate to a human. Figure 2 traces one such loop end to end — a CWE-89 SQL-injection alert routed through three tool-assisted evidence steps to a single yes/no question.

Feeding the agent less, not more, is itself the finding, not just an implementation convenience. DeepCode AI Fix ran the comparison directly on vulnerability repair: rather than handing an LLM the entire file, the authors used program analysis to shrink the input down to just the reported defect and the surrounding context actually needed to fix it. That reduction, on its own, let a fine-tuned Mixtral-8x7B remove more than 80% of the reported defects and exactly match the human fix in 10–50% of cases — beating GPT-3.5 and GPT-4 baselines given the unreduced code, and doing it with far less training data besides. A smaller, correctly scoped context wins the same way a smaller, correctly scoped model does.

That one yes/no question is where refusal bias bites hardest: a model that hedges on the benign triage request never even reaches the verdict. Table 3 draws on SastBench, a benchmark purpose-built for agentic SAST triage rather than adapted from a generic vulnerability-detection dataset, and a separate study on sifting false positives from LLM agents reaches the same conclusion from a different angle. The benchmark results are the clearest single data point in this entire post for why refusal bias is a defensive liability, not just an offensive one.

The gap between the aligned and abliterated versions of the same 4B model is the whole argument in one row: recall more than doubles — from 41.50% to 92.10% — once the safety alignment stops treating a benign vulnerability-triage request as something to hedge on. Read against Claude-3.5-Sonnet's cloud numbers, the abliterated local model isn't just "good enough" — it's competitive on F1 while running entirely on-premises. Unaligned general models hit a reasoning ceiling tied to their parameter count on genuinely hard edge cases, but targeted fine-tuning combined with stripping safety alignment lets an SLM match or exceed a much larger cloud model specifically because the task is triage, not open-ended conversation.

Orchestrating the Defense

Automated malware analysis runs a suspicious binary inside an isolated sandbox and produces a dense detonation report — filesystem events, process creations, network socket bindings, memory writes — that a defensive agent then has to interpret, map to MITRE ATT&CK, and summarize as an incident. Individual SLMs reliably struggle to reason over logs this large and this dense on their own; orchestrating them into a collaborative multi-agent architecture is where the real capability shows up.

• Multi-Agent Pipeline — an Evidence Collector Agent runs sandboxed grep/jq searches for indicators of compromise, a Semantic Embedder filters noise by similarity, a Reasoning Agent interprets the condensed evidence, and a Verifier Agent performs a final quality check;
• Adversarial Debate — two agents classify the same binary independently and critique each other's deductions across multiple rounds; on disagreement, a controller injects grounding MITRE ATT&CK technique descriptions into the discussion;
• Hierarchical Consultation — a lightweight generalist orchestrates the execution loop and queries a domain-specialist model (Foundation-Sec-8B, say) only when it hits obscure terminology or protocol formats;
• Grounded Hybrid System — combines evidence collection with adversarial debate, grounding the debate in a verified evidence bundle to suppress the reasoning drift and hallucination that ungrounded conversational exchanges are prone to.

The pattern across all four architectures holds regardless of exactly how the agents are wired together: orchestration beats a solo model every time, and grounding the collaboration in verified evidence beats debate without it.

On CyberSecEval's malware-analysis benchmark — Meta and CrowdStrike's suite, grounded in real sandbox detonation reports — a solo Qwen3-4B-Thinking is actually worse than solo Foundation-Sec-8B (19.80% against 22.54%) — a domain-adapted model beats a general reasoning model on a domain task, unsurprisingly — but wire the same Qwen3-4B into a grounded hybrid loop with Foundation-Sec-8B as its expert consultant, and the pair together clears the accuracy of either one alone, reaching 35.30% — more than twelve points over solo. The absolute accuracy numbers are still modest — this is a genuinely hard task — but the delta between orchestration patterns is the finding that matters.

From Lab to Industrial Scale

The lab-scale version of this finding scaled cleanly into production. Microsoft's MDASH ("Multi-model Agentic Security Hunting") runs the same logic at industrial scale: more than 100 specialized agents split across a deliberately heterogeneous panel of frontier and distilled models, with auditor, debater, and prover roles that reason differently by design, not by accident. Taesoo Kim, the Microsoft VP of Security Research who leads the team behind it, frames the whole system's thesis in one line: the durable advantage in AI-driven vulnerability discovery lies in the agentic system around the model, not any single model — this post's own argument, running in production at 100-agent scale.

Disagreement between them is treated as a signal rather than noise — when an auditor flags a finding the debater can't refute, that finding's credibility goes up. On CyberGym, a 1,507-task real-vulnerability benchmark spanning 188 open-source projects, that ensemble scored 88.45% — ahead of every single-model system on the leaderboard, Claude Mythos included — and had climbed to 96.55% within three weeks. No individual model in the panel is the point; the diversity of reasoning styles across it is.

Both of those numbers were already dated the same week this post was last updated. Microsoft folded a dedicated cybersecurity model, MAI-Cyber-1-Flash — a sparse mixture-of-experts transformer, 137 billion total parameters, 5 billion active, a 256K context window — directly into MDASH: it's built to absorb roughly 90% of routine security work on its own, escalating only the hardest cases to GPT-5.4, and it held MDASH's CyberGym accuracy roughly where it already was at half the compute cost.

Independently, Wiz's Atlas — its own multi-model orchestration system, unrelated to either lab — landed at 90.9% on the same leaderboard while surfacing more than 200 previously unknown flaws in code that's been fuzzed and reviewed for years: the Linux kernel, Kubernetes, gVisor, containerd, dnsmasq, and gRPC among them. Three vendors, three different orchestration schemes, the same specialization-over-scale shape each time. MAI-Cyber-1-Flash's compute column makes the point sharpest: five billion active parameters holding industrial-scale accuracy exactly where it was, at half the cost, isn't a discount substitute for the frontier model it sits behind — it's evidence that small was already enough.

06 A Shared Taxonomy

Cisco has since gone further and formalized the pattern into a named specification. Foundry Security Spec defines eight core agentic roles for security evaluation — Orchestrator, Indexer, Cartographer, Detector, Triager, Validator, Coverage-Guide, and Reporter — each with its own defined inputs, outputs, and functional requirements, deliberately model-agnostic and stack-agnostic about which implementation fills each slot.

The spec's own first user story is the whole argument compressed into one sentence, written from the operator's side rather than the architecture's: as an Operator, "point the system at a target repository and a one-page goals document, run one command, and walk away — so that an evaluation starts without me hand-assembling a pipeline." Everything in Figure 3 — the Orchestrator, the eight roles, the shared Substrate — exists so that sentence can be true. The person running it never touches the routing; they just get to leave.

Map it against MDASH's five stages and the correspondence is almost one-to-one: Indexer and Cartographer do the Preparing, Detector does the Scanning, Validator does the Validating, Coverage-Guide does the Deduping, Reporter does the Proving. What used to be an ad-hoc pipeline design choice is turning into an industry-standard taxonomy of jobs, independent of which model fills each one.

SOC analysts spend a meaningful fraction of their day hunting threats by writing schema-compliant Kusto Query Language queries by hand — specialized syntax that creates a real operational bottleneck, and a natural target for natural-language-to-query automation. Frontier LLMs translate these queries accurately, but routing every query through a cloud API means shipping proprietary internal schema structure off-premises with every request — the same data-sovereignty problem that motivates local SAST triage above.

The answer, per Muzammil et al., is a localized, two-stage "SLM-Oracle" architecture, benchmarked against the NL2KQL dataset Microsoft published for exactly this task. A schema retriever first identifies the relevant telemetry table columns and injects them as hints into the system prompt. A fine-tuned SLM — Gemma-3-4B or DeepSeek Coder 6.7B in the benchmarked configurations, LoRA-tuned with chain-of-thought rationale distilled from a larger teacher — then generates a candidate query using error-aware prompting that accounts for known parser quirks without inflating token counts. In the second stage, a low-cost, schema-aware LLM (Gemini 2.0 Flash, in the paper's setup) acts as an oracle judge, validating and refining the candidate for exact syntax compliance before it ever reaches the analyst.

The two-stage pipeline doesn't just approach GPT-5's cloud-API accuracy — it edges past it on both syntax and semantic correctness, at roughly 15× lower normalized cost and nearly half the latency. The oracle stage is doing real work here, not just window dressing: a raw zero-shot 4B model is close to useless (0.005 semantic accuracy), and even the fine-tuned single-stage models plateau well below what the two-stage combination reaches.

07 Open Questions

Every section above ends on a single number that reads like a resolved argument — an F1 score, a percentage, a multiplier. Numbers like that answer a narrower question than they look like they're answering. Three questions are still open after the benchmarks, and none of them reduces to a topline figure; they're worth pulling apart on their own terms before the conclusions close the post.

How Much Less Do Small Models Detect?

The honest answer is: it depends entirely on the task, not on parameter count alone. On SastBench triage, the gap essentially closes — abliterated Qwen-4B lands at 90.40 F1 against Claude-3.5-Sonnet's 92.93, a 2.5-point gap that a human triage queue would never notice. On CyberSecEval's malware-detonation reasoning task, the gap stays wide: even the best-orchestrated small-model configuration in the defense section tops out at 35.30% accuracy, nowhere near a solved task.

And on the V8 fuzzing result earlier in this post, the gap runs the other way entirely — a specialized small model, Gemini 3.5 Flash Cyber, found more vulnerabilities than a much larger general model, not fewer. "How much less" isn't a fixed tax on being small; it's a property of how well the task rewards narrow specialization over broad reasoning, and this post's own tables argue both directions depending on which one you pick.

The headline gap, in other words, isn't where the interesting question lives — the failure modes underneath it are.

What Are the False Positive and Negative Rates?

Buried inside the SAST triage table's headline F1 score are two very different failure modes. Abliterated Qwen-4B's 92.10% recall means it's still silently missing roughly one real vulnerability in twelve — a false negative, the kind that ships. Its 88.75% precision means roughly one in nine flagged alerts is still noise even after triage — a false positive, the kind that wastes an analyst's morning.

A blended F1 score treats those two errors as interchangeable, and for a defensive tool they plainly aren't: a missed CVE and a wasted hour are not the same cost. Almost none of the benchmarks cited in this post report FP and FN rates separately, or weight them by consequence — which is itself a measurement gap, not just a modeling one.

The NL2KQL section earlier in this post repeated Muzammil et al.'s claim of "up to 10× lower" token cost for the two-stage SLM-Oracle pipeline — but its own table gives GPT-5 at $1.000 and the two-stage system at $0.183, which works out to roughly 5×, not 10×. That gap between a stated multiplier and the number the underlying table actually supports is common enough in this space to be a standing rule: recompute the ratio yourself from the raw row, including the one section up in this very post, before repeating a vendor's or a paper's own efficiency claim.

What Does This Mean for Black-Hat Access to Capability?

This is the question the rest of this post has mostly left implicit. The closed, frontier-grade cyber-specialized models are being deliberately gated by the organizations that built them: Gemini 3.5 Flash Cyber ships only to governments and "trusted partners," and Claude Mythos runs inside Project Glasswing, gated access that started at eleven organizations and has since grown to roughly 150 partners. The open-weight SLM ecosystem this entire post has been arguing for — Foundation-Sec-8B on Ollama, Qwen3-4B-Thinking on Hugging Face, xLAM-2-8B — carries no equivalent gate at all.

Anyone, anywhere, in any jurisdiction, can download the same weights this post cites for defensive triage, and the abliteration technique removes the one behavioral guardrail those weights shipped with — identically, regardless of who's running the download. A single consumer GPU is the only capital requirement. No export-control regime, sanctions list, or usage monitor currently reaches a model file once it's published to a public registry.

This means the cost-efficiency curve this post has spent five sections celebrating is, for an unaligned downstream user, the same curve that makes offensive capability cheaper to acquire than it has ever been.

This isn't a new tension. It's the same export-control debate this blog has covered elsewhere at length, one layer up the stack: every regime built to gate a dual-use capability at a border runs into the same wall once the artifact in question is a file, not a physical good.

08 Conclusions

The open questions in the previous section don't have tidy answers yet — but the benchmarks this post walked through already settle the shape of the answer. The throughline, applied to triage, exploitation, and query generation, is a single reframing: the question was never "how big does the model need to be." It was "how narrow can the task be made, so a model small enough to own, audit, and run on every request can handle it — and how much deterministic scaffolding does it take to make that narrowness actually reliable."

Five findings hold up across every benchmark this post cited, not just one:

• Performance parity is real, not aspirational — GRPO/RLVR post-training and XGrammar-2's structured decoding together let sub-10B local models match or exceed the tool-use, code-generation, and alert-triage accuracy of proprietary APIs an order of magnitude larger, at a fraction of the latency and energy cost. The two-stage SLM-Oracle architecture for NL2KQL is the sharpest single number for that trade: it edges past GPT-5's cloud-API accuracy at roughly 15× lower normalized cost;
• That parity only matters because of the finding that runs underneath it: cost-per-finding is the KPI that actually decides a procurement call. Vendor leaderboards quote F1 and tokens-per-second because those numbers flatter frontier models; Revelio found 175 vulnerabilities at roughly $42 per project against 55, 39, and 31 for Claude Code, GPT-5.5, and Sorcar, and Tenzai submits validated CVEs to HackerOne at $225 each — underperforming more than 125,000 human researchers by no measure except the one nobody else sorts by. The inverse failure is just as telling: 3,560 raw findings against one Java codebase cost roughly $128,000 in triage labor before a single fix shipped. Found-per-dollar, not found-per-benchmark, is where the small models win and the frontier models lose;
• Data sovereignty stopped being a compliance checkbox and became an operational requirement — keeping security intelligence local removes the risk of exposing network topology, intellectual property, and database credentials to a third-party endpoint on every single request;
• The demise of one-size-fits-all safety follows from the same localization: large general-purpose models are conversationally fluent and prone to exactly the refusal bias this post catalogued, while local, task-adapted SLMs can be surgically abliterated to remove refusal pathways while preserving the reasoning structure underneath — a scalpel where alignment-by-RLHF is a blunt instrument;
• Cooperative agent topologies are where the actual capability lives — adversarial debate, hierarchical consultation, grounded evidence pipelines all let individually parameter-bound models correct each other's reasoning errors and deliver reliable output on tasks no single one of them could handle alone.

The future of automated cyber operations does not depend on the continuous expansion of giant, centralized language models. It lies in smart, heterogeneous, localized agentic architectures, where specialized, compact models handle the vast majority of the daily operational workload.

Put in economic terms rather than architectural ones, that whole vision compresses to one comparison: $42 a project beats $128,000 in triage labor, every time, and the gap between those two numbers is what "smart" and "heterogeneous" actually buy you. Everything else in this post is detail.

References

• DARPA. (2025). "AI Cyber Challenge Marks Pivotal Inflection Point for Cyber Defense." Available at: darpa.mil/news
• Anthropic. (2026). "Effective Harnesses for Long-Running Agents." Available at: anthropic.com/engineering
• "How AI Cybersecurity Harnesses Are Reshaping Autonomous Hacking." CyberScoop. Available at: cyberscoop.com
• Tenable. (2026). "Meet Tenable Hexa AI: Agentic AI for Exposure Management." Available at: tenable.com/blog
• Proofpoint. "Proofpoint Satori: Powering Agentic AI Security Operations." Available at: proofpoint.com
• SpecterOps. (2026). "Enterprise-Scale Cyber Ranges for AI Evaluations." Available at: specterops.io
• Lin, X., Liu, Y., et al. (2026). "SafeHarness: Lifecycle-Integrated Security Architecture for LLM-based Agent Deployment." arXiv. Available at: arxiv.org/abs/2604.13630
• Mayoral-Vilches, V., Balassone, F., et al. (2026). "Towards Cybersecurity SuperIntelligence (CSI): What's the Best Harness for Cybersecurity?" arXiv. Available at: arxiv.org/pdf/2605.28334
• "Large Language Models for Cyber Security: A Systematic Literature Review." arXiv. Available at: arxiv.org/abs/2405.04760v4
• Huang, F. (2026). "ReFlect: An Effective Harness System for Complex Long-Horizon LLM Reasoning." arXiv. Available at: arxiv.org/abs/2605.05737v1
• Omri, Y., Gan, Z., Broveak, Z., Geens, R., He, Z., Pentland, A., Verhelst, M., Weissman, T., & Tambe, T. (2026). "Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads." arXiv:2606.06448. Available at: arxiv.org/abs/2606.06448

• Anthropic. (2026). "Assessing Claude Mythos Preview's Cybersecurity Capabilities." Available at: anthropic.com/research
• "The Myth of Claude Mythos Crumbles as Small Open Models Hunt the Same Cybersecurity Bugs Anthropic Showcased." The Decoder. Available at: the-decoder.com
• "The Mythos Moat Was Always the Scaffold." paddo.dev. Available at: paddo.dev
• Fort, S. (2026). "AI Cybersecurity After Mythos: The Jagged Frontier." AISLE, April 7, 2026. Available at: aisle.com/blog
• XBOW. (2026). "Affordable AI Models: GLM, Muse, Spark, and Cybersecurity." Available at: xbow.com/blog
• Kim, T. (2026). "Defense at AI Speed: Microsoft's New Multi-Model Agentic Security System Tops Leading Industry Benchmark." Microsoft Security Blog. Available at: microsoft.com/security/blog
• Nadella, S., et al. (2026). "Rethinking Security for the Age of AI." The Official Microsoft Blog, July 27, 2026. Available at: blogs.microsoft.com
• Wiz. (2026). "Introducing Atlas: Wiz's AI Vulnerability Researcher." Wiz Blog, July 27, 2026. Available at: wiz.io/blog
• Cisco. (2026). "Announcing Foundry Security Spec." Available at: blogs.cisco.com/ai
• Holley, B. (2026). "The Zero-Days Are Numbered." The Mozilla Blog, April 21, 2026. Available at: blog.mozilla.org
• CiscoDevNet. (2026). "Foundry Security Spec — open specification repository." Available at: github.com/CiscoDevNet/foundry-security-spec
• Provos, N. (2026). "Finding Zero-Days with Any Model." Available at: provos.org

• Kaplan, M. (2026). "When Vulnerability Discovery Costs $225, Governance Is the Bottleneck." Available at: mkaplan.substack.com
• "Cost per Validated Vulnerability in Cyber Security." Penligent. Available at: penligent.ai
• "AI Scanning's Hidden Tax: $128K in Triage Before a Fix." CybrSec Media. Available at: cybrsecmedia.com
• Hou, Y., Wang, H., et al. (2026). "Revelio: Cost-Efficient Agentic Memory Safety Vulnerability Detection for Repository-Scale Codebases." arXiv. Available at: arxiv.org/abs/2606.22263
• Carlini, N., Nasr, M., et al. (2025). "LLMs Unlock New Paths to Monetizing Exploits." arXiv. Available at: arxiv.org/abs/2505.11449
• Chlipala, A. (2026). "The End of Security Through Obscurity." Available at: stng.substack.com
• Pesoli, A., Errico, H., Cavallaro, L. (2026). "Demystifying the Mythos or Disrupting Bugonomics? From Zero-Day Asymmetry to Defender Remediation Throughput." arXiv. Available at: arxiv.org/abs/2605.24632

• Cisco. (2026). "Introducing Antares: Highly Efficient Open Weight AI Models for Vulnerability Localization." Available at: blogs.cisco.com/ai
• Vijay, S., Priyanshu, A., et al. (2026). "Antares: Foundation Models for Agentic Vulnerability Localization." Technical Report, Cisco Foundation AI. Available at: cisco-foundation-ai.github.io
• Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł., & Polosukhin, I. (2017). "Attention Is All You Need." Advances in Neural Information Processing Systems 30 (NeurIPS '17). arXiv:1706.03762. Available at: arxiv.org/abs/1706.03762
• Li, B. (2026). "Incompressible Knowledge Probes: Estimating Black-Box LLM Parameter Counts via Factual Capacity." arXiv. Available at: arxiv.org/abs/2604.24827
• "Deep Dive into LLaMa 3." Medium. Available at: medium.com/@zhao_xu
• "FenkoHQ/Foundation-Sec-8B." Ollama. Available at: ollama.com/FenkoHQ/Foundation-Sec-8B
• "Qwen/Qwen3-4B-Thinking-2507." Hugging Face. Available at: huggingface.co/Qwen
• "Llama-3.1-FoundationAI-SecurityLLM-Reasoning-8B Technical Report." arXiv. Available at: arxiv.org/html/2601.21051v1
• "AI-Powered SOC: Cisco Sec-8B and AIPOD in Action." Cisco Live EMEA 2026. Available at: ciscolive.com
• Google Cloud. (2026). "Find and Fix Software Vulnerabilities With CodeMender." Available at: cloud.google.com/blog
• Google DeepMind. (2026). "Introducing Gemini 3.5 Flash Cyber." Available at: deepmind.google/blog
• "Small Language Models (SLMs) Are the Future: Fine-Tuning AI That Runs on Your iPhone." Available at: youtube.com

• "XGrammar-2: Fast and Customizable Structured Generation for Tool Calling and Agents." Available at: blog.mlc.ai
• "XGrammar-2: Efficient Dynamic Structured Generation Engine for Agentic LLMs." arXiv. Available at: arxiv.org/html/2601.04426v2

• Qin, Y., Liang, S., Ye, Y., et al. (2023). "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-World APIs." arXiv (ICLR '24 spotlight). Available at: arxiv.org/abs/2307.16789
• TrustedSec. (2026). "Benchmarking Self-Hosted LLMs for Offensive Security." Available at: trustedsec.com/blog
• Happe, A. & Cito, J. (2025). "Benchmarking Practices in LLM-driven Offensive Security: Testbeds, Metrics, and Experiment Design." arXiv. Available at: arxiv.org/abs/2504.10112
• "Reentrancy Detection in the Age of LLMs." arXiv. Available at: arxiv.org/html/2603.26497v1
• "SCALM: Detecting Bad Practices in Smart Contracts Through LLMs." AAAI Publications. Available at: ojs.aaai.org
• "ReDetect: A Hybrid LLM-GNN Framework for High-Precision Reentrancy Vulnerability Detection in Smart Contracts." Engineering Archive. Available at: engrxiv.org
• "Introducing ARACNE: A New LLM-Based Shell Pentesting Agent." Stratosphere IPS. Available at: stratosphereips.org
• Chen, S., Luo, T., Wu, S., Liu, X., Zhou, Y., Li, Q., & Xu, W. (2026). "VulnSage: A Multi-Agent Framework for Automated Exploit Generation with Constraint-Guided Comprehension and Reflection." arXiv:2604.05130. Available at: arxiv.org/abs/2604.05130

• McKinsey & Company. (2026). "State of AI Trust in 2026: Shifting to the Agentic Era." Available at: mckinsey.com
• "Samsung Engineers Feed Sensitive Data to ChatGPT, Sparking Workplace AI Warnings." Dark Reading. Available at: darkreading.com
• "Sifting the Noise: A Comparative Study of LLM Agents in Vulnerability False Positive Filtering." arXiv. Available at: arxiv.org/html/2601.22952v2
• "SastBench: A Benchmark for Testing Agentic SAST Triage." arXiv. Available at: arxiv.org/pdf/2601.02941
• "SastBench: Agent-Agnostic SAST Triage Benchmark." Emergent Mind. Available at: emergentmind.com
• Berabi, B., Gronskiy, A., Raychev, V., Sivanrupan, G., Chibotaru, V., & Vechev, M. (2024). "DeepCode AI Fix: Fixing Security Vulnerabilities with Large Language Models." arXiv:2402.13291. Available at: arxiv.org/pdf/2402.13291

• Meta AI & CrowdStrike. (2025). "CyberSOCEval: Benchmarking LLM Capabilities for Malware Analysis and Threat Intelligence Reasoning." arXiv, September 2025. Available at: arxiv.org/abs/2509.20166

• Muzammil, S., Reddy, R., Kamalakrishnan, V., Ahmadi, H., & Ul Hassan, W. (2025). "Towards Small Language Models for Security Query Generation in SOC Workflows." arXiv. Available at: arxiv.org/abs/2512.06660
• Tang, X., Abdi, A. H., et al. (2024). "NL2KQL: From Natural Language to Kusto Query." Microsoft. arXiv. Available at: arxiv.org/abs/2404.02933

• "Uncensor Any LLM With Abliteration." Hugging Face. Available at: huggingface.co/blog/mlabonne
• "WTF Are Abliterated Models? Uncensored LLMs Explained." WebDecoy. Available at: webdecoy.com
• "Agentic Misalignment in Summer 2026." Anthropic Alignment Science Blog. Available at: alignment.anthropic.com