For a few years, buying security AI meant picking a model — one large, general system to scan code, triage alerts, and answer questions. That era is ending. In a single week of July 2026, three of the biggest names in technology shipped cybersecurity AI that works nothing like a single general model: Cisco released tiny open-weight models that only locate bugs, Microsoft launched a specialized model wired into an agentic remediation system, and Google put out a lightweight model that autonomously verifies and patches vulnerabilities. The business question is no longer which model. It is which model for which task — a decision worth getting right, with vendor-neutral AI strategy behind it.
Cybersecurity AI is splitting into three tiers: small local models, specialized frontier models, and agentic systems that verify and patch. No single model wins every task. Choose by the job — locating a bug, confirming it, or fixing it — and by code privacy, false-positive rate, cost per scan, sandboxing, auditability, and human review. The biggest line is capability: some tools only find vulnerabilities, while others generate and apply the patch.
One Model Is Over: Small, Frontier, and Agentic
The shift is from one general model to a system that routes work across model classes. Three shapes are emerging, and each fits a different job. Small models are compact and cheap enough to run on your own hardware, ideal for scanning code at volume. Frontier models are large and specialized, built to top the hardest security benchmarks. Agentic systems chain models together to reason, act, and remediate at machine speed, with a human in the loop.
No single class wins. A small model that runs locally protects your source code but only points at a problem. A frontier model catches what smaller ones miss but costs more per scan. An agentic system can fix a bug end to end, but a system that acts on your code needs the tightest controls of all. Picking well means matching the class to the task, not standardizing on one tool — the same discipline behind a sound AI Bill of Materials.
Three July Launches, Three Different Jobs
The July 2026 launches make the split concrete, and each occupies a different point on the map.
Cisco Antares — small, local, locate-only. On July 21, 2026, Cisco released Antares, a family of open-weight security small language models — Antares-350M and Antares-1B — on Hugging Face under an Apache 2.0 license. According to Cisco, they are purpose-built to pinpoint where known vulnerabilities exist in a codebase, and they are compact enough to run locally, so sensitive source never leaves your environment. Cisco positions them for vulnerability localization specifically, not code generation or patching. This is the privacy-first, high-volume triage tool.
Microsoft MAI-Cyber-1-Flash — specialized and benchmark-topping. On July 27, 2026, Microsoft introduced MAI-Cyber-1-Flash, which it describes as its first model built specifically for cybersecurity, inside MDASH, a multi-agent identification and remediation system. Microsoft reports that pairing the model with GPT-5.4 scored 95.95 percent on the CyberGym benchmark — which measures generating working proof-of-concept exploits for known vulnerabilities — versus roughly 83 percent for the competing models it named. Microsoft also claims the pairing delivers that performance at about half the cost of leading models, and says the model passed AI Red Team and outside review. Its agentic layer, Project Perception, enters public preview August 3, 2026.
Google Gemini 3.5 Flash Cyber — agentic, sandboxed, and patching. Also on July 21, 2026, Google introduced Gemini 3.5 Flash Cyber, a lightweight model built for security work. Per Google, inside its CodeMender agent the model autonomously builds exploit code to confirm a vulnerability in a sandbox, then automatically generates a patch. Google reports it found 55 confirmed unique bugs in Chrome's V8 engine, ten of which other models missed. Notably, Google is gating it — an initial limited-access pilot for governments and trusted partners — citing the dual-use risk of a model that can write working exploits.
| Criterion | Why it matters | What to check |
|---|---|---|
| Task fit | Small, frontier, and agentic models do different jobs | The model class matches the task |
| Code and data privacy | Some scans send your source code to a cloud | Whether it runs locally or off-site |
| Benchmark relevance | Vendor scores use their test, not your stack | If the benchmark reflects your code |
| False positives | Noisy findings burn out your analysts | Real-world precision, not the demo |
| Cost per scan | Frontier calls add up across a large codebase | Price per repository, not per token |
| Sandboxing | Some models run exploit code to confirm a bug | That exploits stay in isolation |
| Auditability | You must prove what the model found and did | A traceable log of every action |
| Human review | Machine speed is wrong for irreversible fixes | Where a person signs off |
| Locate vs patch | Finding a bug and fixing it carry different risk | Whether it only finds or also patches |
Locate the Bug, or Also Fix It?
The single most important line in this market runs between models that find vulnerabilities and models that fix them. Cisco's Antares deliberately stops at localization: it tells you where a known weakness lives. Google's Gemini 3.5 Flash Cyber, inside CodeMender, goes all the way — it confirms the bug by building an exploit in a sandbox, then writes a patch. Those are different products with different risk profiles, and buying one when you needed the other is a costly mistake.
A tool that only locates is safe to run widely; the worst it does is cry wolf. A tool that generates and applies patches is powerful and dangerous — an automated fix pushed to production without review can break more than it repairs. Google's own decision to restrict access to a model that writes exploits is the tell. If you adopt a patching system, you need sandboxing so exploit code stays isolated, and a human sign-off before any fix ships. Google DeepMind's description of Gemini 3.5 Flash Cyber is explicit that the model verifies in a sandbox — treat that as the minimum bar, not a bonus feature.
Benchmarks Are Marketing Until You Map Them
Every vendor in this space leads with a benchmark, and every benchmark is run by the vendor. Microsoft's 95.95 percent on CyberGym and Google's 55 bugs in V8 are real claims worth noting — but they measure the vendor's chosen test, not your codebase. CyberGym rewards generating exploits for known vulnerabilities; if your real risk is misconfigured cloud infrastructure, that score tells you little. The business skill is not reading the benchmark. It is asking whether the benchmark resembles your stack.
Two numbers matter more than any leaderboard: false positives and cost per scan. A model that flags a hundred issues where three are real does not save analyst time — it burns it. And a frontier model priced per token can cost more to run across a large repository than the vulnerabilities it finds are worth. Before adopting any security model, ITECS tests it against a slice of your real code, measures its precision and its true cost per scan, and checks it against the broader AI-enabled app inventory so you know exactly what is running where.
- 01
Classify
Sort the task: triage a codebase, confirm a bug, or generate a fix.
- 02
Match
Route to the right model class: small and local, frontier, or agentic.
- 03
Sandbox
Isolate any model that runs exploit code or can touch production.
- 04
Review
Put a human on every patch before it ships, and log what ran.
Your Security-AI Model Selection Checklist
Choosing a security model comes down to a short set of questions. ITECS runs this before adopting any tool.
Match the model to the task. Use small local models for high-volume triage, frontier models for the hardest analysis, and agentic systems only where you want action, not just findings.
Protect your code and data. Prefer models that run in your environment when the source is sensitive, and know exactly what leaves your network on every scan.
Judge the benchmark by your stack. Treat vendor scores as marketing until you confirm the test resembles your code and the threats you actually face.
Measure false positives and cost per scan. Test on a slice of your own repository, and price the model per repository scanned, not per token in a demo.
Sandbox anything that runs exploit code. If a model builds or executes proof-of-concept exploits, isolate it so nothing escapes into production.
Demand auditability and human review. Require a traceable log of what the model found and did, and put a person between any generated patch and your live systems.
How ITECS Selects and Governs Your Security Models
The security-AI market now moves in weekly launches, and no single model is the answer. ITECS is vendor-neutral by design: we do not sell you a model, we help you choose and govern the right ones. We map your security tasks, match each to the appropriate small, frontier, or agentic model, sandbox the ones that run exploits, and put human review and audit logging around anything that can change your code. It is the same governance discipline we apply to agentic AI infrastructure and to building an emergency stop for any autonomous agent that can act on your systems.
We price this the way we price all advisory work — hourly consulting or prepaid retainer hours with tracked usage, no monthly minimum and no expiration, plus a flat fee for a scoped security-AI selection and governance build. The payoff is simple: the right model on each task, sensitive code kept where it belongs, and no automated fix reaching production without a human's sign-off. We begin every engagement with a data and AI readiness audit. When you are ready to pick the right models for security, talk to the ITECS team.
Buying security AI by the model? Let's pick the right one for each task. Learn about our AI Consulting service or schedule a free AI assessment.
About The Author
The ITECS Team
ITECS helps Dallas business leaders adopt practical AI with the security, documentation, training, and operational discipline expected from an established managed technology partner.
Sources And Trust Signals
This article is based on ITECS implementation experience and the public resources below.
Cisco's July 21, 2026 introduction of Antares-350M and Antares-1B, small open-weight models on Hugging Face built to locate known vulnerabilities and run locally.
Coverage of Microsoft's July 27, 2026 launch of MAI-Cyber-1-Flash, its CyberGym benchmark and cost claims, and the MDASH remediation system behind Project Perception.
Reporting on MAI-Cyber-1-Flash and Project Perception, Microsoft's agentic security system entering public preview August 3, 2026.
Google's July 21, 2026 post on Gemini 3.5 Flash Cyber and CodeMender, which builds exploits in a sandbox to confirm bugs and generates patches, offered through a gated pilot.
ITECS vendor-neutral AI consulting that selects, routes, and governs security models by task rather than selling a single tool.
ITECS audit that tests a security model against a slice of your real code and inventories what runs where before you adopt it.
