ИИ расширяет цепочку поставок
Обеспечение безопасности программной цепочки поставок давно остаётся одной из ключевых задач — в значительной степени из-за ограниченной видимости в системы партнёров и их зависимости. Сегодняшние корпоративные ИИ-системы выводят эту проблему на совершенно новый уровень.
В традиционном ПО цепочка поставок была относительно хорошо понятна: исходный код, сторонние пакеты, системы сборки и целостность артефактов перед релизом. ИИ-приложения значительно расширяют эту поверхность. Одна производственная система может зависеть от размещённых моделей, пайплайнов извлечения данных, оркестрационных фреймворков, внешних инструментов, корпоративных коннекторов и идентификаторов, обеспечивающих связи между всеми этими элементами.
Истинная ИИ-безопасность цепочки поставок подразумевает обеспечение защищённости всех компонентов, от которых зависит ИИ-система: моделей, данных, инструментов, коннекторов и облачной инфраструктуры. Однако многие команды по-прежнему оценивают ИИ-риски преимущественно на уровне модели. В продакшене система шире: она включает саму модель, данные, используемые для обучения, дообучения, привязки и извлечения, оркестрационный слой, маршрутизирующий промпты и вызовы инструментов, инструменты и коннекторы, обращающиеся к внутренним и сторонним системам, облачную инфраструктуру, хостящую и открывающую эти сервисы, а также идентификаторы и секреты, позволяющие одному компоненту вызывать другой.
Новые векторы атак в ИИ-системах
Сравнение с классической цепочкой поставок ПО здесь предельно просто. ИИ-цепочка поставок включает взаимодействия во время выполнения в данных, инструментах и внешних системах. Атаки могут влиять на то, что система извлекает и выполняет. Отравленный источник извлечения может исказить контекст ещё до того, как модель даст ответ. Коннектор с чрезмерно широкими правами может открыть доступ к внутренним системам. Агент на основе модели с повышенными правами может превратить ошибочный ответ в действие в другой системе.
На практике такие сбои обычно начинаются с привычных уязвимостей. Открытый API, связанный с провайдером модели, векторной базой данных или набором данных, может раскрыть промпты, ответы или вспомогательные данные. Коннектор с избыточными правами может позволить ассистенту искать в репозиториях, системах тикетов, мессенджерах или хранилищах документов, к которым доступ никогда не предполагался. Ошибочная конфигурация облачной инфраструктуры может оставить открытыми конечную точку инференса, ноутбук, хранилище или оркестрационный компонент. Смесь рисков может включать теневые ИИ-сервисы, публичные ИИ-конечные точки, открытые хранилища данных и слабо ограниченные права агентов.
MCP и рост рисков подключений
ИИ-системы всё чаще строятся для взаимодействия с внешними системами, а не для работы внутри чат-окна. Это стало проще по мере созревания стандартов и фреймворков. Model Context Protocol (MCP), например, стал открытым стандартом для подключения ИИ-приложений к внешним системам, включая источники данных и рабочие процессы.
На практике это означает, что всё больше ИИ-приложений могут получать актуальную информацию и выполнять задачи в корпоративных средах, что, в свою очередь, создаёт дополнительные риски. Как только модель получает возможность вызывать инструменты, обращаться к внутренним системам и запускать рабочие процессы, риск смещается от качества ответов к доступу и действиям. Архитектура самого MCP отражает это, рассматривая внешний доступ и делегированную авторизацию как ключевые части протокола.
Типичные точки отказа и upstream-риски
Во многих развёртываниях слабым звеном является не сама модель, а слой подключений вокруг неё — место, где инструменты и внешние источники данных встречаются с моделью. Чем полезнее становятся эти системы, тем важнее становится контроль доступа как вопрос безопасности.
OWASP рассматривает уязвимости цепочки поставок и отравление данных как отдельные, но связанные проблемы. Это имеет значение для систем с интенсивным извлечением данных, где внешний контент формирует окружение модели до того, как она сформирует ответ. Если источник отравлен или скомпрометирован, последствия могут не ограничиваться плохим ответом. Они могут затронуть ранжирование, саммари, рекомендации или принятие решений downstream, опирающихся на извлечённый контекст.
В агентных системах эта цепочка может пойти ещё дальше, если агент имеет право вызывать инструменты или запускать рабочие процессы на основе этого контекста. Точка отказа нередко находится на стыке — коннектор с избыточным доступом, секрет, открытый для неправильного сервиса, или извлечение из отравленного контента. Именно поэтому безопасность ИИ — это уже не просто задача качества модели, а полноценная проблема цепочки поставок, требующая нового подхода к защите.