Artificial Intelligence

The Safest AI May Be the One That Knows When to Stop

Cisco built a small AI to find known vulnerabilities in code — and it worked, competing with models many times its size. Then testers asked it a harder question: is there anything left to find? The answer said more about trustworthy AI than the model.

I've been watching Cisco make some interesting moves in AI — most of what gets attention is the big infrastructure and network-level plays.

One of the most revealing moves runs the other direction. While most AI headlines chase ever-larger models, Cisco released Antares: a family of small language models built for one painfully specific job — vulnerability localization.

A vulnerability advisory can tell a security team what weakness it needs to investigate. It doesn't tell them where that weakness lives inside a large, unfamiliar codebase. Anyone who has owned that work knows the feeling — advisories keep arriving, and the team is drowning in triage before anyone even confirms which files are actually at risk.

Somebody still has to search the repository, inspect candidate files, and narrow the investigation to the code most likely to matter. That work takes time, costs money, and demands security expertise that's already in short supply.

Antares helps with that search. Give it a description of a known vulnerability and a body of code, and it ranks the files most likely to contain the weakness, so a human knows where to look first.

Antares is a family, not a single model. Two are open-weight and available now — Antares-350M and Antares-1B — with a larger Antares-3B expected later. All of them can run locally, without sending proprietary code to a cloud service, and they require far less computing power than the general-purpose models most of us associate with AI.

That's a narrow job. It's also a useful one — and it's a bounded one. Antares is not a general chatbot, an autonomous security engineer, a patch validator, or a verdict that software is safe. It helps a person decide where to look first when a vulnerability is already known to apply.

But then someone tried something different

Independent testers reproduced Cisco's results, and the models held up — competing with systems many times their size on the job they were built for.

Then the testers ran a different check. They gave Antares the same kind of repository after the vulnerable code had already been patched. The logic was straightforward: if Antares understood the difference between a real vulnerability and a fixed one, it should recognize there was nothing left to flag.

Antares kept pointing at files anyway — as if the vulnerability were still there.

It knew how to keep searching. It did not reliably know when there was nothing left to find.

Cisco's model team acknowledged the result publicly. Fix verification wasn't the job Antares had been built to perform. The model was designed to answer, "Where should I look?" The patched-code test asked, "Is there anything left to find?" Those questions sound related. They require different judgments.

The danger arrives when a person — or the system surrounding the model — quietly promotes one answer into the other. "Here are the files I'd inspect first" becomes "The vulnerability is here." Or the absence of a convincing result becomes "The repository is safe." The model didn't necessarily make that leap. We did.

The boundary became visible

Here's the part I find most interesting, and it's not really about Antares anymore — it's about how Cisco responded.

Cisco's Vulnerability Localization Benchmark already measured localization and patched-code verification as two separate phases at launch — that structure wasn't new. What was new is that independent testers ran that second phase and published the numbers before Cisco had. Cisco didn't get defensive about it. The company confirmed the gap publicly and said teaching the model to say no is next on its list.

That's a more useful signal than another capability demonstration. Cisco built a narrowly specialized tool, released it as open-weight so outsiders could stress-test it, and then engaged honestly when the test found something the published results hadn't yet shown. Security has always been too broad for any one person to own. Why would we expect one AI to own it?

Security isn't one job — I learned that the hard way

I learned the human version of this lesson through TechWiseTV.

When we started the show in 2006, I was "the security guy." That label made sense when each host had their own technology lane. But security covers a ridiculous amount of territory. The deeper we went into networking, collaboration, wireless, and data centers, the harder it became to pretend that one label described one body of expertise.

Certain subjects pushed me much farther outside what I actually knew. Data centers were one of them. I had built my confidence around network security — that's how I started with TechWiseTV. We'd covered data center technology before, but when Cisco unveiled the Unified Computing System a few years later, we knew the market might reduce it to, "Cisco is getting into the server business." My challenge was explaining the more integrated model Cisco was actually building, and why that distinction mattered. I was starting from scratch. But starting from scratch wasn't the same as pretending.

My co-host, Jimmy Ray Purser, was an engineer's engineer — a savant who could retain and explain technology better than anyone I've ever met. I learned to watch Jimmy Ray's first reaction to something new. He understood things so quickly that, by the time we recorded, the discovery was already old news to him. Part of my job was helping him remember that reaction and recreate it for the audience.

Knowing where my expertise ended didn't make my world smaller. It let me enter much larger rooms without pretending I knew more than I did.

TechWiseTV became more ambitious when Jimmy Ray and I stopped trying to be interchangeable. He could "horse me up" on almost any technology. I could take that understanding all the way to a finished show — shape the story, build the conversation, help experts communicate on camera, and carry it through production.

One of many times that played out was our 2011 walkthrough of Cisco's new Allen, Texas, data center. The story reached beyond servers into networking, power, cooling, resiliency — how the whole facility worked as a system. I couldn't have built that story alone.

Our boundaries didn't constrain the work. They made the work possible. I didn't become more useful by trying to become Jimmy Ray — as if I could. I became more useful when I understood which judgments were mine, which were his, and how to connect the two.

Capability is not authority

We usually evaluate AI by what it can do. How many problems did it solve? How quickly did it respond? How much work did it remove?

Operational authority requires another test: what happens when the system is asked to make a judgment it was never designed to make? Does it keep producing because producing looks like success? Or can it expose the evidence, recognize that the next judgment belongs somewhere else, and escalate?

That becomes urgent the moment an AI agent can change a network route, approve an expense, modify access, respond to an incident, or push code toward production. A plausible answer can be corrected. An unauthorized action creates a blast radius.

Right now, much of AI safety still depends on a skilled human recognizing when the machine has gone over its skis. That may be acceptable for supervised assistance. It is not enough for autonomous authority.

An operational system needs a defined job, evidence behind its recommendation, conditions under which it refuses to continue, and a clear path to someone — or something — with the authority to make the next call. Refusal is not failure when the requested judgment exceeds the system's job.

We should expect the same discipline from the machines we authorize to act.

Intelligence gets attention. Restraint earns authority. The next breakthrough may not be another AI that always has an answer — it may be one that recognizes when the next answer belongs to someone else, and when the right answer is NONE.

Sources

Robb Boyd spent nearly two decades at Cisco as Managing Editor of TechWiseTV — the company's highest-ROI marketing asset, reaching audiences in 65+ countries. Today he spends as much time thinking about how AI is changing the way organizations trust their own people as he does producing video for them — this piece is part of that thinking, done in public.

Want more analysis like this? Subscribe to ExplaiNerds. And if you're a marketing or content leader with a story that deserves a bigger audience — let's talk.