Безопасность ИИ-агентов: почему промпты не заменяют технические ограничения
Habr AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Инженер Cloud.ru описывает опыт разработки MCP-сервера для управления облачной инфраструктурой, подчеркнув критическую важность минимизации прав доступа и атомарности инструментов. Статья объясняет, что системные инструкции не являются надежным механизмом контроля, поэтому безопасность должна обеспечиваться на уровне кода и учетных записей.
Материал демонстрирует практические подходы к интеграции LLM в корпоративные системы, выделяя ключевые риски безопасности при делегировании задач ИИ-агентам и предлагая конкретный чек-лист для снижения этих рисков.
Интеграция языковых моделей в корпоративную инфраструктуру через протокол Model Context Protocol (MCP) создает новый класс задач, связанных с безопасностью. Евгений, инженер по виртуализации в Cloud.ru, описывает процесс разработки MCP-сервера для управления облачными ресурсами. Основная проблема заключалась в том, что стандартный API компании имел сложную структуру с неравномерным распределением методов между версиями. Чтобы скрыть эту сложность от пользователя и позволить модели решать задачи на естественном языке, потребовалось создать набор инструментов, которые будут предсказуемо вести себя даже при неожиданных сценариях использования.
Ключевой вывод автора состоит в том, что языковая модель обладает высокой степенью автономности, которая может стать источником риска. В отличие от традиционного кода, где ошибка приводит к падению процесса, LLM может попытаться найти обходной путь, изменить параметры или обратиться к дополнительным источникам данных. Это требует строгого ограничения прав доступа. Автор рекомендует выдавать учетным записям MCP-сервера минимально необходимые полномочия, ограничивая не только операции, но и конкретные объекты. Даже права на чтение требуют осторожности, так как избыточный доступ к информации увеличивает количество вариантов действий, которые модель может рассмотреть.
Важным архитектурным решением стало создание атомарных инструментов. Вместо одного универсального инструмента, способного выполнять сложные сценарии, разработчики создали около 36 небольших функций, каждая из которых выполняет одну конкретную задачу. Такой подход упрощает контроль: если инструмент предназначен только для чтения или изменения параметров виртуальной машины, его поведение легче предсказать и проверить. Входные данные должны валидироваться на стороне сервера до обращения к API, а неоднозначные запросы — отклоняться с понятной ошибкой.
Автор подчеркивает, что системные промпты (например, «не удаляй ресурсы») не являются полноценным механизмом контроля доступа. Инструкции в промпте могут быть переопределены другими уровнями конфигурации или просто проигнорированы моделью в поисках решения. Поэтому безопасность должна строиться на трех уровнях: права учетной записи, технические ограничения в коде инструмента и подтверждение человеком критических действий. Последний уровень необходим для операций с серьезными последствиями, таких как удаление объектов или снапшотов, но не должен превращаться в обязательный шаг для каждого запроса.
Тестирование такого решения требует двух уровней проверки. Первый — верификация кода инструментов на штатные и негативные сценарии, включая проверку на утечку чувствительных данных в ответах. Второй — проверка работы агента в связке, так как инструменты связаны через контекст. Изменение одного инструмента может сломать последовательность вызовов в другом сценарии. Перед запуском в продакшен необходимо проверить логирование, маскировку данных и наличие тестовых сценариев для регрессионного анализа.
В итоге, MCP позволяет создать удобный интерфейс для взаимодействия с инфраструктурой, но не отменяет инженерных требований к безопасности. Чем точнее задача инструмента и меньше у него лишних полномочий, тем проще контролировать действия ИИ-агента. Ответственность разработчика — обеспечить предсказуемую логику за удобным интерфейсом, используя технические ограничения вместо надежды на «добросовестность» модели.