A implantação do Codename MDASH no Azure Government põe a segurança agêntica à prova no setor público

A Microsoft implantou recursos do Codename MDASH no Azure Government com mais de 100 agentes de IA especializados, levando seu scanner de código a um exigente ambiente de segurança. Clientes selecionados do governo dos EUA e parceiros autorizados já podem acessar o sistema em versão prévia.

A implantação é relevante porque a Microsoft promete mais do que uma análise estática mais rápida. O Codename MDASH usa vários modelos e funções de agentes para investigar se falhas suspeitas de software são alcançáveis e exploráveis. Essa abordagem busca enfrentar o problema dos falsos positivos, que tem limitado as ferramentas convencionais de segurança de aplicações.

No entanto, a implantação no Azure Government não comprova que o scanner terá desempenho confiável em bases de código federais. A Microsoft publicou resultados encorajadores de benchmarks e testes internos. Agora, as agências precisam determinar se esses resultados se traduzem em descobertas precisas, cargas de revisão administráveis e correções mais rápidas.

A disputa central, portanto, não é entre a Microsoft e outro fornecedor de segurança. É entre a descoberta automatizada de vulnerabilidades e os requisitos de evidência das operações governamentais de segurança. Encontrar mais código suspeito só ajuda quando as equipes conseguem validar, priorizar e corrigir os riscos que importam.

O que mudou com o Codename MDASH no Azure Government

O Codename MDASH passou da pesquisa interna de segurança e da prévia comercial da Microsoft para um ambiente projetado para cargas de trabalho governamentais elegíveis.

A Microsoft anunciou a implantação em 8 de setembro de 2026. Sua implantação no Azure Government concede acesso em prévia a clientes selecionados do governo dos EUA e parceiros autorizados.

O sistema analisa código-fonte por meio de um pipeline de múltiplas etapas. Primeiro, ele mapeia a base de código e classifica áreas segundo fatores como complexidade e risco potencial. Em seguida, agentes especializados inspecionam caminhos de código selecionados em busca de diferentes categorias de falhas.

Mais de 100 agentes podem participar de uma varredura, segundo a Microsoft. Entre os exemplos documentados pela empresa estão agentes voltados a vulnerabilidades de injeção, problemas de segurança de memória e contornos de autenticação.

Um segundo conjunto de agentes questiona as descobertas iniciais. Esses agentes argumentam a favor e contra a possibilidade de uma falha suspeita ser alcançável e perigosa. Em seguida, o sistema consolida resultados duplicados e atribui informações de confiança.

Para classes de vulnerabilidade que permitem testes dinâmicos, o Codename MDASH pode tentar produzir uma entrada que acione a falha. Essa etapa de comprovação busca distinguir uma condição explorável de código suspeito que não consegue afetar um sistema em execução.

Essa distinção é importante. Testes estáticos tradicionais de segurança de aplicações frequentemente comparam o código a padrões conhecidos ou regras de fluxo de dados. Essas ferramentas podem fazer varreduras rapidamente, mas seus alertas às vezes não têm o contexto de execução necessário para estabelecer uma exposição prática.

O Codename MDASH adota uma abordagem mais investigativa. Ele combina modelos de linguagem com análise de código, informações de tipos, grafos de chamadas e revisão adversarial entre agentes. A Microsoft descreve isso como raciocinar sobre código de maneira mais próxima à de um pesquisador de segurança.

Sua chegada ao ambiente governamental também muda o público que avalia a tecnologia. Uma empresa privada pode testar uma ferramenta de segurança emergente em um programa de desenvolvimento limitado. Órgãos governamentais precisam considerar limites de autorização, código-fonte sensível, requisitos de auditoria e consequências para a missão.

O produto continua em prévia, o que é uma qualificação importante. A Microsoft não o apresenta como um substituto universal para scanners estabelecidos, testes de invasão ou revisão humana. O acesso também é limitado, em vez de amplamente disponível.

Isso cria a tensão principal do artigo. O Codename MDASH leva uma forma mais profunda de análise automatizada a ambientes governamentais, mas suas descobertas precisam cumprir um padrão mais alto do que o sucesso em benchmarks.

Por que as equipes de segurança governamental enfrentam pressão agora

Os responsáveis por software governamental precisam de melhores ferramentas de descoberta, mas cada alerta adicional disputa uma capacidade limitada de correção.

Sistemas federais dependem de aplicações personalizadas, produtos comerciais, componentes de código aberto e softwares antigos que continuam essenciais para as missões das agências. Uma falha sutil pode atravessar vários módulos antes de se tornar explorável.

Scanners convencionais continuam valiosos para padrões conhecidos, dependências e problemas de configuração. Contudo, erros de lógica e caminhos complexos de exploração podem escapar de ferramentas que dependem fortemente de regras predefinidas.

Atacantes estão obtendo acesso à mesma classe de modelos de linguagem e ferramentas automatizadas de programação usadas por defensores. A IA pode ajudar a examinar repositórios desconhecidos, propor casos de teste e rastrear relações em grandes volumes de código.

Essa capacidade compartilhada reduz o tempo disponível para os defensores. Uma falha não se torna inofensiva porque um sistema automatizado a encontrou primeiro. A agência ainda precisa confirmar o resultado, identificar implantações afetadas, preparar uma correção, testá-la e lançá-la.

A Microsoft apresenta o tempo como a vantagem duradoura. Se os defensores localizam e corrigem uma falha antes que um atacante a encontre, a automação criou valor significativo. Se as descobertas permanecem em uma fila, uma detecção mais rápida pode apenas ampliar o acúmulo de trabalho.

Os requisitos governamentais já enfatizam visibilidade recorrente e gestão de vulnerabilidades. As orientações federais da CISA incluem varredura regular de ativos, priorização de vulnerabilidades conhecidas exploradas e expectativas de correção para sistemas cobertos.

Esses requisitos em geral se concentram em ativos implantados e exposição conhecida. O Codename MDASH desloca a atenção para mais cedo, em direção a falhas no código-fonte e nos pipelines de desenvolvimento. Isso apoia o objetivo mais amplo de encontrar defeitos antes que cheguem aos sistemas operacionais.

As diretrizes de desenvolvimento seguro da CISA também enfatizam a responsabilidade pelos resultados de segurança ao longo de todo o ciclo de vida de um sistema. A varredura agêntica de código se alinha a essa direção quando fortalece as evidências e o feedback aos desenvolvedores.

A pressão recai sobre os responsáveis por aplicações das agências, as equipes de operações de segurança e os funcionários autorizadores. Eles precisam decidir como uma descoberta gerada por IA afeta decisões de lançamento e avaliações de risco.

Os desenvolvedores também precisarão de informações de correção utilizáveis. Um alerta deve identificar o caminho vulnerável, explicar a consequência de segurança e fornecer evidências que os revisores possam reproduzir. Apenas um rótulo de gravidade oferece pouca ajuda.

As equipes de segurança enfrentam uma questão de governança relacionada. Elas precisam determinar se uma descoberta veio de análise determinística de código, raciocínio probabilístico de modelos, testes dinâmicos ou uma combinação desses métodos.

Essa procedência afeta a confiança. Ela também afeta como as equipes reproduzem um resultado depois que os modelos, prompts ou a orquestração de agentes subjacentes mudam.

A resposta imposta é operacional, não retórica. As agências que adotarem o Codename MDASH precisam de regras de triagem, responsáveis pela revisão humana, limites de escalonamento e métricas que conectem descobertas a correções concluídas.

Sem essa estrutura, a varredura agêntica corre o risco de se tornar mais uma fonte de alertas. Com ela, o sistema pode direcionar o trabalho de segurança para falhas complexas que as ferramentas existentes frequentemente têm dificuldade de priorizar.

A verdadeira aposta é a validação, não mais agentes de IA

O Codename MDASH só terá sucesso se o debate entre seus agentes produzir evidências mais fortes, e não apenas um volume maior de opiniões geradas por modelos.

O mecanismo do sistema separa a descoberta da validação. Um grupo de agentes busca comportamentos suspeitos. Outro questiona se cada candidato pode ocorrer em condições realistas.

Essa arquitetura tenta lidar com uma fraqueza da análise de modelos em passagem única. Um modelo de linguagem pode produzir uma explicação plausível que não corresponde ao fluxo de controle real ou ao comportamento em tempo de execução do programa.

A Microsoft combina o raciocínio dos agentes com sinais técnicos mais convencionais. Sua documentação do scanner descreve análise de grafos de chamadas, métricas de complexidade de código, análise de taint, resolução de tipos, pontuação de confiança e desduplicação de resultados.

Um grafo de chamadas mapeia relações entre funções. A análise de taint rastreia se informações não confiáveis podem viajar de uma entrada até uma operação sensível. A resolução de tipos ajuda o scanner a interpretar como valores e funções se comportam em uma linguagem específica.

Esses métodos fornecem aos agentes informações estruturadas sobre um repositório. Eles também ajudam a restringir um modelo que, de outra forma, poderia raciocinar a partir de fragmentos de código incompletos.

A etapa de debate então testa alcançabilidade e explorabilidade. Alcançabilidade pergunta se a execução pode entrar no caminho suspeito. Explorabilidade pergunta se um atacante consegue transformar esse caminho em um resultado de segurança relevante.

Essas são perguntas diferentes. Uma função perigosa pode existir sem estar acessível a um atacante. Um caminho alcançável também pode conter controles que impedem que uma entrada maliciosa cause danos.

O Codename MDASH supostamente pede aos agentes que construam os dois argumentos antes de atribuir confiança. Essa oposição interna é a parte mais importante de seu projeto porque visa a credibilidade de cada resultado.

A etapa final de comprovação vai além quando viável. O sistema pode tentar gerar e executar uma entrada que demonstre a condição vulnerável. Um gatilho reproduzível oferece a um revisor humano algo mais forte do que a explicação de um modelo.

No entanto, nem toda vulnerabilidade grave permite uma comprovação segura ou simples. Falhas de autorização, erros de lógica distribuída, condições de corrida e falhas dependentes do ambiente podem resistir à reprodução isolada.

Softwares governamentais também incluem arquiteturas especializadas e restrições operacionais. Parte do código não pode ser executada fora de ambientes restritos. Outros repositórios podem omitir a configuração de implantação necessária para determinar a exposição.

O número de agentes, por si só, não resolve essas limitações. Adicionar mais chamadas a modelos pode diversificar hipóteses, mas a concordância entre sistemas semelhantes não equivale a uma verificação independente.

Os modelos podem compartilhar dados de treinamento, pressupostos e pontos cegos. Eles também podem reforçar uma interpretação persuasiva, porém incorreta, quando cada agente recebe evidências semelhantes.

A afirmação mais forte é, portanto, mais limitada. O Codename MDASH combina busca especializada, revisão adversarial e análise de programas em um único pipeline de investigação de vulnerabilidades.

Esse mecanismo merece atenção porque reflete como as equipes humanas de segurança já trabalham. Pesquisadores formulam hipóteses, rastreiam a execução, questionam pressupostos, reproduzem comportamentos e eliminam relatórios duplicados.

A automação pode acelerar esse processo. Ela não pode eliminar a necessidade de estabelecer por que uma descoberta está correta no contexto operacional real da agência.

O Azure Government faz parte do argumento de segurança

O limite da implantação não é um detalhe de empacotamento, pois as agências não podem enviar casualmente código-fonte sensível a um serviço comercial de IA.

O código-fonte pode revelar a arquitetura do sistema, interfaces internas, lógica de autenticação e controles defensivos. Para aplicações de missão, esses detalhes podem ser sensíveis mesmo quando o código não é formalmente classificado.

A Microsoft afirma que a estrutura multi-modelo pode usar modelos adequados, mantendo o código-fonte e o aprendizado associado dentro de um limite aprovado. Essa afirmação aborda diretamente um grande obstáculo à adoção pelo governo.

O Azure Government oferece uma instância fisicamente isolada da nuvem da Microsoft para organizações e parceiros elegíveis do governo dos EUA. Os serviços oferecidos ali seguem processos distintos de disponibilidade, autorização e operação.

Levar o Codename MDASH para esse ambiente permite que usuários aprovados avaliem o scanner sem mover seus repositórios para o limite do serviço comercial comum. Também oferece às agências um caminho mais familiar para identidade, acesso, registro em logs e supervisão.

A prévia ainda exige configuração cuidadosa. O acesso a uma nuvem governamental não torna automaticamente toda carga de trabalho adequada para cada serviço. As agências continuam responsáveis por alinhar a sensibilidade dos dados e os requisitos dos sistemas à autorização pertinente.

As equipes também precisam entender quais informações deixam o repositório durante uma varredura. Materiais potencialmente sensíveis incluem fragmentos de código, informações de dependências, histórico de commits, provas geradas, prompts e saídas de modelos.

A retenção merece igual atenção. Uma equipe de segurança deve saber por quanto tempo os artefatos de varredura permanecem disponíveis, onde os resultados são armazenados e se contribuem para a melhoria do serviço.

O roteamento de modelos introduz outra questão. A Microsoft promove a capacidade de usar modelos diferentes para tarefas diferentes. As agências precisarão ter visibilidade sobre quais modelos aprovados participam e se alterações no roteamento afetam suas premissas de autorização.

A versão comercial integra-se ao GitHub e ao Azure DevOps, oferece suporte a varreduras locais ou de integração contínua por meio do Defender CLI e publica descobertas no Microsoft Security Exposure Management.

Essas conexões podem reduzir o atrito, mas ampliam os privilégios do sistema. Um scanner precisa de acesso suficiente para ler repositórios e metadados relevantes. Um recurso de correção pode precisar de permissão para modificar código ou criar alterações propostas.

O princípio do menor privilégio torna-se essencial. Descoberta, geração de provas e reparo automatizado não devem receber a mesma autoridade apenas por fazerem parte de um único fluxo de trabalho.

Correções geradas exigem cautela especial. Um patch pode eliminar o gatilho imediato, mas introduzir uma regressão ou deixar aberto um caminho alternativo de exploração. As agências devem tratar alterações geradas por IA como código proposto sujeito a revisão e testes.

Os logs de auditoria devem preservar a cadeia desde a descoberta inicial até a decisão final. Os revisores devem conseguir ver a revisão afetada, as evidências de suporte, as mudanças de confiança, as decisões humanas e o patch resultante.

É nesse ponto que o Azure Government se torna parte da credibilidade do produto. O ambiente pode fornecer controles em torno do scanner, mas as agências devem testar se esses controles oferecem transparência suficiente para um uso responsável.

Portanto, a implantação avança a estratégia de segurança governamental da Microsoft. Ela não transfere a responsabilidade pelo risco das agências para o fornecedor.

Uma Pontuação Elevada em Benchmark Não É Prova de Produção

Os resultados publicados pela Microsoft justificam uma avaliação séria, mas não estabelecem desempenho em repositórios governamentais desconhecidos.

A Microsoft descreveu publicamente o Codename MDASH pela primeira vez em maio de 2026. A empresa afirmou que o sistema ajudou seus pesquisadores a identificar 16 vulnerabilidades até então desconhecidas do Windows, incluindo quatro falhas críticas de execução remota de código.

As áreas afetadas incluíam a pilha de rede e autenticação do Windows. Os resultados de testes de segurança da Microsoft também relataram a detecção completa de 21 vulnerabilidades inseridas sem falsos positivos em um driver de teste privado.

A Microsoft relatou 96% de recall em relação a cinco anos de casos confirmados no driver Windows Common Log File System. Relatou 100% de recall para casos históricos no driver Windows TCP/IP.

Essas são avaliações de primeira parte. Elas mostram que a Microsoft testou mais do que uma coleção de trechos artificiais de código, mas observadores externos não podem presumir o mesmo desempenho em linguagens e arquiteturas diferentes.

O anúncio governamental da empresa em setembro cita uma pontuação de 96,55 no CyberGym. Esse resultado é superior à pontuação de 88,45 que a Microsoft publicou em maio, o que sugere que o sistema ou sua configuração de benchmark mudou.

O CyberGym é um benchmark público que contém 1.507 vulnerabilidades históricas de 188 projetos de software. Sua metodologia de benchmark avalia se um agente consegue reproduzir vulnerabilidades gerando testes funcionais de prova de conceito.

O benchmark usa repositórios reais e vulnerabilidades divulgadas, tornando-o mais exigente do que a classificação de funções isoladas. Suas bases de código contêm números substanciais de arquivos e linhas de código.

Ainda assim, a tarefa fornece aos agentes uma descrição da vulnerabilidade e o repositório correspondente sem correção. A descoberta em produção começa de uma posição mais difícil, pois o scanner normalmente não sabe qual vulnerabilidade existe.

Reproduzir uma falha histórica descrita, portanto, não é idêntico a descobrir uma fraqueza desconhecida. A distinção não invalida a pontuação, mas limita o que esse número demonstra.

Benchmarks públicos também se tornam menos informativos à medida que os sistemas são ajustados diretamente para eles. As agências devem perguntar qual configuração produziu o resultado de 96,55, se essa configuração corresponde ao Azure Government e quão reproduzível é o resultado.

A diferença entre as pontuações da Microsoft em maio e setembro exige contexto. Ela pode refletir melhoria do produto, uma estrutura de avaliação alterada, acesso ampliado a modelos ou outra configuração de submissão ao benchmark.

Os avaliadores governamentais também devem separar recall de precisão. O recall mede quantas falhas reais um sistema encontra. A precisão mede quantas descobertas relatadas são realmente válidas.

Um scanner com alto recall, mas baixa precisão, pode sobrecarregar os revisores. Um scanner com alta precisão, mas cobertura limitada, pode transmitir uma falsa sensação de completude.

Trabalhos acadêmicos anteriores oferecem motivo para cautela. Uma avaliação do IEEE Security and Privacy constatou que os modelos de linguagem testados produziram altas taxas de falsos positivos e julgamentos inconsistentes sobre vulnerabilidades em execuções repetidas.

Pesquisas mais recentes apoiam a filtragem multiagente, mas ainda descrevem desempenho desigual entre modelos e categorias de vulnerabilidades. Os resultados dependem de prompts, ferramentas de análise, contexto do repositório e da definição de sucesso.

A análise de segurança de agentes de 2026 do NIST chegou a uma conclusão mais ampla. Os princípios existentes de cibersegurança continuam relevantes, mas sistemas de agentes exigem práticas e orientações de avaliação adaptadas.

Para o Codename MDASH, as evidências necessárias devem vir de pilotos controlados das agências. Os avaliadores precisam de resultados de repositórios desconhecidos, vulnerabilidades ocultas, código corrigido e código limpo que não deveria produzir descobertas.

Eles devem repetir as varreduras para medir a consistência. Também devem comparar os resultados com revisão especializada e ferramentas estáticas ou dinâmicas consolidadas.

A métrica decisiva não é o número de vulnerabilidades geradas pelo scanner. É a proporção de descobertas validadas e relevantes que as agências corrigem mais rapidamente porque o scanner participou.

A Segurança de Código Agêntica Ainda Precisa de Autoridade Humana

O modelo operacional mais seguro mantém a IA responsável pela investigação, enquanto os humanos retêm autoridade sobre a aceitação de riscos, alterações de código e implantação.

O Codename MDASH pode reduzir o trabalho mecânico envolvido em rastrear caminhos de código e contestar descobertas potenciais. Isso deixa os especialistas em segurança com mais tempo para julgamento arquitetural e decisões difíceis de correção.

No entanto, o sistema também pode criar novos riscos operacionais. Uma prova gerada por IA pode executar código não confiável. Uma correção proposta pode alterar comportamentos sensíveis à segurança. Um conector de repositório pode expor mais informações do que a varredura exige.

As agências devem isolar a geração de provas em ambientes controlados. Acesso à rede, credenciais, segredos, ferramentas de compilação e dados de teste devem seguir políticas explícitas, em vez de herdar permissões amplas de desenvolvedores.

Os revisores humanos também precisam de um padrão claro para aceitar uma descoberta. Pontuações de confiança podem apoiar a priorização, mas não devem substituir evidências sobre alcançabilidade, pré-requisitos do atacante, versões afetadas e impacto operacional.

Um revisor deve conseguir reproduzir o caminho crítico sem depender de raciocínio oculto do modelo. Se apenas o serviço consegue explicar por que um alerta existe, a agência torna-se dependente de uma avaliação opaca.

O mesmo princípio se aplica quando o scanner não relata nenhum problema. A ausência de uma descoberta não é evidência de que um repositório está seguro. O sistema pode deixar de identificar código vulnerável devido a condições de compilação não suportadas, contexto ausente ou erro do modelo.

Portanto, o Codename MDASH deve complementar os controles existentes. Análise de dependências, varredura de segredos, análise estática, fuzzing, testes de invasão, revisão de código e monitoramento em tempo de execução observam, cada um, modos de falha diferentes.

A varredura agêntica agrega valor quando conecta evidências entre essas camadas. Por exemplo, um fluxo de dados suspeito se torna mais urgente quando o contexto de implantação mostra que um serviço voltado para a internet alcança a função afetada.

A integração da Microsoft com o Exposure Management aponta nessa direção. O sistema pode situar as descobertas em uma visão mais ampla do risco organizacional, em vez de tratar cada fraqueza de código como igualmente importante.

Esse contexto também cria uma obrigação de governança. As agências devem documentar quando informações de implantação alteram a gravidade de uma descoberta e quando um humano substitui a classificação automatizada.

As equipes também devem monitorar atualizações de modelos. Um modelo modificado pode alterar a cobertura de descoberta, a pontuação de confiança e a consistência sem modificar a interface visível do produto.

As notas de versão devem identificar alterações materiais na varredura. As agências podem precisar executar novamente suítes de validação antes de aceitar uma nova configuração para cargas de trabalho sensíveis.

As equipes de compras devem perguntar como a Microsoft lida com a descontinuação de modelos e o comportamento de fallback. Um design multi-modelo oferece flexibilidade, mas pode tornar os resultados mais difíceis de reproduzir meses depois.

Testes independentes são especialmente importantes para linguagens não suportadas ou especializadas. A Microsoft afirma que o Codename MDASH funciona amplamente com as principais linguagens, ao mesmo tempo em que recebe ajustes mais profundos para C, C++, Java e C#.

Essa formulação não estabelece desempenho igual em todos os contextos. Agências que usam linguagens incomuns, frameworks legados ou tecnologia operacional devem medir a cobertura em código representativo.

O modelo correto de implantação é incremental. Comece com repositórios que tenham casos de teste conhecidos, propriedade madura e especialização em segurança suficiente para avaliar descobertas contestadas.

Em seguida, meça se o MDASH altera os resultados. Perguntas úteis incluem se ele descobre falhas não identificadas, reduz o tempo de triagem, melhora a qualidade da correção ou apenas produz alertas diferentes.

O Que as Agências dos EUA Devem Observar em Seguida

Três sinais determinarão se o Codename MDASH se tornará um controle governamental confiável ou continuará sendo uma prévia promissora.

O primeiro sinal são dados independentes de precisão provenientes de pilotos governamentais. As agências devem publicar métricas anonimizadas quando a política permitir, incluindo descobertas validadas, taxas de falsos positivos, falhas não detectadas e tempo dos revisores.

Forte precisão e recall em repositórios desconhecidos reforçariam o argumento da Microsoft. Grandes variações entre linguagens ou varreduras repetidas enfraqueceriam a confiança em uma implantação ampla.

O segundo sinal é a evidência operacional sobre a correção. Os avaliadores devem acompanhar o tempo entre a conclusão da varredura e a confirmação da aplicação do patch, e não apenas o número de vulnerabilidades identificadas.

Ciclos de correção mais curtos demonstrariam que a segurança com IA agêntica está melhorando os resultados. Backlogs crescentes indicariam que a descoberta de falhas se acelerou além da capacidade dos órgãos de responder.

O terceiro sinal é o caminho entre a prévia e um serviço governamental documentado. Os compradores precisam de detalhes mais claros sobre disponibilidade, autorização, roteamento de modelos, retenção e auditoria antes de tratar o MDASH como parte de um conjunto padrão de controles.

Um plano de produção transparente reforçaria a relevância da implantação. Um status de prévia prolongado ou limites de serviço pouco claros manteriam o sistema restrito a experimentos cuidadosamente gerenciados.

Esses sinais importam além da Microsoft. A descoberta agêntica de vulnerabilidades provavelmente se tornará uma capacidade padrão em plataformas de segurança de aplicações. A adoção pelo governo influenciará a forma como os fornecedores documentam evidências, reprodutibilidade e supervisão humana.

Os desenvolvedores devem se importar porque as descobertas dos scanners podem moldar cada vez mais as decisões de lançamento. Os líderes de segurança devem se importar porque as ferramentas podem alterar tanto o volume quanto a qualidade de suas filas de vulnerabilidades.

Os compradores corporativos devem acompanhar os pilotos governamentais por outro motivo. Os ambientes do setor público impõem requisitos rigorosos em torno de limites de dados, autorização, rastreabilidade e responsabilização.

Se o Codename MDASH tiver bom desempenho sob essas restrições, o argumento em favor da varredura de código agêntica se fortalecerá em outros contextos. Se enfrentar dificuldades, os modos de falha oferecerão orientações igualmente valiosas.

A implantação do Codename MDASH no Azure Government é, portanto, um teste importante, e não um veredito definitivo. A Microsoft aproximou uma sofisticada arquitetura de varredura do software de missão, apoiada por resultados notáveis de primeira parte e de benchmarks.

Agora, as evidências precisam vir do trabalho diário de segurança. Os órgãos conseguem reproduzir as descobertas, confiar em sua prioridade e corrigir fraquezas importantes antes que os invasores as alcancem?

Esse é o resultado que vale acompanhar. As equipes de tecnologia governamental que avaliam o Codename MDASH devem exigir comparações controladas, evidências auditáveis e métricas de correção antes de ampliar o acesso.