# Cisco Antares Guide: Local Vulnerability Localization

> Evaluate Cisco Antares 350M and 1B locally or in CI, interpret VLoc Bench results, and keep localization separate from proof and remediation.

- **Published**: 2026-07-23
- **Category**: AI Infrastructure
- **URL**: https://agentpedia.codes/blog/cisco-antares-vulnerability-localization-guide

---

> **Important callout**

**Bottom line:** Cisco Antares-350M and Antares-1B are small, gated open-weight models that rank source files likely to contain a vulnerability matching a CWE description. Use that ranking to shorten triage, not to declare a vulnerability proven or fixed. Keep software composition analysis, SAST, DAST, secret scanning, exploit validation, regression tests, and expert review in the workflow.

[Cisco introduced Antares](https://blogs.cisco.com/ai/introducing-antares-the-most-efficient-open-weight-ai-models-for-vulnerability-localization) on July 21, 2026. This guide follows the public model cards, technical report, and Cisco's open VLoc Bench repository as they stood on July 23. It explains the trust boundary, reproduces the official evaluation path, and turns the model's file candidates into a reviewable local or CI workflow. AgentPedia did not receive gated model access or reproduce Cisco's scores.

## What Antares does inside a repository

Antares is a terminal-using **vulnerability-localization agent**. Given a CWE identifier and generic category description, it explores a fixed repository snapshot through a read-only command interface, gathers evidence, and submits either a ranked list of source-file paths or "no vulnerability found." The default protocol allows 15 terminal calls.

That is a narrower job than vulnerability detection or remediation. Antares answers, "Which implementation files should an analyst inspect first?" It does not answer, "Can an attacker exploit this exact revision?" or "Is this patch safe to merge?"

The agent loop has four practical stages:

1. **Orient:** inspect the repository structure and likely language or framework boundaries.
2. **Narrow:** search for code patterns associated with the supplied CWE.
3. **Verify candidates:** read likely files and follow nearby imports or call paths.
4. **Submit:** return exact repository-relative file paths, or abstain.

Cisco trained this behavior in two stages. Supervised fine-tuning teaches security reasoning, repository exploration, and the terminal protocol. Group Relative Policy Optimization then rewards complete trajectories for file-level localization quality, valid submissions, compliant tool use, and evidence-gathering behavior. The released checkpoints use IBM Granite 4.0 backbones; they are specialized agents rather than general chat models.

The model and harness are separate components. The model generates reasoning and tool requests. A constrained execution environment decides which commands actually run, truncates observations, enforces the call budget, and records the trace. That separation is why the harness, sandbox, and prompt must be versioned alongside the weights.

## Released models, context, and access

Cisco released two weight repositories and described a larger 3B model in its report. Only the 350M and 1B repositories are available for access requests at the research cutoff.

| Model | Backbone | Declared maximum context | Public status on July 23, 2026 | Practical evaluation role |
| --- | --- | ---: | --- | --- |
| [Antares-350M](https://huggingface.co/fdtn-ai/antares-350m) | IBM Granite 4.0 350M | 32K | Gated open-weight repository; manual approval | Lowest-footprint first pass; compare quality and throughput with 1B |
| [Antares-1B](https://huggingface.co/fdtn-ai/antares-1b) | IBM Granite 4.0 1B | 128K | Gated open-weight repository; manual approval; includes an Antares CLI ZIP | Stronger released checkpoint and the main candidate for a controlled pilot |
| Antares-3B | IBM Granite 4.0 Micro | 128K | Described and benchmarked by Cisco, not released in the supplied collection | Benchmark context only; do not design an integration around unavailable weights |

"Open weight" does not mean anonymous download. Both Hugging Face pages require a signed-in user to share contact information, accept the repository conditions, and pass manual review. Build approval time into a pilot plan, and review the exact license and access terms shown when access is granted.

The 350M card lists repository revision `cdf6d054fa5f491553ccb1704269cbd1954c6c6e`; the 1B card lists `10417eb35641b32e7141157db19c76eb545193b6` at the cutoff. Pinning those revisions makes a rerun attributable to a specific artifact. It does not guarantee identical GPU kernels, driver behavior, or model-server output, so record those too.

The model cards do not publish an official CPU, GGUF, or low-bit quantized deployment path. "Small enough for local use" should therefore be validated on the exact accelerator, precision, concurrency, and context needed by your workflow rather than translated into an unsupported laptop latency claim.

## Localization is not proof or remediation

A useful deployment starts by assigning each tool one job. Antares should sit between vulnerability intelligence and human investigation, not replace the controls around it.

| Workflow question | Primary control | What Antares contributes | What Antares does not establish |
| --- | --- | --- | --- |
| Do we depend on an affected package or version? | SCA, lockfile/SBOM analysis, vendor advisory matching | Can prioritize source areas after the affected component and CWE are known | Dependency reachability, package inventory, or version proof |
| Does source match a known insecure pattern or data flow? | SAST, CodeQL, Semgrep, compiler and framework analyzers | Searches beyond a fixed query and ranks files for review | Rule completeness, sound data flow, exact vulnerable line, or severity |
| Is a secret committed or exposed? | Secret scanning and credential inventory | May encounter relevant files during exploration | Reliable secret detection, revocation, or exposure assessment |
| Is the running application exploitable? | DAST, fuzzing, isolated reproduction, manual exploit validation | Helps narrow where a reproducer or trace should be investigated | Reachability, exploitability, environmental prerequisites, or business impact |
| Is the proposed fix correct? | Code review, regression and security tests, patch comparison | Can be rerun on an immutable patched snapshot as one signal | Patch correctness, absence of regressions, or complete remediation |
| Should CI block the change? | Risk policy combining several verified signals | Adds a reviewable candidate list and terminal trace | A production-ready pass/fail decision by itself |

This boundary also protects against a common language error. A file can be **relevant to a CWE investigation** without containing the root cause. Conversely, the true vulnerable behavior may span entry points, helpers, configuration, generated code, or dependencies that are not represented by one fix file.

> **Warning callout**

Treat repository contents as untrusted input. Comments, documentation, fixtures, filenames, and generated artifacts can contain instructions aimed at a tool-using model. Keep the terminal read-only, disable network access, mount an immutable snapshot, withhold credentials, validate every submitted path, and never let the model turn a candidate into a patch or external action automatically.

For broader controls around repository prompt injection and tool authority, use AgentPedia's [coding-agent security guide](/blog/antigravity-security-guide). GitHub's native quality controls are covered separately in the [GitHub code quality guide](/blog/github-code-quality-ga-guide).

## Cisco's vendor-reported VLoc Bench results

Cisco reports the following Phase A File F1 values on the 500-task Vulnerability Localization Benchmark. These are **Cisco-run, vendor-reported results**, averaged across three runs according to the model cards. AgentPedia did not reproduce them.

| Model | Parameters | Phase A File F1 | Availability | Main caveat |
| --- | ---: | ---: | --- | --- |
| GPT-5.5 (xhigh) | Frontier | 0.229 | Closed | Same standardized harness, but not a local open-weight deployment |
| Antares-3B (GRPO) | 3B | 0.223 | Not released at cutoff | Cannot be independently tested from the supplied model collection |
| GPT-5.5 | Frontier | 0.221 | Closed | Vendor comparison, not evidence of your repository's accuracy |
| **Antares-1B (GRPO)** | **1B** | **0.209** | Gated weights released | Low absolute file overlap; misses remain frequent |
| GLM-5.2 | 753B | 0.186 | Open weight | Size alone is not a controlled predictor of specialization |
| Gemini 3 Pro | Frontier | 0.152 | Closed | Benchmark result does not transfer automatically to another agent harness |
| **Antares-350M (GRPO)** | **350M** | **0.135** | Gated weights released | Lower quality than 1B; benchmark still supports triage, not autonomous conclusions |

File F1 is the harmonic mean of file precision and recall for each task, macro-averaged across the benchmark. A score of 0.209 is not 20.9% vulnerability-detection accuracy. It reflects overlap between submitted paths and the benchmark's fix-derived file labels under one constrained protocol.

The result is interesting because the specialized 1B checkpoint approaches the strongest systems shown by Cisco while remaining much smaller. It is not evidence that Antares "solves" vulnerability detection. Even the highest standardized result is 0.229, and Cisco's report says 192 of 500 entries were solved by none of 32 evaluated external models.

Cisco also reports roughly 11 minutes for the 350M and 13 minutes for the 1B checkpoint to complete its 500-task sweep on one H100 with 16 parallel workers. Those are throughput measurements from Cisco's setup, not single-repository CI latency guarantees. Container setup, repository size, model server, batch scheduling, storage, and trace handling all contribute to end-to-end time.

## What VLoc Bench measures--and misses

[VLoc Bench](https://github.com/cisco-foundation-ai/vulnerability-localization-benchmark) contains 500 tasks from 290 real repositories across npm, pip, Maven, Go, Rust, and Composer. It covers 147 CWE categories; 78% of entries have CVE identifiers. Each task pairs a vulnerable pre-fix snapshot with a patched post-fix snapshot.

The two phases measure different failure modes:

| Phase | Repository state | Expected action | Metric | Operational interpretation |
| --- | --- | --- | --- | --- |
| A | Vulnerable, pre-fix snapshot | Submit affected implementation files | Macro-averaged File F1 | Can the agent narrow a known-vulnerable repository to fix-related files? |
| B | Patched, post-fix snapshot | Submit no vulnerability found | True-negative rate | Can the agent avoid carrying the same CWE hypothesis into a fixed snapshot? |

The released Antares GRPO rows in Cisco's public `model-performance.json` contain Phase A values but no Phase B result. That means the headline released-model comparison does **not** establish a false-positive rate on patched code. Run both phases before considering a gate.

Five benchmark details change how the scores should be read:

1. **The prompt is deliberately sparse.** The standardized task supplies a generic CWE description, not the advisory text, file hints, severity, or crash trace. A real advisory-assisted workflow may provide more context, but then it is no longer the same experiment.
2. **Ground truth comes from fix diffs.** Tests, documentation, and configuration are excluded. A modified implementation file is a useful proxy, not a human-audited line-level proof of root cause.
3. **Ranking is not scored.** The harness accepts ranked paths, but its current `file_f1` implementation converts submitted and ground-truth paths to sets. Moving the correct file from rank five to rank one helps an analyst but leaves File F1 unchanged.
4. **Repository structure drives difficulty.** Cisco reports substantially lower aggregate performance on large and multi-file cases. Severity is not a reliable proxy for localization difficulty.
5. **The harness is part of the result.** Command budget, prompt, output truncation, model endpoint, tool parser, temperature, and parallelism can all change behavior.

The public repository has one launch-day documentation mismatch worth avoiding: an early installation block shows `data/downloader_and_verifier.py --source-dir`, but the released script does not define `--source-dir`. Its implemented interface uses `--workers`, `--resume`, `--manifest`, `--mirror-dir`, and `--output-dir`. The commands below follow the code, not the stale example.

## A reproducible local evaluation

Run this only on repositories and vulnerability data you are authorized to process. The benchmark contains intentionally vulnerable historical snapshots, so use a dedicated host or isolated runner with no path to production credentials.

### 1. Freeze the model and harness

After Cisco approves Hugging Face access, download one checkpoint at the revision recorded above. `HF_TOKEN` must belong to the approved account.

```bash
export ANTARES_MODEL=fdtn-ai/antares-1b
export ANTARES_REV=10417eb35641b32e7141157db19c76eb545193b6

hf download "$ANTARES_MODEL" \
  --revision "$ANTARES_REV" \
  --local-dir /srv/models/antares-1b
```

Pin the benchmark to the reviewed July 23 commit:

```bash
git clone https://github.com/cisco-foundation-ai/vulnerability-localization-benchmark.git
cd vulnerability-localization-benchmark
git checkout 000c19cda9ba027e1d241216768b2b6358685000

python3.11 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e .
```

The benchmark package currently requires Python 3.11 or newer, Docker, `vllm>=0.19`, `transformers>=5.0`, and an OpenAI-compatible model server. Preserve the resolved Python package lock or environment export in your evaluation record.

### 2. Build the no-network sandbox and verify the dataset

```bash
docker build -t vulnerability-localization-benchmark-sandbox .
python data/downloader_and_verifier.py --workers 16
```

The downloader reconstructs both snapshots from exact Git commits, normalizes GitHub archive behavior, repacks flat ZIPs, and verifies deterministic content MD5 values from the manifest. Do not disable verification to save setup time. Review the dataset `NOTICE` and each included repository's license before redistributing snapshots or raw traces.

The default sandbox grants two CPUs and 4 GB of memory per task, sets `network: none`, limits commands to 10 seconds, and starts from a fresh, fixed ZIP-derived repository snapshot behind a strict read-only command allowlist. That interface blocks normal file writes and shell redirection, but the container filesystem and chowned repository are writable; `--permissive` removes the allowlist. Keep strict mode for the first reproduction. For production, use the read-only repository mount or immutable snapshot recommended above rather than treating the benchmark default as filesystem immutability.

### 3. Serve Antares on loopback

```bash
CUDA_VISIBLE_DEVICES=0 python -m vllm.entrypoints.openai.api_server \
  --model /srv/models/antares-1b \
  --served-model-name antares-1b \
  --host 127.0.0.1 \
  --port 8200 \
  --dtype bfloat16 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 32768 \
  --tensor-parallel-size 1 \
  --trust-remote-code
```

Review the downloaded repository before enabling `--trust-remote-code`. Keep the endpoint on loopback unless an authenticated, encrypted proxy and network policy are already in place. The benchmark's Antares runner uses raw `/v1/completions`, not `/v1/chat/completions`, and constructs the model's role and tool-call format itself.

### 4. Smoke-test both phases

Start with ten cases and one worker. This catches missing snapshots, parser errors, OOMs, unsupported commands, malformed submissions, and container cleanup problems without spending a full sweep.

```bash
PYTHONPATH=src python -m vulnerability_localization_benchmark.cli \
  --config configs/default.yaml \
  --api-base http://127.0.0.1:8200/v1 \
  --model-name antares-1b \
  --runner vllm_antares \
  --output-dir results/antares-1b-smoke \
  --phases ab \
  --n-limit 10 \
  --workers 1
```

Inspect every `*_trace.json` before increasing concurrency. Do not use `--permissive` in a production-like pilot merely because the benchmark container has no network; strict command validation is a useful defense against repository prompt injection and unexpected shell behavior.

### 5. Run and preserve the full comparison

```bash
PYTHONPATH=src python -m vulnerability_localization_benchmark.cli \
  --config configs/default.yaml \
  --api-base http://127.0.0.1:8200/v1 \
  --model-name antares-1b \
  --runner vllm_antares \
  --output-dir results/antares-1b-full \
  --phases ab \
  --workers 16 \
  --resume
```

Concurrency 16 matches Cisco's throughput description, but it is not a safe default for every GPU or storage system. Raise workers only after monitoring accelerator memory, queue depth, host memory, container churn, and endpoint errors. Record the checkpoint revision, benchmark commit, container image digest, vLLM and Transformers versions, driver, accelerator, precision, context, worker count, config file, start time, and any retries.

The run writes per-entry scores and full traces plus `aggregate.json`. Preserve them in access-controlled storage: traces can contain proprietary paths and source snippets even when the model endpoint is local.

## How to read the output without fooling yourself

A candidate should enter review only when the path exists in the pinned snapshot and the trace shows repository evidence. Use a compact acceptance record:

| Review field | Required evidence |
| --- | --- |
| Input identity | Repository URL or internal ID, immutable commit, CWE and source advisory |
| Candidate | Exact repository-relative path and model rank |
| Trace quality | Commands used, relevant observations, dead ends, malformed or blocked calls |
| Corroboration | SCA/SAST/DAST result, call-path review, reproducer, or maintainer evidence |
| Analyst decision | Accepted, rejected, duplicate, insufficient evidence, or out of scope |
| Remediation | Separate patch/review/test record; never inferred from localization alone |

Track more than aggregate F1. For an operational pilot, measure:

- top-1 and top-k candidate usefulness, because the benchmark does not score order;
- accepted-candidate precision and known-case recall;
- patched-snapshot false positives;
- hallucinated or nonexistent paths;
- tool-call validation errors and prompt-injection attempts;
- wall time, GPU time, queue delay, and trace-storage cost;
- analyst minutes per accepted finding and per rejected candidate;
- stability across at least three runs on stochastic settings;
- results by language, repository size, CWE, and number of affected files.

A lower-cost model that doubles reviewer time may be a net loss. The useful unit is cost per **accepted, independently verified localization**, not cost per model submission.

## Put Antares in CI without making it the judge

The technical report says the gated Antares CLI can emit human-readable, JSON, and SARIF 2.1.0 output, preview automatically selected CWE categories, and optionally fail on findings. Because the CLI ZIP requires approved access and its command surface could not be inspected for this guide, consult its bundled help and pin the asset hash before automating it; do not invent flags from the report.

Use a staged CI policy:

1. **Shadow mode:** run on a nightly schedule or selected pull requests, upload traces and candidates as restricted artifacts, and never change status checks.
2. **Advisory mode:** create a neutral review annotation only when a candidate is corroborated by another scanner or matches an active advisory/CWE investigation.
3. **Selective gate:** block only for a documented, measured condition such as a previously verified vulnerability reappearing in a known file, with a named security reviewer and override path.
4. **Rollback:** pin model, harness, prompt, taxonomy, and policy versions so one change can be reverted without disabling the rest of the security pipeline.

Keep source checkout and model serving in separate trust zones. The analysis worker should receive an immutable, credential-free snapshot and reach only the approved local inference endpoint. The model server should not have repository write access. The system that converts findings into code-scanning annotations should validate paths, cap artifact size, escape untrusted text, and avoid publishing private source excerpts.

Antares complements the agentic security systems discussed in AgentPedia's [Fugu-Cyber benchmark guide](/blog/fugu-cyber-orchestration-security-benchmarks), but the tasks differ: Antares localizes files from CWE-conditioned repository exploration; Fugu-Cyber's cited evaluations cover vulnerability reproduction and detection-rule generation. Do not compare their headline scores as if they measure one task.

## Production evaluation checklist

### Before the first run

- Obtain approved model access and archive the applicable terms without exposing account details.
- Verify weight, tokenizer, CLI, and harness hashes; scan the artifacts and review any remote model code.
- Use an immutable repository snapshot with no secrets, credentials, writable mounts, or network access.
- Pin the CWE/advisory input, model revision, benchmark commit, server image, prompt, and tool policy.
- Define who can inspect traces and how long source-bearing artifacts are retained.

### Before enabling CI annotations

- Evaluate both vulnerable and patched cases from your own languages and frameworks.
- Include single-file and multi-file vulnerabilities, large repositories, generated code, monorepos, and known negatives.
- Test malicious instructions in comments, docs, fixtures, filenames, and command output.
- Measure ranking usefulness separately from set-based File F1.
- Require an independent evidence path and a qualified reviewer for every accepted candidate.

### Before enabling a gate

- Publish thresholds, exemptions, ownership, escalation, and rollback rules.
- Prove a model or harness update cannot silently change the status check.
- Keep SCA, SAST, DAST, secret scanning, build tests, and manual review enabled.
- Validate SARIF paths and sanitize messages before upload.
- Re-run the evaluation after changing weights, prompts, context, model server, tool parser, command budget, sandbox, or CWE selection.

## Use Antares or skip it?

**Evaluate Antares-1B** if your team already receives credible advisories or CWE hypotheses, spends significant time finding the relevant files, can run a local GPU endpoint, and has reviewers who can validate candidate paths. The 1B checkpoint is the stronger released model in Cisco's Phase A results.

**Compare Antares-350M** when throughput or deployment size matters enough to trade away localization quality. Use the same cases, budgets, and reviewer rubric; do not choose it from parameter count alone.

**Wait** if you need ungated artifact access, an official quantized or CPU path, independently reproduced benchmark results, published Phase B numbers for the released GRPO checkpoints, or a supported CI contract that your team can inspect before approval.

**Skip autonomous enforcement** if a model finding would directly patch code, disclose a vulnerability, close a ticket, change severity, or block production without corroborating evidence and human review. Antares is a focused triage component. Its value is reducing the search space while leaving proof, risk decisions, and remediation with the controls built for those jobs.

## FAQ

### What does Cisco Antares do?

Antares explores a repository from a CWE description and returns ranked source-file candidates plus its terminal trace. It localizes where reviewers should look; it does not prove exploitability, identify exact vulnerable lines, or produce a validated remediation.

### Are Antares-350M and Antares-1B fully public downloads?

Their Hugging Face repositories and model cards are public, but access to the files is gated. As of July 23, 2026, users must sign in, share contact information, accept the conditions, and pass manual review before downloading the weights or the Antares CLI asset.

### Can Antares replace SCA or SAST?

No. Antares does not build a dependency inventory, match vulnerable package versions, execute SAST rules, scan secrets, exercise a running application, prove exploitability, or validate a patch. Use its ranked candidates alongside SCA, SAST, DAST, secret scanning, tests, and expert review.

### Did AgentPedia reproduce Cisco's Antares benchmark scores?

No. The File F1 values in this guide are Cisco-reported results from VLoc Bench. The guide supplies a pinned evaluation workflow so teams with approved model access and suitable hardware can run their own Phase A and Phase B measurements.

### Should an Antares finding fail CI?

Not by default. Start in advisory or shadow mode, retain the terminal trace, and require corroborating evidence. Gate only after measuring false positives, false negatives, reviewer time, and stability on representative repositories and after defining an override and rollback path.


## Sources and methodology

This article prioritizes Cisco's launch post, public model cards, technical report, and source code for the benchmark and runner. Benchmark claims remain vendor-reported unless explicitly described as a local evaluation procedure.

### Cisco and model sources

- [Cisco Antares launch article](https://blogs.cisco.com/ai/introducing-antares-the-most-efficient-open-weight-ai-models-for-vulnerability-localization) and [official Cisco AI announcement](https://x.com/CiscoAI/status/2079552055778402548)
- [Antares-350M model card](https://huggingface.co/fdtn-ai/antares-350m), [Antares-1B model card](https://huggingface.co/fdtn-ai/antares-1b), and [Antares collection](https://huggingface.co/collections/fdtn-ai/antares)
- [Antares technical report](https://cisco-foundation-ai.github.io/antares/technical-report.pdf)

### Benchmark and reproducibility sources

- [Vulnerability Localization Benchmark repository](https://github.com/cisco-foundation-ai/vulnerability-localization-benchmark), [dataset card](https://github.com/cisco-foundation-ai/vulnerability-localization-benchmark/blob/main/DATASET_CARD.md), and [live leaderboard](https://cisco-foundation-ai.github.io/vulnerability-localization-benchmark/)
- [Pinned benchmark snapshot](https://github.com/cisco-foundation-ai/vulnerability-localization-benchmark/tree/000c19cda9ba027e1d241216768b2b6358685000), [default configuration](https://github.com/cisco-foundation-ai/vulnerability-localization-benchmark/blob/000c19cda9ba027e1d241216768b2b6358685000/configs/default.yaml), and [Antares vLLM runner](https://github.com/cisco-foundation-ai/vulnerability-localization-benchmark/blob/000c19cda9ba027e1d241216768b2b6358685000/src/vulnerability_localization_benchmark/model_runners/vllm_antares.py)
- [Dataset downloader and verifier](https://github.com/cisco-foundation-ai/vulnerability-localization-benchmark/blob/000c19cda9ba027e1d241216768b2b6358685000/data/downloader_and_verifier.py) and [file-scoring implementation](https://github.com/cisco-foundation-ai/vulnerability-localization-benchmark/blob/000c19cda9ba027e1d241216768b2b6358685000/src/vulnerability_localization_benchmark/scoring.py)

---

[Join the Agentpedia newsletter](https://agentpedia.codes/blog)

[Browse related Agentpedia articles](https://agentpedia.codes/blog)


---

- [All articles](https://agentpedia.codes/blog)