Antares transforma a autorização de agentes no novo perímetro da segurança de aplicações

A Cisco afirma que Antares consegue examinar 500 repositórios em 15 minutos por menos de $1. À primeira vista, o número parece uma vitória incontestável para a segurança de aplicações: inspeção quase contínua a um custo irrisório. Mas ele também torna economicamente viável colocar um operador automatizado ao lado do código, dar-lhe acesso a ferramentas e permitir que cada resultado dispare a ação seguinte.

As antigas ferramentas de varredura foram concebidas com base na separação de funções. Elas examinavam um repositório, emitiam um alerta e paravam. Um especialista em segurança decidia se o alerta era real, um desenvolvedor definia como alterar o código e um sistema de implantação determinava se a mudança poderia chegar ao ambiente de produção. A demora era frustrante, mas também funcionava como barreira: a análise não recebia automaticamente permissão para agir.

Os modelos Antares-350M e Antares-1B da Cisco condensam a primeira parte desse processo. São modelos pequenos, com pesos abertos, desenvolvidos para localizar vulnerabilidades conhecidas em bases de código, e há planos para o Antares-3B.

Mesmo com essa velocidade e esse preço, Antares não é um pesquisador autônomo de formas de exploração. Os modelos procuram vulnerabilidades conhecidas; o anúncio da Cisco não demonstra que consigam descobrir de forma independente todas as falhas inéditas nem executar ataques amplos. Ainda assim, as antigas passagens de responsabilidade começam a desaparecer antes mesmo que cheguem os recursos mais avançados. A detecção rotineira e barata pode ser executada junto a praticamente todos os repositórios, alimentando diretamente fluxos de trabalho dotados de ferramentas.

A detecção barata empurra as decisões difíceis para as etapas seguintes

Quando a varredura era cara, as equipes de segurança de aplicações precisavam racionar as análises: quais repositórios eram importantes, quais versões justificavam uma revisão e quais alertas mereciam a atenção de um especialista. Agora, as equipes podem examinar mais repositórios com maior frequência, gerando mais descobertas e reduzindo o valor da detecção como serviço centralizado; o que ainda precisa ser racionado é o poder de decidir o que acontece em seguida.

As equipes passam a ter de definir o que cada agente pode fazer. Um deles pode ler o código-fonte, mas não acessar segredos. Outro pode executar testes em um ambiente isolado, mas não chamar serviços externos. Um terceiro pode abrir uma solicitação, mas não enviar uma correção. Um agente de correção pode alterar uma ramificação, mas não incorporá-la, enquanto um agente de implantação pode chegar ao ambiente de homologação, mas não ao de produção. São decisões de autorização vinculadas a cada chamada de ferramenta e mudança de estado, não questões relacionadas à qualidade do modelo.

Os sistemas de identidade humana foram criados para responder a uma pergunta mais simples: qual pessoa entrou no sistema? Um fluxo de trabalho baseado em agentes exige uma sequência mais difícil de respostas: qual identidade não humana está agindo, em nome de quem, com qual contexto do repositório, por meio de qual ferramenta, depois de receber qual conteúdo não confiável e com que capacidade de tornar o resultado permanente? Uma autenticação no início não responde a tudo isso, assim como um crachá na entrada de um edifício não autoriza o acesso a todas as portas, painéis de controle e áreas de manutenção em seu interior.

É por isso que o acordo da Cisco para adquirir a Astrix Security, noticiado pela imprensa, importa mais do que outro teste de desempenho de ferramentas de varredura. A Astrix monitora e controla as permissões concedidas a agentes de IA. A informação sobre o acordo veio de uma fonte, e não da Cisco, portanto não deve ser tratada como uma estratégia já concluída. Ainda assim, a combinação identifica o novo ponto de controle: a análise do código fornece a descoberta; a identidade do agente determina se ela resultará em uma observação, uma correção ou um incidente.

A ferramenta de varredura virou um agente operacional e herdou seu potencial de impacto

Os fornecedores já foram além da simples sinalização de código suspeito. A OpenAI descreve o Codex Security como um agente que encontra, valida e propõe correções para vulnerabilidades. O MDASH da Microsoft coordena mais de 100 agentes e identificou 16 falhas do Windows até então desconhecidas. Esses sistemas reúnem descoberta, validação, priorização e correção em um único ciclo de raciocínio, ação e retorno.

Esse ciclo é útil. Uma descoberta pode disparar um teste; o resultado do teste pode refinar o diagnóstico; o diagnóstico pode gerar uma correção; e a correção pode ser testada novamente. A mesma estrutura, porém, também amplia a superfície de ataque, porque cada ação exige uma ferramenta, cada ferramenta precisa de credenciais ou permissões e cada resultado pode se tornar a entrada da etapa seguinte.

Um agente deve receber apenas a permissão mínima necessária para a ação em curso, perdê-la assim que a ação terminar e atravessar uma nova barreira de aprovação antes de passar da inspeção para a modificação ou da modificação para a implantação. As aplicações precisam autorizar cada chamada perigosa de ferramenta de acordo com o contexto, em vez de herdar as permissões da sessão humana que iniciou a tarefa.

Essa é a guinada mais ampla para a execução gerenciada: um fluxo de trabalho só torna útil a capacidade do modelo quando define onde ele pode agir, como seu trabalho será verificado e quais ações continuarão indisponíveis. Na segurança de aplicações, essas restrições são o próprio produto, e não apenas uma camada administrativa ao seu redor.

Quando as ferramentas de varredura se tornam baratas o bastante para funcionar em toda parte, a capacidade de auditoria — e não a taxa de detecção — passa a ser o diferencial no mercado corporativo.

A integração ao ambiente de desenvolvimento leva o perímetro para dentro do repositório

Assistentes independentes mantinham separações visíveis entre recomendação e execução. Essas divisões estão desaparecendo. A Apple adicionou suporte a Claude Agent, Codex e MCP no Xcode 26.3, colocando os agentes dentro do ambiente de trabalho do desenvolvedor. Plataformas de hospedagem de código, ambientes de desenvolvimento, ferramentas de linha de comando e plataformas de implantação agora fornecem o contexto de que os agentes precisam para ser úteis: conteúdo dos repositórios, chamados, resultados de compilação, credenciais e serviços conectados.

Contexto útil e acesso perigoso são o mesmo recurso, visto de lados opostos da barreira de permissões. Pesquisadores demonstraram uma forma de exploração no servidor MCP oficial do GitHub capaz de usar um chamado malicioso para induzir um agente baseado em LLM a vazar informações privadas de seu usuário. Separadamente, a CISA constatou que controles frágeis em repositórios públicos do GitHub permitiram que uma empresa contratada expusesse chaves privadas de acesso à nuvem e outras credenciais. Uma falha começou com conteúdo não confiável interpretado por um agente; a outra, com credenciais que atravessaram a fronteira de um repositório. Ambas revelaram a mesma fragilidade: código, identidade e ferramentas continuaram sendo administrados separadamente mesmo depois que o fluxo de trabalho os reuniu.

Pesquisadores também encontraram formas de escapar de ambientes isolados e contornar barreiras no Cursor, Codex, Gemini CLI e Antigravity por meio da gravação de arquivos posteriormente usados por ferramentas confiáveis. A maioria das falhas foi corrigida, o que demonstra que os mecanismos de contenção podem melhorar. Mas as correções também mostram que um único ambiente isolado externo não basta; os sistemas precisam de defesas que abranjam acesso aos repositórios, credenciais, arquivos gerados, ferramentas confiáveis, chamadas de rede e direitos de implantação.

Um agente não precisa de permissão para implantar código malicioso se puder gravar um arquivo que uma ferramenta confiável de implantação consumirá mais tarde. Também não precisa de acesso direto a um segredo se puder induzir outra ferramenta a recuperá-lo. Os invasores miram justamente essas transições: o momento em que um chamado não confiável vira uma instrução para o modelo, a saída do modelo vira um arquivo ou o arquivo vira um comando.

Pesos abertos enfraquecem o controle sobre o modelo, não sobre a implantação

Fornecedores de modelos fechados podem restringir recursos avançados de cibersegurança controlando contas e distribuição. A OpenAI disponibilizou o GPT-5.4-Cyber apenas a participantes selecionados de seu programa Trusted Access for Cyber, preservando uma vantagem técnica e impondo condições de acesso. Essa barreira continua relevante: os modelos de cibersegurança com pesos abertos ainda estão atrás dos sistemas de ponta.

Mas a distância está diminuindo. Os principais modelos de cibersegurança com pesos abertos estavam 4–7 meses atrás dos modelos fechados de ponta, ante 6–10 meses durante a maior parte de 2025. A diferença restante dá vantagem aos fornecedores que controlam os sistemas mais avançados, mas não restabelece o controle centralizado sobre essa capacidade de forma mais ampla.

Um modelo menor não precisa igualar o melhor modelo fechado para mudar a economia do trabalho de segurança. Basta ter capacidade suficiente para repetir uma tarefa delimitada, acesso ao código relevante e ferramentas que transformem cada resultado em uma nova tentativa. Relatos de que agentes de programação conseguem automatizar partes da descoberta de vulnerabilidades inéditas mostram o efeito de uso duplo: o mesmo ciclo iterativo que permite a um defensor validar e corrigir uma vulnerabilidade também permite a um invasor pesquisar, testar e aperfeiçoar sua abordagem com menor custo marginal.

As organizações não podem usar políticas de distribuição como substituto do controle na camada de implantação onde quer que opere um modelo aberto ou menor. Os repositórios de modelos abertos já estão se tornando uma superfície de ataque para agentes, o que torna as permissões de repositório, os limites de uso das ferramentas, os ambientes isolados e a duração das credenciais controles mais duradouros do que o acesso a qualquer família específica de modelos.

A vantagem da Cisco está entre a descoberta e a ação

A oportunidade estratégica da Cisco não consiste apenas em vender uma ferramenta melhor para encontrar vulnerabilidades. Está em conectar a análise de código do tipo Antares à identidade dos agentes, aos controles de rede e às políticas corporativas, permitindo que uma organização determine não só o que um agente encontrou, mas também o que tinha autorização para ler, qual ferramenta acionou, que alteração propôs e até onde essa alteração chegou.

A Cisco também avançou em direção à camada dos desenvolvedores. De 2024 a 2026, a presença do enfoque em desenvolvedores em sua comunicação subiu 11.8 pontos percentuais, enquanto a do enfoque corporativo caiu 13.1 pontos percentuais. A Cisco também se juntou a Chainguard, Cloudflare, JPMorgan Chase e outras empresas no lançamento da Athena, uma coalizão que usa IA para proteger software de código aberto. Nenhum dos dois movimentos, porém, conecta uma descoberta a limites efetivamente aplicáveis ao agente que age a partir dela.

A própria Cisco também oferece provas de por que essas partes não podem continuar separadas. Segundo fontes, invasores roubaram o código-fonte da Cisco depois de invadir seu ambiente interno de desenvolvimento com credenciais obtidas por meio de um ataque à cadeia de suprimentos do Trivy. Uma análise de código melhor, por si só, não resolveria o problema de credenciais roubadas, de um ambiente de desenvolvimento comprometido nem da confiança herdada pelas ferramentas usadas nas etapas seguintes. A invasão tornou a cadeia concreta: um repositório, uma credencial, um sistema de desenvolvimento e um caminho pelo qual o acesso se propagou.

A varredura de 500 repositórios por menos de $1 transforma o antigo painel de segurança de aplicações da Cisco: ele deixa de ser um ponto de controle e passa a atuar como um agente ao lado do código. Quando essa ferramenta de varredura passa a ter outros recursos ao alcance, uma única barreira no acesso inicial já não funciona como perímetro. O controle precisa acompanhar cada chamada de ferramenta.