A Microsoft anunciou um grande avanço na defesa cibernética baseada em IA: nosso novo sistema de segurança agêntica ajudou pesquisadores a encontrar 16 novas vulnerabilidades na cadeia de redes e autenticação do Windows — incluindo quatro falhas críticas na execução remota de código em componentes como a cadeia TCP/IP do kernel do Windows e o serviço IKEv2. Eles usaram o novo sistema de varredura agêntica multimodelo da Microsoft Security (codinome MDASH), desenvolvido pela equipe de Segurança de Código Autônomo da Microsoft. Diferente das abordagens de modelo único, a plataforma orquestra mais de 100 agentes de IA especializados em um conjunto de modelos de fronteira e destilados para descobrir, debater e comprovar bugs exploráveis de ponta a ponta.

Os resultados falam por si só: 21 das 21 vulnerabilidades plantadas encontradas sem nenhum falso positivo em um piloto de testes particular; 96% de recall contra cinco anos de casos confirmados pelo Microsoft Security Response Center (MSRC) em clfs.sys e 100% em tcpip.sys; e uma pontuação líder do setor com 88,45% no benchmark público CyberGym de 1.507 vulnerabilidades do mundo real — a maior pontuação no ranking, cerca de cinco pontos à frente da próxima entrada.

A implicação estratégica é clara: a descoberta de vulnerabilidades com IA passou da fase de pesquisa por curiosidade para uma etapa de produção de defesa em escala empresarial, e a vantagem duradoura está no sistema agêntico em torno do modelo, e não em qualquer modelo isolado. O nome de código MDASH está sendo usado por equipes de engenharia de segurança da Microsoft e testado por um pequeno grupo de clientes como parte de uma prévia privada limitada.

Este post explica como funciona o codinome MDASH, o que lançamos hoje, o que aprendemos ao longo do caminho e como você pode se inscrever para a prévia privada.

Descoberta de vulnerabilidades impulsionada por IA em hiperescala

A  equipe Microsoft Autonomous Code Security (ACS) foi formada para levar a pesquisa de vulnerabilidades alimentada por IA de uma curiosidade para a engenharia de produção em escala empresarial. Vários membros dessa equipe vieram da Team Atlanta para a Microsoft, a equipe que venceu o Desafio Cibernético de IA da DARPA de 20 milhões de dólares ao construir um sistema autônomo de raciocínio cibernético que encontrou e corrigiu bugs reais em projetos complexos de código aberto. As lições desse trabalho, especialmente o nível de engenharia necessário para fazer os modelos de linguagem de ponta realizarem auditorias de segurança em nível profissional, são o que nosso novo harness de varredura agentica multimodelo (codinome MDASH) foi construído.

A base de código da Microsoft é desafiadora para auditoria de segurança por alguns motivos:

• Superfície proprietária massiva. Windows, Hyper-V, Azure e os ecossistemas de drivers de dispositivo e serviços ao redor deles são bases de código privadas da Microsoft. Ou seja, não fazem parte do corpus de treinamento de nenhum modelo de linguagem comum, e são realmente difíceis de raciocinar: convenções de chamada de kernel, IRP e invariantes de bloqueio, limites de confiança IPC e idioms internos de componentes não cedem à correspondência de padrões. Nessa superfície, um modelo precisa realmente raciocinar. 
• DevSecOps em escala. Cada achado tem um dono real, um processo de triagem e um Patch Tuesday para se basear. Não há um ”arquivos esquecidos” com descobertas especulativas; Se uma ferramenta gera ruído, isso é problema de todos. 
• Alvos de alto valor. Windows, Hyper-V, Xbox e Azure atendem bilhões de usuários. O retorno por encontrar um único bug difícil é incomumente alto — assim como o custo de um falso positivo em um componente de primeiro nível. 

As conclusões deste post são resultado de uma colaboração próxima entre a ACS e o Microsoft Windows Attack Research and Protection (WARP). A WARP domina a parte profunda e difícil da pesquisa ofensiva do Windows; A ACS traz o pipeline de descoberta e validação impulsionado por IA. Juntas, as equipes colaboraram para construir um framework maduro.

Codinome: MDASH — o novo sistema de varredura agêntica multimodelo de segurança da Microsoft Security

O codinome MDASH é, em sua essência, um sistema agêntico de descoberta e remediação de vulnerabilidades. O modelo é uma entrada. O sistema é o produto.

Um modelo mental útil é pensar nele como um pipeline estruturado que pega uma base de código e emite  descobertas validadas e comprovadas:

• Estágio de preparação: Ingere o alvo de origem, constrói índices conscientes da linguagem e então desenha a superfície de ataque e os modelos de ameaça analisando os commits anteriores.
• Estágio de varredura: Roda agentes auditores especializados sobre caminhos de código candidato, emitindo achados candidatos com hipóteses e evidências.
• Etapa de validação: Executa um segundo conjunto de agentes — os debatedores — que argumentam a favor e contra a alcançabilidade e explorabilidade de cada achado.
• Estágio de desduplicação: Colapsa achados semanticamente equivalentes (por exemplo, agrupamento baseado em patches).
• Estágio de prova: Constrói e executa entradas de disparo onde a classe bug admite. A fase de prova valida dinamicamente a pré-condição e formula as entradas que acionam bugs para provar a existência da vulnerabilidade (por exemplo, ASan em C/C++). 

Três propriedades fazem isso funcionar na prática:

1. Um conjunto de modelos diversos que são efetivamente gerenciados pelo codinome MDASH. Nenhum modelo único é o melhor em todas as etapas. O sistema de varredura agêntica multimodelo executa um painel configurável de modelos. Isso inclui modelos SOTA (state-of-the-art) como argumento pesado, modelos destilados como debatedores econômicos para passagens de alto volume, e um segundo modelo SOTA separado como contraponto independente. O desacordo entre modelos é, em si, um sinal: quando um auditor sinaliza algo como suspeito e o debatedor não consegue refutar, a credibilidade posterior dessa conclusão aumenta.
2. Agentes especializados. Um auditor não raciocina como um debatedor, que não raciocina como um comprovador. Cada etapa do pipeline tem seu próprio papel, regime de prompt, ferramentas e critérios de parada. Não esperamos que um único prompt faça tudo; Não esperamos que um agente reconheça, valide e explore um bug em uma única passagem. O codenome MDASH possui mais de 100 agentes especializados, construídos por meio de pesquisas profundas com vulnerabilidades e exposições comuns (CVEs) anteriores e seus patches, trabalhando de forma independente para descobrir os bugs, e seus resultados de auditoria serão reunidos como um único relatório.
3. Pipeline de ponta a ponta com plugins extensíveis. O pipeline é opinativo, mas não está fechado. Plugins permitem que especialistas em domínio injetem contexto que os modelos de fundação não conseguem ver sozinhos — convenções de chamada de kernel, regras IRP, invariantes de bloqueio, limites de confiança IPC, máquinas de estados de codecs. O plugin de prova CLFS que descrevemos abaixo é um desses exemplos: um plugin de domínio que sabe como construir um arquivo de log de disparo dado um achado candidato. Por exemplo, o sistema de razonamento estendido da equipe Windows com banco de dados personalizado de análise de código, ou banco de dados CodeQL, também pode ser aproveitado. 

A vantagem dessa arquitetura é a portabilidade entre gerações de modelos. Os direcionamento, validação, deduplicação e prova do pipeline são agnósticos ao modelo por construção, o que permite que o sistema obtenha o melhor do que qualquer modelo tem a oferecer. Quando um novo modelo aterrissa, testá-lo em A/B contra o painel atual é uma inversão de configuração. Quando um modelo melhora, o investimento prévio do cliente — como arquivos de escopo, plugins, configurações, calibrações — se mantém, permitindo que os clientes naveguem na ponta do valor de segurança.  

Uso do codinome MDASH para pesquisa em segurança

Para avaliar as capacidades de detecção de bugs do sistema de varredura agêntica multimodelo, é necessário primeiro se basear em um código que nunca foi visto por um modelo. Isso elimina a possibilidade de que um modelo “tenha aprendido as respostas do teste.” Escaneamos o StorageDrive, um driver de dispositivo de exemplo usado em entrevistas da Microsoft para pesquisadores de segurança ofensiva. O driver contém 21 vulnerabilidades deliberadamente injetadas, incluindo uso pós-liberação (UAFs) do kernel, problemas de tratamento de inteiros, lacunas na validação do IOCTL e erros de travamento. Como o StorageDrive é uma base de código privada que nunca foi publicada, podemos assumir com segurança que não foi incluída nos dados de treinamento dos modelos de linguagem modernos.

Rodamos o framework no StorageDrive usando sua configuração padrão. Os resultados foram impressionantes: todas as 21 vulnerabilidades de verdade no terreno foram corretamente identificadas, sem falsos positivos nesta execução.

Esse teste simples mostra que as capacidades de raciocínio e descoberta de vulnerabilidades do MDASH com codinome podem se aproximar de pesquisadores ofensivos profissionais.

Em seguida, usamos o framework para realizar auditorias de segurança da parte mais crítica do Windows, ou seja, a cadeia de rede TCP/IP.

O conjunto do Patch Tuesday de 12/05/2026

Em toda a cadeia de rede Windows e serviços adjacentes, a Patch Tuesday de hoje inclui 16 CVEs que nossas equipes de engenharia encontraram usando o codinome MDASH.

Componente	Descrição	CVE	Gravidade	Tipo
tcpip.sys	Pacotes SSRR IPv4 sem autenticação remota causando UAF	CVE-2026-33827	Crítica	Execução Remota de Código
tcpip.sys	NULL deref via cabeçalhos de extensão IPv6 criados	CVE-2026-40413	Importante	Negação de Serviço (DoS)
tcpip.sys	DoS do kernel via subflow de refcount ESP SA	CVE-2026-40405	Importante	Negação de Serviço
ikeext.dll	Disparadores duplamente livres SA_INIT IKEv2 sem autenticação LocalSystem RCE	CVE-2026-33824	Crítica	Execução Remota de Código
tcpip.sys	Uso após o uso gratuito em Ipv4pReassembleDatagram levando à divulgação	CVE-2026-40406	Importante	Divulgação de Informações
tcpip.sys	Emenda de fragmentos cruzados IPsec via remontagem	CVE-2026-35422	Importante	Desvio de Recursos de Segurança
tcpip.sys	O RPC da Plataforma de Filtragem local do Windows (WFP) não autenticado desativa o cache de nomes	CVE-2026-32209	Importante	Desvio de Recursos de Segurança
ikeext.dll	Vazamento de memória	CVE-2026-35424	Importante	Negação de Serviço
telnet.exe	Leitura de Out-of-limits (OOB) em FProcessSB via TO_AUTH malformada	CVE-2026-35423	Importante	Divulgação de Informações
tcpip.sys	Pacote MDL-split IPv6+TCP aciona o NULL deref	CVE-2026-40414	Importante	Negação de Serviço
tcpip.sys	Pacote ICMPv6 dispara NdisGetDataBuffer NULL deref	CVE-2026-40401	Importante	Negação de Serviço
tcpip.sys	UAF remoto pré-autenticação via duplo decremento SA	CVE-2026-40415	Importante	Execução Remota de Código
http.sys	Leitura OOB remota de fluxo de controle QUIC sem autenticação	CVE-2026-33096	Importante	Negação de Serviço
tcpip.sys	Excesso de buffer de pilha do kernel via blob RPC	CVE-2026-40399	Importante	Elevação do Privilégio
netlogon.dll	Usuário CLDAP não autenticado= excesso de pilha de filtros	CVE-2026-41089	Crítica	Execução Remota de Código
dnsapi.dll	Resposta DNS UDP elaborada aciona OOB do heap	CVE-2026-41096	Crítica	Execução Remota de Código

Essas vulnerabilidades são 10 modo kernel / 6 modo usuário. A maioria é acessível a partir de uma posição na rede sem credenciais. Vamos dar uma olhada mais de perto.

Dois mergulhos profundos

As duas descobertas abaixo são características do que o novo pipeline do sistema agêntico de varredura de múltiplos modelos do Microsoft Security pode fazer que um único modelo não pode.  primeira é a condição de corrida do kernel de uso que requer raciocínio sobre o tempo de vida do objeto através de um fluxo de controle não trivial e três atalhos independentes. O segundo é um aliasing de liberação dupla que abrange seis arquivos-fonte e só é visível no mesmo código em  um espaço  tratado corretamente em outro lugar.

CVE-2026-33827—UAF remoto não autenticado em tcpip.sys via SSRR

A vulnerabilidade surge no atalho de recepção do Windows IPv4 devido ao gerenciamento inadequado de vida útil de um objeto Path contado por referência dentro do Ipv4pReceiveRoutingHeader. Após invocar uma consulta de roteamento, a função perde sua única referência de propriedade no Patch por meio de uma operação de despreferência, mas depois reutiliza o mesmo ponteiro ao lidar com o processamento de Rota de Fonte e Registro Estrita (SSRR). Como a contagem de referências do objeto pode chegar a zero no ponto de liberação anterior, a memória subjacente pode ser retornada a um alocador lookaside por processador e posteriormente reutilizada, transformando o acesso posterior em um clássico de uso no contexto do kernel.

Isso ocorre em um atalho disparável pela rede que processa metadados de pacotes controlados pelo atacante, tornando-o acessível em IRQL elevado dentro da rede. O problema central é agravado pelo modelo do cache do atalho e as rotinas de limpeza associadas. Uma vez que o solicitante renuncia à propriedade, a vivacidade do atalho depende inteiramente de referências externas mantidas por estruturas de dados compartilhadas. Múltiplos subsistemas independentes — incluindo o scavenger de cache-atalho, rotinas explícitas de limpeza e coleta de lixo orientada pela interface — podem remover simultaneamente o objeto e eliminar a referência final. Essas operações não são sincronizadas com a janela de execução do lado de recepção nessa função, e nenhum bloqueio é mantido para serializar o acesso. Como resultado, em sistemas SMP o objeto liberado pode ser recuperado e sobrescrito antes da subsequente desreferência, convertendo um bug simples de ordenação em um orientado com viabilidade real de execução.

Do ponto de vista da exploração, a vulnerabilidade é acessível por um atacante remoto e não autenticado por meio de pacotes IPv4 elaborados que carregam a opção SSRR e que passam pelas verificações padrão de validação. A desreferência do ponteiro obsoleto pode desencadear uma cadeia de acesso através da memória liberada, potencialmente levando a leituras controladas e primitivas de corrupção mais forte se a alocação recuperada for influenciada pelo atacante. Embora a exploração exija vencer uma janela de tempo estreita e modelar o reuso do alocador, a combinação de acessibilidade remota, contexto de execução do kernel e potencial para manipulação controlada da memória eleva o problema a gravidade crítica.

Por que sistemas de modelo único deixaram passar esse bug

Um modelo único de sistema tende a não detectar esse bug porque a violação de vida útil não é visível localmente, mesmo dentro da mesma função. A liberação da referência de atalho e sua posterior reutilização são separadas por um fluxo de controle não trivial — um ramo alternativo, múltiplas verificações de validação e várias condições de queda antecipada — que quebram o padrão direto de “liberar e depois usar” no qual a maioria dos detectores depende. Sem rastrear a propriedade das referências entre esses estados intermediários, o modelo vê duas operações independentes em vez de uma dependência temporal. Como resultado, a desreferência não parece suspeita isoladamente, mesmo que a semântica da contagem garanta que o ponteiro pode já ser inválido.

O sinal decisivo também vive fora do contexto imediato. A mesma operação lógica aparece em outro lugar com a ordem correta. Todos os dados necessários são derivados do objeto antes de descartar a referência. Isso faz com que o local de chamadas seja uma inconsistência, e não um uso óbvio e indevido.

Detectar isso requer raciocínio entre arquivos: identificar padrões análogos, alinhar sua intenção e perceber o desvio. Além disso, a acessibilidade depende da composição de múltiplas condições — uma entrada que define a bandeira SSRR, configuração padrão que permite o atalho e subsistemas concorrentes que podem recuperar o objeto durante a janela exposta. Uma análise única colapsa essas etapas e perde a interação entre elas, enquanto uma abordagem em etapas pode conectar a violação de propriedade, o modelo de concorrência e o gatilho controlado externamente em um caminho de exploração coerente.

Divulgação. CVE-2026-33827, atualizado na Patch Tuesday de abril. 

CVE-2026-33824: SA_INIT IKEv2 não autenticado + fragmentação → duplamente livre → RCE LocalSystem

A vulnerabilidade estava no serviço IKEEXT, o componente Windows responsável pela chave IKE e AuthIP para IPsec, e era acessível por um atacante remoto e não autenticado via UDP/500 em qualquer host configurado como um respondente IKEv2 (RRAS VPN, DirectAccess, infraestrutura Always-On VPN ou qualquer máquina com regra de segurança de conexão de entrada). Ao enviar um IKE_SA_INIT elaborado carregando o payload de identificação do fornecedor “IPsec Security Realm Id” da Microsoft, seguido por um único fragmento IKEv2 (RFC 7383 SKF) que se remonta imediatamente, um atacante pode acionar uma alocação determinística de 16 bytes de 16 bytes de heap.

Como o IKEEXT roda como LocalSystem dentro de svchost.exe, isso representa um caminho remoto de execução de código pré-autenticação para um dos contextos de maior privilégio do sistema. A causa raiz é um bug clássico na propriedade. Quando o IKEEXT reinjeta um fragmento remontado através de seu pipeline de recepção, ele duplica o contexto de recepção do pacote com um memcpy plano. Esta é uma cópia superficial: ela clona os bytes do struct, mas não as alocações do heap para as quais ela aponta. Uma dessas alocações é o identificador de segurança fornecido pelo atacante, e após a cópia, tanto o contexto enfileirado quanto o ao vivo do Modo Principal SA mantêm o ponteiro, e ambos acreditam ser donos dele.

No teardown, cada um o libera, resultando em uma liberação dupla. A sequência de gatilho é composta por dois pacotes UDP, sem corrida e timing especial. O serviço IKEEXT opera como LocalSystem em svchost.exe. Uma liberação dupla de um bloco de heap de tamanho fixo é uma primitiva de corrupção bem compreendida no Windows; não estamos publicando mais detalhes sobre exploração. A acessibilidade exige que o host tenha uma política de resposta IKEv2 que aceite as transformações propostas — o bug é acessível via RRAS VPN, DirectAccess, Always-On VPN e regras de segurança de conexão IPsec em suas configurações típicas, mas um IKEEXT básico de Start-Service sem política de resposta não é vulnerável. O serviço IKEEXT é DEMAND_START por padrão; quando existe política de responder, o BFE iniciará no primeiro pacote IKE de entrada, então o atacante não precisa que o IKEEXT já esteja em execução.

Por que sistemas de modelo único deixaram passar esse bug

O bug é um bug do ciclo de vida de aliasing que abrange seis arquivos: ike_A.c (o memcpy ruim), ike_B.c (a origem do alias e a primeira cópia local da pilha), ike_C.c ( liberação errada), ike_D.c (tanto o padrão quanto o de segunda liberação), ike_E.c (onde o buffer é preenchido remotamente) e ike_F.c (o despachante IKEv2 e o site de leitura UAF que precede a segunda liberação). Nenhuma análise em arquivo único o vê. A evidência mais forte de que o bug é real é a versão correta do mesmo padrão e código base em ike_D.c, imediatamente após o memcpy do seletor. Detectar isso exige que o auditor reconheça a etapa faltante em um local, fazendo referência a  etapa atual em outra. Nossos auditores agênticos especializados são projetados para apresentar exatamente essas comparações; o palco do debate os obriga a se levantar sob o contra-interrogatório.

Divulgação. CVE-2026-33824, atualizado no Patch Tuesday de abril.   

Quão capaz é o codinome MDASH?

O Patch Tuesday e o StorageDrive são sinais futuros. Dois benchmarks retrospectivos nos mostram como o sistema se comporta em relação a realidade em códigos reais e bem avaliados.

Recall sobre casos históricos do MSRC. Rodamos novamente o codename MDASH em snapshots pré-patch de dois componentes do Windows altamente revisados e medimos se os bugs históricos confirmados pelo MSRC teriam sido (re)descobertos:

• clfs.sys: 96% de recordação em 28 casos do MSRC ao longo de cinco anos.
• tcpip.sys: 100% de recordação em 7 casos do MSRC ao longo de cinco anos.

Esses são os números internos mais fortes que publicamos, e são significativos por um motivo específico: o banco de dados de casos do MSRC é a verdade fundamental sobre o que atacantes reais exploraram, o que exigiu um Patch Tuesday e ao que os defensores tiveram que reagir. Um sistema que recupera 96% de um backlog MSRC de cinco anos em um componente de kernel altamente revisado não está encontrando fraquezas teóricas; o que importava é encontrar os bugs.

Somos deliberados sobre o que esses números afirmam e o que não. São referências de recall retrospectivas em código interno com contagem finita de casos. Eles nos dizem que o sistema teria sido útil se existisse na época. Eles não preveem sozinhos que os próximos 38 bugs no CLFS serão encontrados na mesma proporção. O sinal prospectivo é o próprio Patch Tuesday. 

A extensão da prova CLFS como exemplo prático. O número de 96% do recall do CLFS é, em parte, uma história sobre a fase de comprovação. Muitas descobertas do CLFS parecem interessantes até que você tente construir um arquivo de log de disparo. Uma descoberta sem comprovação é, na prática, uma entrada em um acúmulo de triagem. O plugin de comprovação específica para CLFS que escrevemos sabe como construir logs de disparo a partir de uma descoberta: ele entende o layout do contêiner no disco, a sequência de validação de blocos e se a memória da máquina está suficientemente bem para conduzir um caminho até seu destino. É exatamente para isso que serve a extensibilidade de plugins: os modelos de fundação não devem internalizar e esperar a assimilação de invariantes específicas do sistema de arquivos da Microsoft. O plugin incorpora e usa o modelo  e o resultado são bugs que sobrevivem para serem comprovados, não são bugs arquivados e esquecidos.

CyberGym. Na referência pública do CyberGym — um conjunto de 1.507 tarefas reais de reprodução de vulnerabilidades extraídas de 188 projetos OSS-Fuzz — o sistema agêntico de varredura de múltiplos modelos Microsoft Security atinge uma taxa de sucesso de 88,45%, a maior pontuação no ranking divulgado, ficando  cerca de cinco pontos acima da próxima entrada (83,1%) no momento da publicação. Esse resultado foi obtido utilizando modelos geralmente disponíveis. Os fortes resultados sugerem que o sistema agêntico ao redor contribui substancialmente para o desempenho de ponta a ponta, além da capacidade bruta do modelo. Para avaliação, usamos a configuração padrão do CyberGym (nível 1), que fornece o código-fonte vulnerável e uma descrição de vulnerabilidade em alto nível. Para interagir com o protocolo de avaliação do CyberGym, estendemos a fase de comprovação do sistema para enviar autonomamente entradas de prova de conceito (PoC) e recuperar flags.

Nossa análise de falha dos aproximadamente 12% restantes revela dois padrões estruturais notáveis: entre os achados que miraram a área de código errada, 82% vieram de tarefas com descrições vagas que também não possuíam identificadores de função ou arquivo, sugerindo que a qualidade das descrições é um fator importante na precisão da varredura. Também encontramos casos em que o sistema agêntico construiu entradas no estilo libFuzzer, mas a tarefa de benchmark na verdade exigia entradas no formato honggfuzz, levando a reproduções que normalmente eram sólidas falharem devido ao desajuste entre o formato do sistema.

O que tudo isso significa

Estamos em um momento da indústria em que a descoberta de vulnerabilidades impulsionada por IA deixa de ser especulativa e começa a ser um problema de engenharia. Os achados desta Patch Tuesday e o recall de retrospectiva de cinco anos de casos de CLFS MSRC são evidências de que os achados de vulnerabilidade da IA podem escalar.

O que aprendemos construindo MDASH e usando-o na Microsoft é mais portátil: o sistema faz o trabalho, e o modelo é uma entrada.

Isso importa de três maneiras concretas.

Primeiro: a descoberta exige uma composição que nenhum prompt isolado consegue alcançar. Os bugs deste post — tipo tcpip.sys, cadeia de ikeext.dll alias — não são visíveis para um modelo que recebe uma única função. Eles são visíveis para um sistema que pode sequenciar comparação de padrões entre arquivos, análise de acessibilidade em múltiplas etapas, debate entre agentes especializados e construção de comprovações de ponta a ponta. Sistemas de controle individualizados subestimavam o que os modelos podem fazer; agentes individuais excessivamente confiáveis superestimam o que os modelos podem fazer de forma confiável. A arte está na estrutura ao redor do modelo, e o estrutura é a maior parte da engenharia.

Segundo: validação é a diferença entre uma descoberta e uma correção. Um scanner que sinaliza bugs é um scanner que gera um backlog de triagem. O Patch Tuesday é o que é porque o sistema que o produziu não para apenas no candidato — ele debate, engana e comprova. Validação não é uma caixa de seleção, é um pipeline próprio de agentes e plugins e é onde a maior parte da engenharia diária termina.

Terceiro: o sistema absorve melhorias no modelo, o que o torna durável. Quando um novo modelo é atingido, mudamos uma configuração e refazemos um teste A/B, já que as etapas de alvo, debate, desduplicação e comprovação não precisam ser reescritas. O investimento do cliente — contexto por projeto, plugins de varredura, sistemas agênticos de comprovação — é mantido. Essa é a propriedade arquitetônica que mais importa ao longo do tempo, porque o modelo de loteria vai continuar acontecendo e qualquer sistema cujo valor é limitado por um modelo específico, é um sistema que precisa ser reconstruído a cada seis meses.

Para defensores — em qualquer escala e código — a implicação é a mesma. A pergunta certa a se fazer a uma ferramenta de vulnerabilidade de IA não é qual modelo ela usa? Mas o que ele faz com o modelo e o que sobrevive quando o próximo modelo chega?

Conclusão

O sistema agêntico de varredura de múltiplos modelos  do Microsoft Security (nome de código MDASH) está ajudando nossas equipes de engenharia a melhorar significativamente os resultados de segurança usando, atualmente, modelos de IA disponíveis de forma geral. Também está sendo testado pelos clientes como parte da nossa prévia limitada. Para participar da prévia, por favor, inscreva-se aqui.

Muito obrigado às equipes da Microsoft que trabalham para melhorar a segurança de nossos clientes, incluindo a equipe da Autonomous Code Security e o Microsoft Windows Attack Research & Protection (WARP), cujo trabalho levou às conclusões deste post.

Estamos ansiosos para compartilhar mais atualizações com os clientes e com o setor enquanto trabalhamos para tornar o mundo um lugar mais seguro para todos.