MDASH llega al gobierno de EE. UU.: cien agentes revisan el mismo código
Microsoft desplegó Codename MDASH en Azure Government el 8 de septiembre de 2026. No es un lanzamiento general: la cobertura de Nextgov/FCW confirma que la vista previa está limitada a clientes gubernamentales estadounidenses seleccionados y socios autorizados, y que más de cien agentes examinan el mismo software.
MDASH es un escáner de código que distribuye el análisis entre agentes especializados y somete sus resultados a una segunda capa de evaluación. Esa capa contrasta si cada posible fallo es alcanzable y explotable; después, el sistema agrupa duplicados, intenta aportar una demostración y entrega hallazgos priorizados a los equipos de seguridad. La automatización amplía la revisión, pero no sustituye la decisión humana sobre el impacto ni la corrección.
Del descubrimiento a un hallazgo que pueda revisarse
El rasgo distintivo de MDASH no es solo ejecutar muchos análisis a la vez, sino coordinar funciones diferentes sobre un mismo cuerpo de código. Algunos agentes buscan categorías concretas de debilidades; otros discuten los argumentos a favor y en contra de que una alerta represente una ruta de ataque real. El sistema trata así la primera detección como una hipótesis que todavía debe superar varios filtros.
La descripción oficial de MDASH detalla el recorrido: más de cien agentes especializados inspeccionan el código, un segundo grupo evalúa la alcanzabilidad y el peligro de cada candidato, el arnés fusiona resultados equivalentes y, cuando puede, demuestra el fallo antes de remitir una lista depurada y priorizada al equipo de seguridad.
- Descubrimiento: los agentes especializados buscan clases distintas de vulnerabilidades en la misma base de código.
- Debate: agentes críticos intentan confirmar o refutar que el problema pueda alcanzarse y explotarse.
- Deduplicación: el arnés consolida alertas que describen un mismo defecto.
- Demostración: el sistema procura producir evidencia ejecutable, cuando el entorno y el tipo de entrada lo permiten.
- Revisión: el equipo de seguridad valora el contexto, la gravedad y la respuesta adecuada.
Este proceso no convierte cada resultado en una vulnerabilidad definitiva. Una prueba puede fallar por limitaciones del entorno, y una alerta técnicamente válida puede tener un impacto distinto según la configuración o la exposición del sistema. La lista final es una entrada más elaborada para la investigación humana, no una autorización automática para modificar software gubernamental.
La vista previa permanece dentro de Azure Government
MDASH se ofrece en Azure Government como una función de Microsoft Defender y trabaja con modelos disponibles mediante el servicio Microsoft Foundry autorizado para FedRAMP High. Microsoft sostiene que esta configuración mantiene tanto el código fuente de la agencia como la información derivada durante el análisis dentro de una frontera ya aprobada para tratar esos datos.
El alcance de esa afirmación es específico. Describe el procesamiento de MDASH en el entorno gubernamental autorizado; no constituye una garantía sobre cualquier producto de Microsoft, una región comercial de Azure o una integración externa. También importa distinguir el despliegue técnico del acceso: que el sistema ya esté en Azure Government no significa que cualquier suscriptor pueda activarlo.
La vista previa se dirige a determinados clientes del Gobierno de Estados Unidos y socios autorizados. Las organizaciones interesadas deben consultar a su equipo de cuenta de Microsoft. El anuncio no identifica a las agencias participantes, no cuantifica los usuarios admitidos y tampoco fija una fecha de disponibilidad general, por lo que aún no es posible medir el alcance real de la implantación gubernamental.
El benchmark mide una prueba, no el rendimiento de cada agencia
Antes del despliegue gubernamental, Microsoft evaluó la configuración completa de MDASH en CyberGym, un conjunto de 1.507 vulnerabilidades reales conocidas. La actualización técnica de junio atribuyó al sistema un 96,5 % con el criterio «any crash» y documentó 52 casos no resueltos: ocho fallaron en el escaneo, diez en la validación y 34 en la generación de una prueba.
La cifra corresponde a la combinación de modelos, agentes y etapas del sistema bajo las condiciones del benchmark; no debe atribuirse a un agente concreto. Tampoco permite anticipar qué proporción de vulnerabilidades encontrará MDASH en cada repositorio gubernamental. Un banco de pruebas trabaja con casos conocidos y una métrica común, mientras que el software operativo incorpora dependencias, configuraciones, formatos de entrada y lógica de negocio particulares.
La propia distribución de los fallos muestra otra limitación: descubrir una señal no equivale a demostrarla. La generación de pruebas fue el principal cuello de botella en CyberGym, especialmente ante entradas estructuradas, diferencias entre entornos de ejecución y procesos de compilación complejos. Por eso una puntuación alta demuestra capacidad en un conjunto definido, pero no sustituye métricas de producción como falsos positivos, tiempo de revisión o vulnerabilidades confirmadas por los clientes.
Los resultados entran en flujos existentes, con decisión humana
Los hallazgos validados pueden llegar a Microsoft Defender, GitHub Advanced Security y Azure DevOps. Allí pueden priorizarse junto con señales de ejecución, aparecer como alertas de análisis de código, bloquear una compilación o generar trabajo de remediación. La integración reduce el salto entre descubrimiento y corrección, pero no elimina la necesidad de asociar el hallazgo con la versión adecuada, evaluar su impacto y comprobar el parche.
La división de responsabilidades queda clara: los agentes amplían la superficie que puede examinarse y confrontan hipótesis; el arnés coordina, deduplica y ordena; los equipos de seguridad conservan la valoración final. En sistemas vinculados a misiones públicas, incluso una demostración de explotabilidad es evidencia para decidir, no una instrucción automática de despliegue.
Por ahora, el estado confirmado es una vista previa restringida en Azure Government. Microsoft no ha publicado resultados operativos específicos de las agencias, condiciones comerciales, tasas de falsos positivos ni un calendario de disponibilidad general. Esos datos serán necesarios para saber si el desempeño observado en pruebas se mantiene de forma continuada en repositorios gubernamentales diversos.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.