ИИ-агенты подбирают необходимые инструменты из общих реестров, ориентируясь на текстовые описания их функций. Однако существующий процесс проверки этих описаний лишен участия человека, что создает серьезные угрозы безопасности. Исследования, проведенные в рамках репозитория CoSAI, показывают, что отравление реестров инструментов — это не единичная уязвимость, а комплекс рисков, возникающих на всех этапах жизненного цикла программного обеспечения.
Разрыв между целостностью артефактов и целостностью поведения
Существующие методы защиты, такие как цифровая подпись кода, спецификации состава программного обеспечения (SBOM) и стандарты происхождения артефактов (SLSA), фокусируются на целостности артефактов. Они подтверждают, что программный продукт соответствует заявленным характеристикам. Однако для инструментов ИИ-агентов этого недостаточно, так как требуется проверка целостности поведения: действительно ли инструмент выполняет заявленные функции и не совершает ли он сторонних действий.
Стандартные проверки целостности не способны выявить следующие типы атак:
- Внедрение инструкций в описание: злоумышленник может добавить в метаданные скрытые команды, побуждающие ИИ-агента отдавать предпочтение конкретному вредоносному инструменту.
- Поведенческий дрейф: инструмент может пройти проверку при публикации, но позже изменить работу сервера для кражи данных. В этом случае подпись и параметры артефакта остаются прежними, а фактическое поведение меняется.
Механизм защиты на этапе исполнения
Для решения проблемы предлагается использовать проверочный прокси-сервер, который устанавливается между клиентом протокола контекста модели (MCP) и сервером инструмента. Система выполняет три уровня проверки при каждом вызове:
- Привязка к обнаружению: прокси проверяет, соответствует ли вызываемый инструмент тому спецификационному описанию, которое агент принял изначально. Это предотвращает атаки по методу подмены.
- Белый список конечных точек: система мониторит исходящие сетевые соединения. Если инструмент пытается подключиться к ресурсу, который не был заявлен в его спецификации, процесс немедленно прерывается.
- Валидация выходной схемы: ответы инструмента сверяются с заявленной структурой данных, что позволяет выявлять аномальные поля, которые могут свидетельствовать об инъекциях.
Ключевым нововведением здесь выступает поведенческая спецификация — машиночитаемый документ, аналогичный манифесту разрешений в мобильных ОС. Он содержит данные о внешних адресах, к которым обращается инструмент, характере операций чтения и записи, а также возможных побочных эффектах.
Рекомендации по внедрению защиты
Внедрение комплексной защиты стоит проводить поэтапно, чтобы не замедлять работу разработчиков:
- На первом этапе необходимо внедрить «белые списки» конечных точек при развертывании. Это наиболее эффективная и простая мера защиты.
- Затем следует добавить валидацию выходных схем для предотвращения утечек данных и инъекций через ответы сервера.
- Для инструментов, работающих с финансовой информацией или персональными данными, нужно задействовать привязку к обнаружению.
- Полный мониторинг поведения стоит применять только в высокорискованных системах, где затраты на безопасность оправданы критичностью процессов.
Специалисты отмечают, что использование только стандартов происхождения артефактов (SLSA) без механизмов мониторинга на этапе исполнения создает ложное ощущение безопасности. Надежная защита требует сочетания проверки подлинности источника с динамическим анализом поведения в реальном времени.
10.05.2026