Microsoft вывела MDASH в Azure Government: как 100 ИИ-агентов проверяют код
8 сентября Microsoft сообщила о развёртывании системы Codename MDASH в Azure Government. Предварительный доступ получили отдельные государственные заказчики США и авторизованные партнёры. MDASH ищет уязвимости не одним большим запросом к модели: над кодовой базой работают более ста специализированных агентов, а отдельная группа перепроверяет, достижима ли найденная проблема и можно ли её воспроизвести. Это существенное отличие от привычного сканера, который сопоставляет код с набором известных шаблонов.
Иллюстрация редакции: агенты исследуют разные участки кодовой базы, а результат проходит общий этап проверки.
Что именно запустила Microsoft
MDASH появился внутри Microsoft Defender и работает с репозиториями, размещёнными в GitHub и Azure DevOps. Система сначала ранжирует файлы по риску: учитывает граф вызовов и сложность кода, чтобы не тратить одинаковые ресурсы на каждую функцию. Затем специализированные агенты ищут отдельные классы ошибок — например, обход авторизации, инъекции или нарушения безопасности памяти. На следующем этапе другие агенты спорят с находкой, проверяют поток данных и пытаются доказать, что уязвимость действительно достижима.
Финальный список очищается от дублей и получает приоритеты. По возможности система прикладывает воспроизводимое доказательство, а не только словесное предположение. Такой конвейер не делает вывод истинным автоматически, но даёт инженеру больше материала для проверки. Подобный принцип мы уже разбирали в гайде по безопасной проверке ИИ-агента: важны журнал действий, ограниченные права и отдельное подтверждение операции с последствиями.
Зачем понадобилось больше ста агентов
Один универсальный агент вынужден одновременно понимать архитектуру проекта, искать десятки классов ошибок, проверять достижимость и оформлять отчёт. Контекст быстро переполняется, а ранняя неверная гипотеза влияет на оставшуюся работу. В MDASH задачи разделены. Один агент изучает конкретный риск, другой пытается опровергнуть вывод, третий помогает объединить похожие результаты. Разногласие здесь не считается помехой: оно показывает, где уверенность системы должна быть ниже.
Microsoft подчёркивает и возможность менять модели внутри общего каркаса. Это практично: модель устаревает быстрее, чем процесс подключения репозитория, хранения результатов и передачи находки разработчику. Но независимость от одной модели не равна независимости от платформы. Сам каркас, данные проверок и интеграции остаются частью Microsoft Defender, поэтому заказчику всё равно нужен план экспорта и ручной маршрут на случай изменения сервиса.
Что говорят цифры — и чего они не доказывают
В официальном сообщении указана оценка 96,55 на публичном бенчмарке CyberGym. Этот результат относится к системе целиком: моделям, агентам, инструментам и способу проверки. Его нельзя переносить на любой репозиторий или трактовать как процент найденных уязвимостей в рабочем продукте. Код на редком языке, собственный фреймворк, сложная сборка и закрытые зависимости меняют задачу.
Бенчмарк также не отвечает на вопрос, сколько ложных срабатываний дойдёт до команды и сколько времени уйдёт на подтверждение. Для практической оценки полезнее взять набор ранее исправленных дефектов и чистых участков, скрыть ответы от системы и измерить три показателя: долю найденных проблем, число ложных тревог и минуты инженера до воспроизводимого вывода. Подход к таким измерениям описан в материале как считать пользу ИИ в разработке.
Почему запуск ограничен государственным облаком
Исходный код критической системы сам по себе является чувствительными данными. Azure Government работает в изолированном контуре и рассчитан на требования американских государственных организаций, включая FedRAMP High. Для обычной компании это не готовая гарантия соответствия её правилам. Нужно отдельно выяснять регион обработки, срок хранения, права сервисной учётной записи и доступ сотрудников поставщика.
Особенно опасен этап подтверждения находки: агент может запускать сборку, тест или специально сформированный ввод. Такие действия должны происходить в песочнице без доступа к рабочей сети и данным клиентов. Автоматическое применение исправления допустимо только после просмотра diff, тестов и возможности отката. Даже хороший отчёт не оправдывает прямую запись в основную ветку.
Что можно взять из MDASH уже сейчас
Большинству читателей недоступен сам предварительный сервис, зато устройство конвейера можно повторить в меньшем масштабе. Разделите поиск и подтверждение: первая модель предлагает кандидатов, вторая получает код и задачу опровергнуть находку, а инженер принимает итог. Ограничьте проверку одним репозиторием и несколькими классами ошибок. Сохраняйте версию модели, запросы, команды и результаты тестов.
Не следует сразу собирать сотню агентов. Для небольшой команды три роли — исследователь, критик и проверяющий — уже покажут, снижает ли разделение труда количество уверенных ошибок. Если вы строите такой контур, сначала закройте типичные атаки через инструкции из файлов и комментариев; этому посвящён наш пошаговый материал о prompt injection.
Редакционный вывод
Новость о MDASH важна не заявлением «ИИ нашёл уязвимость», а переходом к проверяемому многоступенчатому процессу. Microsoft показывает систему, где модели специализируются, спорят, устраняют дубли и по возможности доказывают находку. Это сильнее одиночного чат-запроса, но ответственность никуда не исчезает. До рабочего запуска нужны закрытая песочница, контрольный набор, понятные метрики ложных тревог и инженер, который имеет право отклонить рекомендацию.
FAQ
MDASH уже доступен всем пользователям Microsoft Defender?
Нет. Microsoft говорит о preview для отдельных государственных заказчиков США и авторизованных партнёров. Условия коммерческого доступа в других регионах нужно проверять отдельно.
Система заменяет обычные статические анализаторы?
Скорее дополняет их. Быстрый детерминированный анализ хорошо ловит известные классы проблем, а агентный контур пытается проследить сложный путь данных и проверить достижимость. Практичный процесс объединяет оба типа сигналов.
Можно ли автоматически принимать исправления от агента?
Для рабочего кода это рискованно. Изменение должно пройти просмотр diff, тесты, проверку зависимостей и обычную процедуру ревью. У системы также должен быть технический запрет на запись в защищённую ветку без подтверждения.