Os pequenos modelos de IA da Cisco expõem uma concessão de segurança maior

A Cisco Foundation AI lançou dois modelos de segurança de pesos abertos em julho, apesar das evidências de que até mesmo os sistemas líderes ainda deixam de localizar a maioria dos trechos de código vulneráveis. O anúncio chegou ao Google News como mais uma coleção mensal de modelos, benchmarks e pesquisas de segurança. No entanto, a história importante não é a cadência de publicações da Cisco.

A Cisco está testando se modelos pequenos e especializados conseguem lidar com trabalhos repetitivos de segurança de forma mais econômica do que sistemas de fronteira de uso geral. Antares-350M e Antares-1B buscam, em repositórios de software, arquivos associados a categorias conhecidas de vulnerabilidades. Eles podem ser executados localmente, mantendo o código-fonte sensível dentro do ambiente da organização.

Esse design desafia a premissa de que toda tarefa difícil de IA exige o maior modelo disponível. Microsoft e Google apresentaram seus próprios sistemas especializados em cibersegurança no mesmo período. A disputa emergente agora coloca modelos focados e implantáveis localmente contra serviços maiores com capacidades de raciocínio mais amplas.

Os resultados de benchmark da Cisco sustentam a abordagem especializada, mas também revelam seus limites. O melhor sistema no benchmark principal da Cisco alcançou uma pontuação File F1 abaixo de 0,23. Quase duas em cada cinco tarefas de benchmark derrotaram todos os modelos avaliados.

Portanto, trata-se de uma concessão, não de uma volta da vitória. Modelos menores oferecem menores exigências operacionais, controle de dados mais rigoroso e análise repetível de repositórios. Seus resultados incompletos ainda exigem analistas experientes, ferramentas de segurança estabelecidas e validação cuidadosa.

O que a Cisco realmente lançou em julho

A Cisco lançou um sistema focado de busca em código, não um caçador autônomo de vulnerabilidades.

Em 21 de julho de 2026, a Cisco apresentou Antares-350M e Antares-1B como pequenos modelos de linguagem de pesos abertos. Seu propósito é a localização de vulnerabilidades, ou seja, encontrar arquivos que possam conter uma fraqueza descrita.

A distinção importa porque a localização representa apenas uma etapa da gestão de vulnerabilidades. O Antares não confirma de forma independente a explorabilidade, não determina a gravidade, não produz uma correção completa nem aprova código para produção.

Em vez disso, cada modelo recebe um repositório e uma descrição de Common Weakness Enumeration. Uma CWE é uma categoria padronizada que descreve uma fraqueza recorrente de software, como validação inadequada de entrada.

O modelo explora um repositório somente leitura usando comandos de terminal. Ele busca padrões relevantes, lê arquivos candidatos, avalia as evidências e muda de direção quando um caminho de busca parece improdutivo.

A Cisco descreve esse comportamento em seu lançamento do Antares. O sistema retorna uma lista classificada de arquivos prováveis e um rastreamento dos comandos usados durante a exploração.

Esse rastreamento é importante para as operações de segurança. Um analista pode inspecionar como o modelo chegou à resposta, em vez de receber um veredito de vulnerabilidade sem embasamento.

Antares-350M é voltado a ambientes computacionais restritos e oferece suporte a uma janela de contexto de 32.000 tokens. Antares-1B oferece suporte a 128.000 tokens e foi projetado para operar em um único processador gráfico.

A execução local é outro recurso definidor. Uma empresa pode inspecionar código proprietário sem transmitir seu repositório a um provedor de modelos hospedados. Essa opção aborda preocupações de privacidade, residência de dados e contratos que frequentemente impedem análises de segurança baseadas em nuvem.

A Cisco também apresentou o VLoc Bench para medir os modelos. O benchmark contém 500 tarefas extraídas de 290 repositórios, seis ecossistemas de pacotes e 147 categorias distintas de CWE.

Cada tarefa inclui um snapshot de repositório com uma vulnerabilidade conhecida. Os rótulos de referência vêm dos arquivos alterados pela correção de segurança correspondente.

O benchmark separa localização de verificação. Durante a localização, um modelo precisa encontrar os arquivos associados à fraqueza. Durante a verificação, ele examina o repositório corrigido e deve evitar relatar incorretamente o problema já reparado.

Essa estrutura é mais restrita do que um teste de penetração completo. Também é mais exigente do que recuperar um trecho de código a partir de um prompt preparado.

O modelo precisa navegar por repositórios desconhecidos operando com informações limitadas. Isso torna o benchmark relevante para a triagem de alertas, em que defensores frequentemente conhecem a categoria da fraqueza antes de localizar sua implementação.

A Cisco posiciona o Antares ao lado de análise estática, análise de composição de software, varredura de segredos, testes dinâmicos e revisão humana. Ela não apresenta os modelos como substitutos desses controles.

A mudança imediata é, portanto, prática, mas limitada. As equipes de segurança ganharam dois modelos para download capazes de reduzir um grande repositório a um conjunto menor de arquivos candidatos.

Essa primeira redução pode economizar atenção durante investigações repetitivas. Ela não pode estabelecer que os arquivos selecionados são vulneráveis, nem provar que os arquivos omitidos são seguros.

Por que o Google News não captou o que está em jogo

A manchete do Google News enquadrou julho como uma sequência de lançamentos, enquanto a mudança real diz respeito a quem pode arcar com revisões contínuas de código.

As equipes de segurança de aplicações não inspecionam um repositório apenas uma vez. O código muda, as dependências se movimentam, os avisos chegam e comportamentos antes aceitáveis tornam-se perigosos diante de novas técnicas de ataque.

Um modelo de fronteira hospedado pode ajudar nessas revisões. No entanto, análises repetidas em escala de repositório consomem recursos substanciais de inferência e podem exigir o envio de código sensível para fora da infraestrutura da empresa.

Pequenos modelos locais mudam essa equação operacional. Eles podem executar uma tarefa restrita repetidamente sem tornar cada varredura dependente de um serviço externo premium.

A concessão pressiona vários grupos ao mesmo tempo. Provedores de modelos de fronteira precisam demonstrar que um raciocínio mais amplo produz valor adicional suficiente para justificar maiores exigências operacionais.

Fornecedores de segurança precisam decidir se modelos especializados pertencem a scanners existentes, consoles de triagem e pipelines de integração contínua. Equipes internas de segurança precisam determinar se classificações de arquivos geradas por modelos realmente reduzem a carga de trabalho dos analistas.

A abordagem da Cisco também pressiona organizações que trataram a segurança com IA como uma decisão de compra de chatbots. A localização de vulnerabilidades é um problema de fluxo de trabalho que envolve acesso ao repositório, registro de evidências, permissões e escalonamento humano.

Uma implantação útil conectaria o Antares a um snapshot controlado do repositório. Ela registraria o rastreamento da busca, retornaria arquivos candidatos e encaminharia esses candidatos a um analista.

O analista compararia a saída com dados de dependências, achados estáticos, testes e o aviso original. Só então a organização decidiria se a remediação é necessária.

Essa divisão de trabalho importa porque o trabalho com vulnerabilidades tem consequências assimétricas. Um falso positivo consome tempo do analista, enquanto um falso negativo deixa código perigoso sem ser descoberto.

Os lançamentos de julho sugerem que nenhum modelo individual precisa assumir todo o processo. Um modelo pode localizar código suspeito enquanto outro avalia a explorabilidade ou elabora uma correção.

O Google DeepMind expressou uma visão semelhante ao apresentar um modelo cibernético especializado por meio de seu programa CodeMender. A Microsoft também anunciou um modelo de cibersegurança treinado internamente e agentes de segurança relacionados.

Uma comparação do setor descreveu as três empresas como focadas em sistemas específicos para tarefas. Sua motivação comum inclui restrições de acesso e o custo de executar modelos de fronteira em escala.

Essa convergência dá ao trabalho da Cisco uma relevância maior do que a de um lançamento de produto. Modelos de segurança especializados estão se tornando uma camada distinta entre scanners determinísticos e assistentes de IA de uso geral.

Ferramentas estáticas continuam eficazes quando os mantenedores podem definir regras confiáveis. Modelos de fronteira continuam úteis quando uma tarefa exige raciocínio amplo, geração de correções ou interação entre muitos sistemas.

Um pequeno modelo de segurança se encaixa entre eles. Ele pode aprender padrões investigativos de busca, permanecendo compacto o suficiente para implantação controlada e frequente.

A questão competitiva não é se o Antares consegue superar todos os modelos maiores. É se um portfólio de sistemas especializados consegue oferecer precisão suficiente em fluxos de trabalho defensivos rotineiros.

Se esse modelo funcionar, os compradores avaliarão a IA pela economia da tarefa e pela adequação operacional. O prestígio em benchmarks gerais terá menos peso do que reduções mensuráveis no tempo de triagem.

Pequenos modelos de segurança desafiam a economia dos modelos de fronteira

O Antares argumenta que um comportamento de busca treinado pode importar mais do que a contagem de parâmetros em uma tarefa de segurança rigorosamente definida.

Modelos de programação de uso geral aprendem sobre trabalho com vulnerabilidades ao lado de muitas capacidades não relacionadas. Eles precisam dar suporte à escrita, explicação, planejamento, geração de código e raciocínio amplo sobre software.

O Antares restringe o objetivo. Ele aprende a buscar, inspecionar evidências, revisar um caminho e identificar arquivos associados a uma determinada descrição de fraqueza.

Esse alvo de treinamento mais restrito permite que a Cisco aloque a capacidade do modelo para a navegação em repositórios. A abordagem se assemelha a um investigador treinado operando por ferramentas, e não a um chatbot que recorda terminologia de segurança.

O modelo começa com evidências limitadas. Ele pode pesquisar nomes de arquivos e padrões de código, inspecionar arquivos relevantes e usar novas pistas para orientar comandos posteriores.

Um agente útil também precisa abandonar hipóteses fracas. Sem esse comportamento, a exploração de repositórios pode se tornar uma sequência cara de buscas redundantes.

O benchmark da Cisco testa esse processo sob um limite de comandos. A estrutura do repositório, portanto, torna-se parte da tarefa, e não informação de fundo escondida em um prompt.

Os resultados sustentam a tese de especialização da Cisco. Antares-1B registrou uma pontuação File F1 de 0,209 no VLoc Bench, segundo dados de benchmark publicados.

O Antares-3B, ainda não lançado, alcançou 0,223. A configuração líder do GPT-5.5 marcou 0,229, deixando apenas uma pequena diferença numérica na avaliação da Cisco.

A contagem de parâmetros, por si só, não determinou a classificação. A Cisco informa que seu modelo 3B treinado para esse propósito igualou ou superou sistemas de uso geral com mais de 100 bilhões de parâmetros.

O ponto maior não é que um modelo 3B tenha se tornado, de modo geral, equivalente a um sistema de fronteira. Não se tornou. A comparação cobre uma tarefa restrita, um harness e um método de pontuação.

Posteriormente, a Cisco testou os mesmos pesos no CyberGym localization e em uma reconstrução pública da avaliação de segurança da Cognition. Essa etapa importa porque os modelos frequentemente parecem mais fortes em benchmarks criados por seus desenvolvedores.

O CyberGym inclui cerca de 1.500 vulnerabilidades de 188 projetos de código aberto. Seu benchmark completo avalia a geração de exploits, mas a Cisco isolou a etapa anterior de localização.

Antares-1B alcançou 67,2% de recall nesse teste de localização. O modelo 3B ainda não lançado chegou a 73,7%, enquanto o principal modelo de fronteira atingiu 89,1%.

Esses números mostram tanto transferência quanto uma lacuna contínua de capacidade. Os modelos menores mantiveram um comportamento útil em uma tarefa externa, mas não alcançaram o melhor resultado de fronteira.

Os testes de benchmark externos da Cisco também incluíram uma reconstrução comunitária da avaliação de segurança da Cognition. Apenas 34 dos 50 casos de teste originais estavam disponíveis publicamente.

A Cisco estimou os resultados dessa comparação por extrapolação a partir do subconjunto público. Ela descreveu explicitamente os números como indicativos, e não como uma avaliação direta genuína.

Essa ressalva é essencial. Diferentes agentes podem usar prompts, limites de comandos, infraestrutura, gerenciamento de contexto e regras de parada distintos.

Mesmo quando dois sistemas recebem o mesmo repositório, o ambiente de execução ao redor pode afetar substancialmente seus resultados. Benchmarks de agentes medem uma combinação de modelo e sistema, não uma inteligência isolada.

Ainda assim, o argumento econômico continua crível. Um modelo local evita o consumo medido por tokens e permite análises repetidas sem exportar o código-fonte.

Isso torna a especialização atraente para triagens em alto volume. Um modelo maior pode então abordar o grupo menor de repositórios ou arquivos que exige uma investigação mais profunda.

A arquitetura provável é, portanto, hierárquica. Modelos especializados e baratos cuidam da localização em larga escala, enquanto sistemas caros e especialistas humanos examinam casos ambíguos.

Essa abordagem espelha operações de segurança já estabelecidas. As organizações já usam controles automatizados de baixo custo para filtrar atividades antes de escalar descobertas incertas.

Antares não elimina os modelos de fronteira do processo. Ele muda onde as equipes podem reservar seu uso.

A Vitória no Benchmark Vem com um Alerta

As evidências mais fortes da Cisco também mostram por que Antares não pode se tornar uma barreira de segurança sem uma validação local substancial.

A comparação principal entre Antares-3B e GPT-5.5 parece impressionante. As pontuações absolutas contam uma história menos confortável.

O sistema com melhor desempenho no VLoc Bench alcançou apenas 0.229 de File F1. File F1 combina precisão e revocação ao comparar arquivos previstos com os arquivos alterados por um patch conhecido.

Uma pontuação baixa pode refletir arquivos relevantes não identificados, sugestões irrelevantes ou ambos. Qualquer uma dessas falhas cria trabalho ou risco para a equipe de segurança que recebe o resultado.

As conclusões publicadas do benchmark mostram que 190 de 500 tarefas permaneceram sem solução para todos os modelos avaliados. Isso representa 38 por cento do conjunto completo.

O desempenho também caiu treze vezes dos menores repositórios para os maiores. A Cisco concluiu que a complexidade estrutural previa a dificuldade com mais força do que a categoria de vulnerabilidade.

Essa descoberta cria a inversão central da história. A especialização ajuda modelos pequenos a competir com modelos muito maiores, mas não torna confiável a descoberta de vulnerabilidades na escala de um repositório.

A mesma limitação aparece no limite do produto. Antares identifica arquivos candidatos, mas os analistas ainda precisam determinar se a fraqueza existe e se pode ser explorada.

Um repositório pode conter várias implementações de um padrão. Código gerado, wrappers, testes, dependências vendorizadas e camadas de compatibilidade podem confundir a busca.

Um patch de segurança também fornece uma forma imperfeita de verdade fundamental. Às vezes, os mantenedores alteram arquivos de suporte que não são diretamente vulneráveis ou deixam locais relacionados fora do reparo inicial.

Portanto, os benchmarks podem recompensar a concordância com um patch histórico sem medir plenamente a compreensão de segurança. Eles continuam úteis, mas suas pontuações não devem ser tratadas como taxas universais de detecção.

Os testes externos da Cisco reduzem as preocupações com sobreajuste completo ao benchmark. Eles não eliminam a necessidade de replicação independente em repositórios corporativos.

Uma organização que adote Antares deve começar com casos retrospectivos. As equipes podem fornecer vulnerabilidades previamente corrigidas e medir se o modelo identifica os arquivos conhecidos.

Elas também devem registrar sugestões irrelevantes, arquivos não identificados, uso de comandos, tempo de execução e tempo de revisão dos analistas. Bases de código diferentes produzirão padrões de erro distintos.

A janela de contexto do modelo não garante a compreensão integral de um repositório. Antares navega por comandos de terminal, portanto seu sucesso depende de selecionar as buscas e evidências corretas.

Grandes monorepositórios criam desafios específicos. Uma descrição de fraqueza pode se aplicar a serviços, clientes gerados, bibliotecas compartilhadas e diversas linguagens de implementação.

O benchmark confirma esse problema de tamanho de repositório. Ele também sugere que simplesmente aumentar a quantidade de parâmetros não removerá todos os obstáculos estruturais.

Líderes de segurança devem resistir a transformar a confiança do modelo em autoridade de política. Antares não deve bloquear independentemente uma versão, encerrar um ticket de vulnerabilidade ou certificar um patch.

Uma implementação cautelosa trataria sua saída como consultiva. Arquivos mais bem classificados receberiam atenção humana mais cedo, enquanto controles convencionais continuariam examinando a base de código mais ampla.

Reportagens independentes chegaram a uma conclusão semelhante. Uma avaliação de implantação observou que os modelos não confirmam vulnerabilidades, não atribuem gravidade nem geram correções.

A reportagem também destacou a necessidade de isolar o ambiente de análise. A execução local mantém o código no local, mas não protege automaticamente o sistema ao redor.

Um modelo com acesso ao terminal ainda interage com repositórios sensíveis e dependências de inferência. Administradores precisam de acesso com privilégio mínimo, restrições de rede, logs e artefatos de modelo verificados.

Pesos abertos criam opções de inspeção e implantação. Eles não fornecem garantia contra adulteração, integrações inseguras ou permissões inadequadas.

Pesos Abertos Não Significam Confiança Irrestrita

A Cisco está equilibrando um acesso defensivo mais amplo com a possibilidade de que modelos de segurança possam ajudar atacantes.

A empresa chama Antares de open weight porque usuários qualificados podem obter os parâmetros treinados. O comportamento do modelo pode então ser executado em uma infraestrutura fora dos serviços hospedados pela Cisco.

No entanto, baixar os modelos lançados exige informações de contato e aprovação. A Cisco afirmou que verifica o acesso para reduzir a chance de criminosos obterem as ferramentas.

Essa distribuição controlada complica o debate habitual entre aberto e fechado. Antares oferece implantação local e pesos inspecionáveis sem permitir acesso anônimo e imediato.

A Cisco teria consultado agências do governo dos Estados Unidos sobre a segurança do modelo e as decisões de lançamento. Isso reflete a natureza de uso duplo da pesquisa de vulnerabilidades.

Um modelo de localização pode ajudar defensores a encontrar código exposto. A mesma capacidade pode ajudar um atacante a restringir a busca por uma fraqueza conhecida em um repositório disponível.

Os modelos da Cisco param antes da geração de exploits, mas esse limite não elimina o uso indevido. Encontrar o arquivo relevante costuma ser um primeiro passo importante no desenvolvimento de um exploit.

A cobertura do lançamento descreve Antares como parte de um movimento mais amplo em direção a ferramentas de segurança abertas. A Capital One lançou, no mesmo período, um agente separado focado em vulnerabilidades.

A pesquisa aberta em segurança tem benefícios de longa data. Regras, benchmarks e casos de teste compartilhados permitem que defensores reproduzam descobertas e comparem sistemas.

Ela também aumenta o escrutínio. Pesquisadores podem identificar erros de avaliação, suposições ocultas e configurações padrão inseguras que um serviço fechado poderia ocultar.

O risco aumenta quando as ferramentas ganham mais autonomia. Um modelo que apenas classifica arquivos tem menos autoridade do que um agente autorizado a executar código, acessar redes ou modificar repositórios.

As equipes de implantação devem preservar essa autoridade limitada. Acesso somente leitura ao repositório, execução em sandbox, comandos limitados e rastros revisáveis devem continuar sendo controles padrão.

A pesquisa mais ampla da Cisco reforça essa cautela. Sua avaliação de 15 modelos proprietários de fronteira encontrou grandes diferenças entre ataques de turno único e ataques adaptativos de múltiplos turnos.

As taxas de sucesso de ataques em múltiplos turnos variaram de 7.89 por cento a 88.30 por cento. As taxas de turno único na mesma coorte variaram de 2.19 por cento a 64.91 por cento.

A pesquisa sobre múltiplos turnos argumenta que testes de segurança com um único prompt não representam atacantes que se adaptam após cada recusa. Essa lição também se aplica a agentes defensivos.

Um agente de busca em repositórios opera por meio de uma sequência de observações e ações. Testar uma saída isolada não pode revelar todas as trajetórias inseguras ou falhas de permissão.

Isso torna a estratégia de benchmark do Antares mais interessante do que o lançamento do modelo por si só. A Cisco está construindo modelos, avaliações específicas por tarefa e especificações para sistemas de agentes controlados.

Essas peças formam um argumento sobre como a segurança com IA deve ser adquirida. Compradores precisam de evidências sobre fluxos de trabalho definidos, condições de ataque, permissões e taxas de falha.

Um cartão de modelo ou um ranking geral não pode responder a essas questões operacionais. Tampouco uma manchete favorável no Google News.

Equipes de segurança precisam de artefatos de avaliação que se pareçam com seus repositórios e restrições. Elas também precisam de registros que mostrem quando o modelo mudou de direção e por que selecionou um arquivo.

Essa evidência pode apoiar auditorias e análises de incidentes. Ela também pode revelar quando um modelo se baseou em nomes superficiais, em vez de relações significativas no código.

Pesos abertos facilitam esses testes locais. O acesso controlado, porém, limita a participação da comunidade e pode desacelerar a replicação independente.

A Cisco precisará mostrar que seu processo de revisão concede aos pesquisadores legítimos acesso prático. Caso contrário, as alegações de abertura continuarão mais restritas do que o rótulo sugere.

O Que as Equipes de Segurança Devem Observar em Seguida

Os próximos três sinais determinarão se modelos especializados de segurança se tornarão infraestrutura ou continuarão sendo demonstrações de pesquisa impressionantes.

O primeiro sinal é a replicação independente do benchmark. Pesquisadores devem executar Antares contra repositórios, linguagens e classes de vulnerabilidade que a Cisco não selecionou.

Os resultados fora da distribuição do CyberGym já fornecem evidências úteis. Testes mais amplos devem medir precisão, falsos negativos, tempo de execução e esforço dos analistas sob ambientes de execução consistentes.

Um resultado favorável reforçaria a tese de especialização da Cisco. Quedas grandes de desempenho sugeririam que os modelos aprenderam padrões de busca específicos do benchmark, e não habilidades de investigação transferíveis.

O segundo sinal é a integração em produção. Antares se torna operacionalmente relevante quando plataformas de segurança conseguem inserir seus arquivos classificados em fluxos de trabalho existentes de investigação e remediação.

As equipes devem observar integrações com sistemas de integração contínua, scanners estáticos, plataformas de gerenciamento de avisos e descobertas SARIF padronizadas. SARIF é um formato comum para troca de resultados de análise estática.

Integração, por si só, não é adoção. A Cisco ou seus parceiros devem mostrar que os analistas encerram investigações mais rapidamente sem aceitar mais vulnerabilidades não identificadas.

A evidência mais útil compararia o tempo dos analistas antes e depois da implantação. Estudos de caso também devem divulgar o tamanho do repositório, a cobertura de linguagens e o processo de revisão humana.

Organizações que realizam pilotos devem preservar suas próprias notas de avaliação, contexto de código, avisos e decisões dos revisores. Uma base de conhecimento pesquisável pode ajudar equipes a reter essas evidências em testes repetidos.

O terceiro sinal é a resposta competitiva. Microsoft, Google, OpenAI, fornecedores de segurança e pesquisadores de código aberto estão todos explorando modelos ou agentes cibernéticos especializados.

Observe se eles publicam benchmarks por tarefa com ambientes de execução reproduzíveis. Observe também se seus sistemas separam localização, verificação, exploração e remediação.

Uma separação clara apoiaria a visão modular da Cisco sobre agentes de segurança. Sistemas integrados com resultados ponta a ponta consistentemente mais fortes enfraqueceriam o argumento a favor de um modelo dedicado à localização.

Antares-3B é mais um teste concreto dentro desse sinal. A Cisco incluiu seus resultados, mas ainda não havia divulgado seus pesos ao publicar as avaliações de julho.

Quando estiver disponível, pesquisadores independentes poderão testar se seu desempenho próximo à fronteira no VLoc Bench se transfere para repositórios diferentes. Eles também poderão comparar seu comportamento com as variantes 350M e 1B divulgadas.

Compradores de soluções de segurança devem evitar esperar por um único vencedor universal. As evidências já sugerem que a escolha do modelo dependerá do escopo da tarefa, dos requisitos de privacidade, da complexidade do repositório e da capacidade de revisão.

O Google News continuará condensando esses lançamentos em anúncios de modelos e classificações de benchmarks. Os profissionais devem fazer uma pergunta mais difícil: o sistema reduz o trabalho de segurança verificado sem ocultar novos modos de falha?

Execute um piloto delimitado com base em casos históricos, preserve cada rastreamento de busca e compare os resultados com seus controles existentes. Essas evidências revelarão se a IA especializada tem lugar no seu pipeline de segurança.