Blog

Cisco Released Antares: Within Hours I Had 3 FlowAgents Running On It, Finding, Fixing, & Reporting Vulnerabilities

Head of AI & Developer Relations

Key Takeaways

- Cisco released Antares, an open-weight, 1-billion-parameter model fine-tuned to find Common Weakness Enumerations (CWEs) in code, and it was registered and running in the Itential Platform within hours.
- Antares finds the vulnerability. It doesn’t fix it, report it, or govern the change, so three purpose-built FlowAgents were built around it: one to find, one to fix, one to report.
- Any model, cloud-hosted or running locally, becomes usable the moment it’s registered in the Itential model registry, with RBAC controlling who can reach it. No SDK, no vendor integration work, no months-long roadmap item.
- The three FlowAgents are the probabilistic pieces. The Git actions, agent handoffs, and approval gate around them run deterministically, and no agent commits to a repository unsupervised.
- Every model runs locally through Ollama and a local Itential Gateway. Zero cloud calls, zero token costs, zero data leaving the environment, which matters most for regulated industries that can’t use public cloud models.
- The workflow itself was generated, tested, and deployed using Itential Builder Skills in Claude Code, spec-driven from end-to-end, not hand-coded.
- Two live runs, CWE-78 (OS command injection) and CWE-502 (deserialization of untrusted data), were found and patched in seconds.

A few days ago, Cisco released Antares. An open-weight, 1-billion-parameter small language model, fine-tuned specifically to find Common Weakness Enumerations (CWEs) in code. Not CVEs on a router or switch. Weaknesses in the Python you and your team are writing every day.

It should have made more noise than it did.

By the time most people finish reading Cisco’s announcement, I’d already registered Antares in the Itential Platform, paired it with two more open-weight models, and had it finding and fixing real vulnerabilities in a real Git repository. Locally, privately, for free, on my MacBook.

Here’s how, and why it matters a lot more than one clever demo.

Finding a Weakness Isn’t the Same as Fixing It

Most of us who moved into network automation with Python didn’t come up as software security engineers. We’re comfortable writing the code. We’re a lot less comfortable knowing whether that code has a common weakness sitting in it.

Antares closes half that gap. Give it a Git repository and a CWE number and description, and it will scan the codebase and tell you exactly where the weakness lives. That’s real, and it’s useful.

💡 Finding the vulnerability isn’t the job.
Fixing it is. Reporting it is. Making sure a human approves the change before it ships is. Antares was never built to do any of that, and it shouldn’t have to be.

That’s where the platform comes in.

Bring Your Own Model: Same Day, No Waiting

The first thing I did with Antares was register it in the Itential Platform’s FlowAI model registry, I added Antares, alongside Qwen3-Coder-30B (a model fine-tuned on code) and Gemma 4 (a model that’s very good with language), pointed each at my local Ollama instance, and turned on the specific models I wanted exposed with RBAC controlling who could reach them.

That’s the whole integration. No SDK to wait on. No vendor partnership to negotiate. No months-long roadmap item. A model shipped days ago was reachable by an agent, governed by the same access controls as every other capability on the platform, the same day.

That’s what time to value actually looks like. Any model, cloud-hosted or running locally on a laptop, becomes usable the moment it’s registered. Next month it might not be Antares. It might be whatever model ships next, from whatever vendor ships it. The registry doesn’t care. Neither does the workflow.

The platform doesn’t lock you to one model, one vendor, or one release cycle. It gives you a place to plug in the next one.

💡The platform doesn’t lock you to one model, one vendor, or one release cycle.
It gives you a place to plug in the next one.

Three Agents, One Platform, No Sprawl

Antares finds the weakness. It stops there by design. So I gave the finding to a second agent, running Qwen3-Coder-30B, an 18GB model that runs comfortably on a Mac through Ollama. It doesn’t suggest a fix. It writes one.

Then a third agent, running Gemma 4, picks up the finished work and closes the loop with the humans who need to know: summarizing what was found, what changed, and communicating it out over email or Slack.

Three agents. Three specialized models, each doing the one thing it’s actually good at. It would be easy for that to turn into three unmanaged tools bolted together with duct tape and hope. It doesn’t, because these aren’t three separate tools.

They’re three FlowAgents, coordinated inside one Itential workflow, under one orchestration model.

Agent sprawl is the next script sprawl. Governed orchestration is how you avoid it.

Agents Reason, The Workflow Runs

Here’s the part I want security and compliance teams to sit with. The three agents in this workflow are the probabilistic pieces. Everything around them, the Git actions, the handoffs between agents, the approval gate before anything gets pushed, runs deterministically.

No agent commits to a repository unsupervised. When the fixer agent finishes its work, the proposed change surfaces in the Itential Work Center for human review. Someone looks at the vulnerability, the proposed fix, and the reasoning, and approves it before anything ships.

That’s the same governance model that applies to every other action on the Itential Platform, whether a human triggers it or an agent does. RBAC, approval gates, and an audit trail don’t change depending on who, or what, is asking.

AI adds reasoning. Itential adds the guardrails.

Zero Cloud Calls, Zero Token Costs, Zero Data Leaving the Building

Every model in this workflow runs locally through Ollama, connected to a local Itential Gateway, connected to the Itential Platform in a private environment. There is no external communication. No tokens billed per call. No customer code or vulnerability data ever leaves the environment it lives in.

For a lot of industries, that’s not a nice-to-have. It’s the requirement that’s kept them out of agentic AI entirely. Healthcare, finance, government, defense, manufacturing: organizations that want the productivity of agentic AI but can’t put their code, their data, or their infrastructure anywhere near a public cloud model.

Your data stays where it lives. What runs on your platform stays on your platform.

Built With a Spec, Not Hand-Coded

One more thing worth being direct about: I didn’t hand-build this workflow. I described what I wanted, three agents that needed to pass work between each other, and Itential Builder Skills in Claude Code generated, tested, and deployed the workflow, spec-driven from end-to-end. My job was adding a run-agent step, a variable, and a merge-data step where the builder skill told me to.

That’s the same story as our time-to-value message everywhere else on the platform: describe intent, get a working workflow, in minutes, not months. It just happens to be the story here too, applied to a brand-new model from a vendor most people haven’t started paying attention to yet.

Spec in. Workflow out.

Two Live Runs, Not a Slide

In the full walkthrough, I run this end-to-end twice, live, on camera. CWE-78, OS command injection, found in a repository using popen, rewritten to use subprocess, and approved through the Work Center in seconds. Then CWE-502, deserialization of untrusted data, found and patched the same way, just as fast.

Two different weaknesses. Same three agents. Same governed workflow. Same result: seconds, not sprints.

Watch the Full Walkthrough

The full video runs about 20 minutes and covers the architecture end to end: the model registry, the FlowAI agents, the deterministic workflow steps, the Work Center approval, and both live CWE runs.

Share it with your CISO and your security team. Share it with your software developers, and with whoever on your team is hacking away at Python without a security background to lean on. Every model that ships from here forward, from Cisco or anyone else, is a candidate for the same treatment: registered, governed, and put to work, the same week it’s released.

Imagine a CWE-free world. That’s not a slogan. That’s a workflow you can run today.

Let’s Build the Next One Together

This is what happens when a new open-weight model drops and you’ve already got the platform to put it to work. I’ll keep doing this every time a model like Antares shows up, and I want to build the next one with you, not just show it to you.

▶️ Join me live: Choose Your Model, Not Your Vendor – August 25 at 12:00 PM

I’m doing a live demo with Joksan Flores on running FlowAgents on any LLM: open weight, proprietary, or something your team built in-house. Same idea as this Antares walkthrough, just the full picture: swapping models behind an agent with zero rebuild, same governance underneath no matter which model’s reasoning. Register here. Can’t make it live? register anyway and they’ll send the recording.

💬 Come talk shop in the VibeOps Forum.

It’s free, open, practitioner-led, and it’s where I hang out when I’m not on a MacBook wiring up local models. Bring your ideas, your CWEs, your worst YAML story, whatever. Join the Slack space.

🔌 Connect with me on LinkedIn.

Keep up with what’s next. And tell me what to build. Seriously. What model just dropped that you want to see wired into a governed FlowAgent? What’s the workflow you wish existed? Find me here.

I’m building in the open, and I’d rather build the thing you actually need.

See you in the Forum.

John Capobianco

John Capobianco is the Head of AI & Developer Relations at Itential, and a technology leader, developer advocate, and builder at the intersection of AI and network automation. With a career spanning enterprise, government, and cloud networking, John has held roles including Head of Developer Relations at Selector AI, where he focused on AI-driven observability, configuration intelligence, and autonomous network operations, as well as Cisco AI Technical Leader and Senior Network Architect for the Parliament of Canada / House of Commons. He brings deep, hands-on experience applying automation and AI in highly regulated, mission-critical environments. His work centers on helping large organizations adopt AI safely while maintaining reliability, security, and operational trust. John is a former professor at St. Lawrence College, an author, speaker, and educator. He is the author of Automate Your Network (self-published, 2019) and the Cisco Press pyATS book (2024). He regularly shares insights through talks, workshops, and the Automate Your Network brand, with a focus on practical, production-ready AI, developer empowerment, and the evolution of network engineering in an AI-first world.

Keep Learning