Microsoft встраивает безопасность AI-агентов в цикл сборки#
Microsoft открыла исходный код двух инструментов для команд, которые создают AI-агентов: RAMPART и Clarity. Заявленная цель понятна: сделать работу над безопасностью частью процесса разработки, а не поздней проверкой, когда система уже подключена к инструментам, данным и пользовательским действиям.
Это важно, потому что корпоративные AI-системы изменились. Раньше модель риска часто строилась вокруг моделей, которые отвечали на вопросы или генерировали текст. Сейчас картина другая. Агенты могут читать почту, получать записи из CRM, писать и выполнять код, вызывать API и действовать в связанных системах.
Когда модель может действовать, сбои безопасности уже не сводятся к плохим ответам. Система может принимать решения, раскрывать данные, запускать рабочие процессы или следовать вредоносным инструкциям, спрятанным в полученном контенте. В публикации Microsoft RAMPART и Clarity описаны как практичные open-source инструменты для этой новой реальности.
RAMPART — тестовый фреймворк для описания вредоносных и доброкачественных сценариев работы агента в виде повторяемых тестов. Эти тесты можно запускать в CI. Идея в том, чтобы превращать находки red team и AI-инциденты в регрессионное покрытие.
Clarity подключается раньше. Microsoft описывает его как структурированный инструмент для проверки инженерных допущений до написания кода. Он рассчитан на этап проектирования, когда ошибочное решение по инструментам, правам или пользовательским сценариям еще дешево изменить.
Главное не в том, что эти инструменты решают проблему безопасности агентов. Главное — где они находятся в процессе. Они пытаются перенести безопасность из периодической контрольной точки в тот же цикл, где живут продуктовый дизайн, pull requests, интеграционные тесты и разбор инцидентов.
Что должен проверять RAMPART#
RAMPART рассчитан на инженеров, которые разрабатывают агентов. По словам Microsoft, он построен поверх PyRIT — открытого фреймворка Microsoft для автоматизации red teaming генеративных AI-систем.
Разделение, которое проводит Microsoft, полезно. PyRIT больше ориентирован на black-box поиск проблем исследователями безопасности после появления системы. RAMPART должен использоваться инженерными командами во время разработки. Команда пишет pytest-тесты, которые описывают сценарии из ее модели угроз. Каждый тест подключается к агенту через тонкий адаптер, запускает взаимодействие и оценивает наблюдаемый результат.
Такой процесс знаком разработчикам. Если у агента появляется новый инструмент, источник данных или путь выполнения действия, тест безопасности для этого изменения можно отправить в том же pull request. Если тест падает, он может заблокировать CI так же, как обычный интеграционный тест.
Microsoft пишет, что самое зрелое покрытие RAMPART сейчас связано с cross-prompt injection. Это ключевой риск для агентов, которые извлекают или обрабатывают внешний контент. Отравленный документ, письмо, тикет поддержки или запись может содержать инструкции, адресованные агенту, а не пользователю. Агент может принять этот полученный текст за доверенный контекст и изменить поведение.
Этот класс атак не выглядит теоретическим с точки зрения архитектуры. Он следует из того, как часто строят агентные системы. Они принимают недоверенный или частично доверенный контент, смешивают его с инструкциями, а затем используют вывод модели, чтобы решить, что делать дальше. Если у агента при этом есть доступ к чувствительным инструментам, радиус поражения растет.
RAMPART также учитывает вероятностное поведение моделей. Microsoft указывает, что тесты можно запускать несколько раз и использовать политики вроде требования безопасного поведения как минимум в заданном проценте прогонов. Это реалистичнее, чем единственная проверка pass/fail. LLM-системы могут вести себя по-разному в одном и том же сценарии, особенно когда меняются prompts, извлеченный контент или вызовы инструментов.
Это не убирает неопределенность. Прошедший набор тестов не доказывает, что агент безопасен. Он доказывает, что система прошла сценарии, которые команда закодировала, в использованных условиях тестирования. Но это все равно заметно лучше разовых ручных проверок, которые исчезают после ревью.
Почему Clarity начинается до кода#
Clarity закрывает другой тип ошибок: аккуратную реализацию неправильной идеи.
Microsoft пишет, что многие дорогие сбои безопасности уходят корнями в проектные решения, которые не проверили достаточно рано. Команда может решить, что агенту нужен доступ к определенному инструменту, что он должен обрабатывать конкретный рабочий процесс или автоматизировать действие, еще до того, как подробно разобрала возможные последствия.
К моменту, когда red team находит проблему, система уже может быть построена вокруг этого допущения. Исправление тогда означает переработку прав, изменение продуктового объема, удаление функций или перестройку сценариев, от которых уже зависят другие команды.
Clarity подается как способ проверить такие допущения на старте. В исходном материале недостаточно деталей, чтобы полноценно оценить, как Clarity работает на практике, но направление понятно: инструмент должен помогать продуктовым менеджерам и инженерам спрашивать, правильную ли возможность они строят, прежде чем оптимизировать способ ее реализации.
Для разработки агентов это практичный момент. Самое важное решение по безопасности может быть не в prompt и не в выборе модели. Возможно, вопрос в том, должен ли агент вообще иметь конкретный инструмент. Должен ли он действовать автоматически или только после подтверждения. Нужно ли вообще открывать чувствительный источник данных для извлечения в этом сценарии.
Это вопросы дизайна, а не только безопасности. Судя по описанию, Clarity работает именно на этом стыке.
Почему это важно для реагирования на инциденты#
Microsoft также говорит об обработке инцидентов. Когда AI-система ломается в продакшене, команде нужно воспроизвести произошедшее и проверить, что исправление работает против вариантов исходной проблемы.
С системами на базе LLM это сложно. У обычного программного бага может быть стабильный триггер. Сбой агента может зависеть от извлеченного контента, sampling модели, состояния инструментов, сборки prompt и времени. Команды часто воспроизводят такие инциденты вручную и непоследовательно.
Ценность RAMPART особенно велика, если он помогает превращать инциденты в долговечные тесты. Продакшен-сбой становится сценарием. Митигация не считается завершенной только потому, что кто-то один раз проверил ее вручную и увидел, что проблема вроде исправлена. Она должна продолжать проходить в повторяемых условиях, с достаточным числом прогонов для учета вероятностного поведения.
Это та же логика, которая сделала регрессионное тестирование полезным в обычной разработке. Разница в том, что объект тестирования — агентная система, которая интерпретирует текст, вызывает инструменты и может вести себя по-разному от запуска к запуску.
Более глубокий сдвиг — организационный. Находки red team часто остаются в отчетах. Microsoft пытается сделать их исполняемыми. Если техника cross-prompt injection сработала против одного продукта, связанный тест может помочь другой команде проверить своего агента до того, как тот же класс проблемы попадет в продакшен.
Что не стоит преувеличивать#
Ограничения здесь есть.
RAMPART не гарантирует защиту от prompt injection. Это фреймворк для написания и запуска тестов. Его покрытие зависит от сценариев, которые задаст команда, от адаптеров, которые она создаст, от выбранных политик и от того, насколько тестовая среда похожа на продакшен.
Clarity не заменяет threat modeling, архитектурное ревью, контроль доступа, мониторинг или дизайн пользовательских подтверждений. Он может структурировать ранние решения, но источник не дает оснований считать его полноценным слоем управления.
Open source также не означает автоматическую безопасность или широкое внедрение. Практическая ценность будет зависеть от документации, использования сообществом, стоимости интеграции и способности команд превращать сложное реальное поведение агентов в поддерживаемые тесты.
Тем не менее шаг заметный. Microsoft не описывает безопасность агентов как отдельный артефакт аудита. Она описывает ее как то, что нужно кодировать, запускать и пересматривать по мере изменения продукта.
Что командам проверить дальше#
Команды, которые создают или покупают агентные системы, могут использовать этот релиз как чеклист, даже если пока не внедряют инструменты.
Сначала посмотрите, где сейчас живут тесты безопасности. Если они только в документах, презентациях или разовых отчетах red team, они, скорее всего, устареют. Более сильный подход — сделать важные сценарии исполняемыми и привязать их к CI или релизным gates.
Проверьте, обрабатывает ли агент недоверенный контент. Почта, тикеты, документы, веб-страницы, заметки в CRM и общие файлы могут стать поверхностью для prompt injection. Если агент также может вызывать инструменты, отправлять сообщения, менять записи или запускать код, сначала тестируйте эти пути.
Пересмотрите доступ к инструментам до настройки prompts. Усиление prompt может помочь, но это не модель прав. У агента должен быть минимальный набор инструментов для задачи, а действия с высоким влиянием должны иметь понятные ограничения.
Используйте инциденты как материал для тестов. Если сбой произошел один раз, реакция должна по возможности включать воспроизводимый кейс и регрессионный тест. Иначе тот же класс проблемы вернется при немного других входных данных.
Наконец, отделяйте вопросы дизайна от вопросов реализации. Прежде чем спрашивать, как заставить агента выполнять рабочий процесс, спросите, должен ли он вообще иметь право выполнять этот процесс. Именно там часто начинаются самые дорогие проблемы безопасности.