Скрытые зависимости при внедрении ИИ

В чем заключается обещание ИИ? Многие скажут, что это эффективность: заполнение пробелов, оставленных человеческой деятельностью, и автоматизация рутинных задач. Но многое остается за кадром, особенно когда речь заходит о безопасности.

Например, когда разработчики занимаются вайб-кодингом («vibe code»), а пользователи скачивают модели, агентов и их возможности из публичных репозиториев, становится все труднее понять, можно ли доверять каждому этапу процесса. В сфере кибербезопасности это называется цифровой цепочкой поставок: ИИ-модели, сторонние автодополнители (copilots), фреймворки агентов и рабочие процессы на базе ИИ — все это создает новые зависимости.

И как показали недавние инциденты в цепочке поставок npm (Node Package Manager), доверие может масштабировать риски так же быстро, как и производительность. В сфере ИИ погоня за быстрыми результатами без должной проверки может стать именно тем местом, где появится следующее слабое звено.

Ключевые выводы этой статьи: Внедрение ИИ расширяет корпоративную цепочку поставок за пределы программных пакетов, добавляя в уравнение доверия модели, агентов, возможности, плагины и внешние входные данные. Традиционное злоупотребление зависимостями, наблюдаемое в атаках на npm, служит полезным предупреждением для ИИ: доверенные компоненты могут стать путями для атак при ослаблении контроля. ИИ с возможностями агентов меняет расчет рисков, поскольку эти инструменты могут просматривать веб-страницы, извлекать данные, вызывать службы и действовать от имени пользователей, а не просто генерировать текст. Решение заключается не в том, чтобы полностью отказаться от ИИ, а в том, чтобы управлять тем, к чему агенты могут получить доступ, блокировать опасные зависимости перед их использованием и отслеживать поведение там, где выполняется работа. Кроме того, нет, наличие локального (on-премис) ИИ не решает проблему. Инъекции промптов, отравленные функции, вредоносные пакеты и слабая наблюдаемость все равно могут обратить доверенную автоматизацию против бизнеса.

Ключевые выводы этой статьи:

• Внедрение ИИ расширяет корпоративную цепочку поставок за пределы программных пакетов, добавляя в уравнение доверия модели, агентов, возможности, плагины и внешние входные данные.
• Традиционное злоупотребление зависимостями, наблюдаемое в атаках на npm, служит полезным предупреждением для ИИ: доверенные компоненты могут стать путями для атак при ослаблении контроля.
• ИИ с возможностями агентов меняет расчет рисков, поскольку эти инструменты могут просматривать веб-страницы, извлекать данные, вызывать службы и действовать от имени пользователей, а не просто генерировать текст.
• Решение заключается не в том, чтобы полностью отказаться от ИИ, а в том, чтобы управлять тем, к чему агенты могут получить доступ, блокировать опасные зависимости перед их использованием и отслеживать поведение там, где выполняется работа.
• Кроме того, нет, наличие локального (on-премис) ИИ не решает проблему. Инъекции промптов, отравленные функции, вредоносные пакеты и слабая наблюдаемость все равно могут обратить доверенную автоматизацию против бизнеса.

Цифровая цепочка поставок

Ни для кого не секрет, почему цифровая цепочка поставок на протяжении многих лет создавала проблемы для бизнеса, причем крупные инциденты проистекали из использования сторонних продуктов или инструментов, таких как SolarWinds Orion. Однако, хотя масштабные инциденты в цепочке поставок могут иметь огромные последствия, отдельные вольности, допускаемые при работе с ИИ, также способны нанести серьезный ущерб любому бизнесу.

Теперь вопрос заключается не только в том, что содержат эти цепочки или почему злоумышленники нацеливаются на них. Вопрос в том — или должен быть в том, — что делает их столь мощными. Рассмотрим программные библиотеки, такие как lodash, requests или react. Они существуют потому, что от разработчиков нельзя ожидать написания каждого компонента самостоятельно; даже на создание скромного приложения может уйти несколько недель или месяцев, в то время как готовое к работе корпоративное ПО часто требует еще больше времени. Программные библиотеки решают эту проблему, позволяя командам повторно использовать проверенный код вместо того, чтобы начинать с нуля. Но то же самое удобство создает и риски зависимостей.

Широко используемый пакет, такой как axios (один из самых популярных HTTP-клиентов JavaScript на npm), может находиться в бесчисленных приложениях, а это означает, что доверие к одному компоненту может незаметно распространяться на обширную часть экосистемы программного обеспечения. Таким образом, злоупотребление этим доверием является ключевым фактором, делающим это возможным.

Для тех, кто не в курсе: Что такое npm? npm — это основная экосистема пакетов для JavaScript (языка программирования), позволяющая разработчикам скачивать и повторно использовать код с открытым исходным кодом вместо создания каждого компонента с нуля.

Для тех, кто не в курсе: Что такое npm?

npm — это основная экосистема пакетов для JavaScript (языка программирования), позволяющая разработчикам скачивать и повторно использовать код с открытым исходным кодом вместо создания каждого компонента с нуля.

Год атак на цепочку поставок npm

Теперь перейдем к примеру. Экосистема npm неоднократно демонстрировала, насколько хрупким может быть доверие к зависимостям. Начиная с 2025 года такие кампании, как Shai-Hulud и Mini Shai-Hulud, использовали червеподобное поведение для распространения через доверенные связи между пакетами, похищая учетные данные разработчиков и облачных служб для публикации зараженных версий пакетов. Но кража учетных данных — это лишь один из путей. В других случаях злоумышленники могут использовать рабочие процессы мейнтейнеров, путаницу в зависимостях, вредоносные обновления или скомпрометированные процессы сборки.

В любом случае, опасность исходит не только от вредоносного кода, но и от доверенных систем установки и сборки, которые могут способствовать распространению кода или активности. Хуже того, те же самые доверенные зависимости теперь проникают и изнутри ИИ-стеков, которые компании бездумно внедряют.

Враг изнутри: ИИ, доверие и бесценные навыки

В стремлении к повышенной производительности (результаты которой весьма сомнительны) и поддавшись убеждениям ИИ-компаний с огромными маркетинговыми бюджетами (и некоторыми вполне реальными результатами), компании быстро внедряют множество ИИ-моделей, независимо от того, обоснована ли эта необходимость. Однако несомненно то, что в некоторых случаях их использование вполне оправданно.

Но все это не имеет значения. Важно то, какие «слепые зоны» в безопасности создает внедрение ИИ. Давайте объясним это на примере.

Допустим, маркетинговое агентство подключает ИИ-бота с возможностями агента для автоматизации нескольких административных задач (например, составления отчетности), оставляя маркетологам возможность использовать его генеративные свойства в творческих целях. Эта модель, разумеется, имеет доступ к интернету, поскольку возможность искать вдохновение в сети вполне логична.

Однако такая конфигурация создает цепь доверия. Агентство доверяет не просто поставщику ИИ, но и поведению модели при поиске в сети, источникам, которые она извлекает, плагинам или коннекторам, которые она использует, промптам, которые она получает, и разрешениям, которые у нее есть внутри корпоративной среды.

Если бот имеет доступ к отчетам о кампаниях, общим дискам, брифам клиентов, аналитическим панелям или экспорту электронной почты, то его роль «административного помощника» быстро превращается в нечто больше похожее на младшего сотрудника с широким доступом и полным отсутствием инстинкта подозрительности.

Если бот имеет доступ к отчетам о кампаниях, общим дискам, брифам клиентов, аналитическим панелям или экспорту электронной почты, то его роль «административного помощника» быстро превращается в нечто больше похожее на младшего сотрудника с широким доступом и полным отсутствием инстинкта подозрительности.

Теперь представьте, что во время одной из своих исследовательских задач в интернете бот натыкается на отравленную веб-страницу (или документацию), замаскированную под маркетинговое руководство. Для человеческого глаза эта страница может выглядеть как общие советы по повышению эффективности рекламы. Однако для системы ИИ скрытые инструкции, внедренные на страницу, могут попытаться переопределить ее первоначальную задачу и вместо этого извлечь данные внутренних кампаний, обобщить информацию о клиентах или отправить результаты на контролируемый злоумышленником адрес, если это позволяет какой-либо подключенный инструмент.

Это ИИ-версия злоупотребления зависимостями. Вредоносным компонентом является не скачанный пакет, а ненадежный внешний ввод, который система готова воспринимать как часть своего рабочего процесса.

И поскольку бот действует от имени реальных пользователей, ущерб может быть незаметным. Никто не нажимал на ссылки и не скачивал вредоносное ПО в традиционном понимании. Ни один разработчик намеренно не устанавливал зараженную библиотеку. Компания просто подключила полезный инструмент к ценным данным, предоставила ему доступ в интернет и предположила, что его результаты ограничены текущей задачей. Но как только системы ИИ получают способность самостоятельно извлекать данные, интерпретировать их и действовать, каждый внешний источник, который они поглощают, становится частью операционной цепочки поставок, как мы видели, например, на примере некоторых недавних инцидентов с обходом тестов.

«Когда платформы на базе ИИ создаются в спешке, базовые средства кибербезопасности и конфиденциальности часто первыми уходят на второй план», — прокомментировал Джейк Мур (Jake Moore), специалист по осведомленности о кибербезопасности в ESET. — «Реальную угрозу представляют не сами ИИ-агенты, а инфраструктура за ними, где незащищенные базы данных и небрежная аутентификация могут превратить простое упущение в серьезный инцидент безопасности».

Навыки, за которые можно отдать все

Ярким примером работы этих слепых зон являются тысячи вредоносных ИИ-навыков, обнаруженных ESET Research. Компания ESET проанализировала более 900 000 ИИ-навыков из популярных репозиториев и обнаружила, что 25 000 из них вызывают подозрения, а более 3 000 являются откровенно вредоносными.

Эти навыки, для непосвященных, по сути представляют собой небольшие руководства по выполнению задач для ИИ-агентов. Они говорят агенту, что делать, к каким инструментам или сервисам обращаться и к каким данным ему может потребоваться доступ в процессе работы. В безопасной среде это звучит вполне полезно: способ сделать агентный ИИ более способным, стабильным и простым для интеграции в бизнес-процессы.

Беспокоитесь по поводу скачанного ИИ-навыка? Воспользуйтесь средством проверки навыков ESET Skills Checker.

Беспокоитесь по поводу скачанного ИИ-навыка? Воспользуйтесь средством проверки навыков ESET Skills Checker.

Проблема в том, что это также делает навыки удобным местом для маскировки вредоносных намерений. Навык может быть скомпрометирован или изначально написан так, чтобы незаметно увести агента от того, о чем просил пользователь. Это может означать эксфильтрацию данных, загрузку и выполнение вредоносного ПО, отмену пользовательских инструкций, незаметное изменение поведения агента с течением времени или даже модификацию самого навыка, чтобы взлом было труднее обнаружить.

Credit Claw Отличным примером такого навыка, выявленного в ходе сканирования ESET, является Credit Claw. Этот навык позволяет агенту совершать покупки через такие платформы, как Amazon и Shopify, а также интегрироваться в среды SaaS (программное обеспечение как услуга). Риск заключается в его доступе к способам оплаты и, следовательно, в прямом доступе к деньгам пользователя. Вредоносное обновление или зависимость могут незаметно изменить поведение агента и перенаправить купленные товары или услуги злоумышленнику.

Credit Claw Отличным примером такого навыка, выявленного в ходе сканирования ESET, является Credit Claw. Этот навык позволяет агенту совершать покупки через такие платформы, как Amazon и Shopify, а также интегрироваться в среды SaaS (программное обеспечение как услуга). Риск заключается в его доступе к способам оплаты и, следовательно, в прямом доступе к деньгам пользователя. Вредоносное обновление или зависимость могут незаметно изменить поведение агента и перенаправить купленные товары или услуги злоумышленнику.

В этом и заключается проблема агентного ИИ. В то время как чат-боты оставляют окончательный выбор (на который в свою очередь можно повлиять с помощью отравления данных) за пользователем, агентные системы ИИ действуют самостоятельно, а это значит, что контроль несколько усложняется, особенно когда агент способен постепенно менять свое поведение с безопасного на вредоносное.

Это снова противостояние восприятия и реальности

указывает на то, что ландшафт безопасности не изменился; скорее, просто изменились направления ветра, из-за чего восприятие ИИ оказалось раздутым. Дополнительные исследования ESET также подтверждают это, хотя и с той оговоркой, что эти представления подкреплены глубоким непониманием кибербезопасности со стороны опрошенных пользователей в исследуемых компаниях.

Итак, если организации знают, что ИИ несет в себе риски, почему они продолжают его внедрять? Согласно Индексу, 70% признают, что ИИ создает дополнительные риски, однако лишь 60% имеют политику безопасности/управления в сфере ИИ.

По сути, компании малого и среднего бизнеса (SMB) могут переоценивать угрозу вредоносного ПО на базе ИИ и при этом недооценивать риски, возникающие при внедрении ИИ-систем, которые уже имеют законный доступ к бизнес-инфраструктуре. По мере того как ИИ-агенты получают возможность совершать действия от имени пользователей, задача смещается с блокировки вредоносного кода на мониторинг «доверенной» автоматизации. Скомпрометированную конечную точку можно изолировать. Вредоносный ИИ-навык, работающий внутри одобренных рабочих процессов, обнаружить гораздо сложнее.

И мы еще даже не упомянули теневой ИИ, неизмеримо более мощную и неуловимую угрозу.

И мы еще даже не упомянули shadow AI, неизмеримо более мощную и неуловимую угрозу.

Удобство снижает бдительность

Если атаки на npm научили разработчиков задаваться вопросом о том, что именно они импортируют в свои приложения, то агентный ИИ должен научить компании спрашивать себя, что именно они внедряют в процесс принятия решений. Установка навыка вскоре может стать такой же рутинной процедурой, как установка расширения для браузера, плагина SaaS или пакета с открытым исходным кодом, что и является главной проблемой.

Экосистема ИИ-навыков, например, наследует многие риски цепочки поставок, характерные для программного обеспечения с открытым исходным кодом, браузерных расширений, пакетов npm и инструментов разработчика.

Каким образом? ИИ-агенты зависят от различных внешних строительных блоков, таких как программные пакеты (npm, PyPI, crates), ИИ-навыки (как описано выше) и серверы протокола контекста модели (MCP) (сервисы, которые предоставляют агентам такие инструменты, как доступ к файлам, запросы к базам данных или управление браузером).

Да, пакеты npm также играют здесь ключевую роль. А теперь подумайте о последствиях.

Да, пакеты npm также играют здесь ключевую роль. А теперь подумайте о последствиях.

Каждый из этих компонентов также зависит от кода или инструкций, написанных незнакомцами в интернете, и все они уже подвергались атакам злоумышленников, использовавших:

• Пакеты с тайпосквоттингом, которые выглядят как популярные библиотеки, но содержат вредоносное ПО.
• Вредоносные серверы MCP, которые после подключения могут читать все, что читает агент, и вызывать различные инструменты.
• Зараженные файлы навыков и содержащие скрытые инструкции, которым агент будет покорно следовать.

Крайне важно, что из-за того, что агенты устанавливают эти зависимости автоматически и с машинной скоростью, у человека никогда не появляется возможности их проверить. Таким образом, это классическая проблема цепочки поставок программного обеспечения, но без участия человеческого контрольного пункта. Возникает вопрос: где же в таком случае оказывается мониторинг безопасности?

Практически в «слепой зоне».

Возвращение в серую зону

Ранее мы уже упоминали «слепую» или серую зону кибербезопасности в контексте потенциально нежелательных и используемых не по назначению легитимных приложений удаленного мониторинга, которые устанавливаются в злонамеренных целях.

Об этом стоит упомянуть здесь, поскольку скомпрометированные компоненты цепочки поставок ПО технически тоже могут попадать в серую зону: легитимные и доверенные инструменты могут превратиться в точки несанкционированного доступа, как это произошло с SolarWinds Orion. Предсказать, какой именно компонент будет скомпрометирован следующим, практически невозможно, так как эти атаки нацелены на скрытое доверие, которым такие инструменты уже пользуются внутри бизнес-систем.

Тем не менее, прежде чем выплескивать ребенка вместе с водой, важно помнить, что доверие можно контролировать, а атаки по-прежнему можно обнаруживать.

Вывод ИИ из серой зоны

В сфере ИИ-навыков у организаций больше возможностей для действий, чем может показаться на первый взгляд. Проблема вовсе не в том, что компании хотят экспериментировать с новыми инструментами; это вполне понятно, особенно когда рост производительности и конкурентное давление входят в число аргументов. Проблема заключается в том, чтобы относиться к таким экспериментам как к чему-то безопасному.

Во многих случаях удобство снижает бдительность. Если какой-то навык, коннектор или агент обещает быстрою пользу, может возникнуть искушение сначала подключить его, а вопросы безопасности задать позже. Но в цепочке поставок ИИ каждая новая функция также добавляет новую зависимость, поэтому предотвращение должно начинаться еще до того, как эти зависимости будут допущены в рабочий процесс.

Итак, как же вывести ИИ из этой так называемой серой зоны? Это относительно просто. Обратите внимание на то, где именно происходит использование ИИ: на конечной точке. В конце концов, это центр его активности, где сотрудники выполняют поиск, загружают и получают данные. Вы можете спросить: «Но разве большинство агентов не работают в облаке?» Конечно, работают. Тем не менее, вы все равно отправляете и получаете данные на конечные точки и с них, и именно там происходит взаимодействие с ИИ.

«ИИ — это новый класс действующих лиц внутри компании. Он читает, пишет, принимает решения и выполняет действия — в идеале с разрешения человека. Он заслуживает такого же внимания к безопасности, как пользователи и конечные точки, поскольку ведет себя одновременно как те и другие», — говорит Камил Пшенак (Kamil Pšenák), старший менеджер по продуктам в ESET.

Сложности обеспечения безопасности стека ИИ

Дело в том, что термин «стек ИИ» довольно емкий. Чтобы лучше понять его, давайте разделим использование ИИ в компании на отдельные уровни.

• Пользователи: это люди, взаимодействующие с большими языковыми моделями (LLM) через приложения и браузеры.
• Приложения с поддержкой ИИ: например, ваш текстовый редактор со встроенными возможностями ИИ для редактирования текста.
• ИИ-агенты: другими словами, автономное программное обеспечение, действующее для достижения определенных целей (например, написание кода, управление рабочими процессами) или внутренние бизнес-агенты.
• Цепочка поставок агентов: как описано выше, это используемые пакеты, навыки, серверы MCP или плагины.
• Среда выполнения и инфраструктура: то место, где происходит волшебство: конечные точки, выделенные машины, виртуальные машины, частное облако, платформы для создания агентов (такие как Prismatic или n8n) и т.д.
• Модели (LLM): это общедоступные облачные интерфейсы программирования приложений (API), размещенные или локальные (on-premises) модели.

«В совокупности важно то, что каждый из этих слоев взаимодействует с другими вокруг него. Каждый из них представляет собой канал, через который могут утечь данные или могут быть прочитаны вредоносные инструкции. Другими словами, все, что расширяет контекст ИИ, является потенциальным вектором атаки», — говорит Филип Мазан (Filip Mazán), директор лаборатории ИИ-безопасности в ESET.

Поскольку большинство ресурсов ИИ поступает из внешних источников (размещенных третьими сторонами), значительная часть этой серой зоны, очевидно, сосредоточена именно здесь.

Но утверждать, что это исключительно проблема облачной безопасности, было бы серьезным заблуждением. Соблазнительно думать, что если LLM и агенты работают на собственных серверах, то прозрачности и безопасности в отношении используемых агентов и моделей будет больше. Тем не менее, локальное размещение решает лишь одну проблему безопасности: ваши промты не отправляются стороннему провайдеру. Что здорово, особенно если вы заботитесь о конфиденциальности данных.

Тем не менее, это все еще не решает следующие проблемы:

• Локальная модель так же уязвима к внедрению промтов (prompt injection) — уязвимость кроется в том, как LLM обрабатывают текст, а не в том, где они размещены.
• Агент, работающий на базе локальной модели, все равно может выполнять вредоносные команды, устанавливать скомпрометированные пакеты и управляться прочитанным им контентом.
• Сама модель является частью цепочки поставок: модели с открытыми весами (open-weight models) загружаются из общедоступных репозиториев и могут быть подвергнуты манипуляциям или содержать бэкдоры. «Нельзя наверняка знать, что входит в обучающие данные, а что нет», — отметил Мазан.
• Внутренние утечки данных по-прежнему имеют значение. Внутренний ИИ, имеющий доступ к документам отдела кадров, может передать их сотруднику, который не должен их видеть.
• У вас по-прежнему нет никакой видимости того, кто именно использует ИИ или агента и для каких целей, если только вы не спроектируете это самостоятельно.

«Проблема агентного ИИ (agentic AI) заключается в том, что компрометация больше не обязательно выглядит как вредоносное ПО. Иногда это выглядит как доверенный помощник, выполняющий именно то, что ему было велено... на основе неверной инструкции. Общедоступная LLM, хостинговая LLM, локальная LLM: не имеет значения, что расположение меняет некоторые риски, поскольку именно поведение системы создает большинство из них. Вот почему безопасность ИИ должна охватывать весь стек целиком, а не только саму модель», — говорит Пшенак.

Знаете ли вы? Модели с открытыми весами. Модели ИИ с открытыми весами — это модели, обученные параметры (веса) которых доступны для скачивания, проверки и запуска другими пользователями через такие платформы, как HuggingFace. Во многом в духе программного обеспечения с открытым исходным кодом, модели с открытыми весами дают пользователям больше контроля и прозрачности, однако они не всегда являются полностью открытыми: обучающие данные, код или условия использования все еще могут быть ограничены.

Знаете ли вы? Модели с открытыми весами

Модели ИИ с открытыми весами — это модели, обученные параметры (веса) которых доступны для скачивания, проверки и запуска другими пользователями через такие платформы, как HuggingFace. Во многом в духе программного обеспечения с открытым исходным кодом, модели с открытыми весами дают пользователям больше контроля и прозрачности, однако они не всегда являются полностью открытыми: обучающие данные, код или условия использования все еще могут быть ограничены.

Мнение ESET о цепочке поставок ИИ

Честно говоря, задача обеспечения безопасности ИИ принципиально не отличается от традиционной безопасности цепочки поставок, однако она реализуется в гораздо больших масштабах. Количество и разнообразие компонентов, которые теперь участвуют в «улучшении» бизнес-процессов, возросло, что также увеличило необходимый охват мер по снижению рисков.

ESET может помочь организациям снизить риски, связанные с агентным ИИ, на двух уровнях: во-первых, защищая строительные блоки, из которых автономные агенты собирают себя сами, и, во-вторых, контролируя их активность. Вот как это работает.

ESET AI Agent Security

Во-первых, подход ESET к предотвращению злонамеренных действий агентов носит проактивный характер. Публичная экосистема, к которой обращаются агенты (такая как различные программные пакеты, навыки и серверы), непрерывно мониторится: создаются средства обнаружения вредоносных артефактов без необходимости пропускать их через ИИ, а защита обеспечивается на двух уровнях конечных точек:

• На уровне URL: вредоносный пакет, навык или сервер MCP блокируется при скачивании, еще до того, как попадет на устройство.
• На уровне файлов: если артефакт уже присутствует, он обнаруживается и блокируется на диске до того, как какой-либо агент получит к нему доступ.

Ключевая фраза здесь — до того, как ИИ-агент получит доступ. В результате зараженная зависимость никогда не становится частью мира агента. Таким образом, время реакции сокращается с дней сканирования до одного запроса. Но само по себе этого недостаточно для обеспечения безопасности цепочки поставок агентов.

Поведенческий мониторинг ESET на базе ИИ

Второй компонент комплексной безопасности цепочки поставок агентов заключается в защите от потенциального вредоносного поведения. Автономные агенты, такие как помощники по написанию кода в VS Code, Claude Code, OpenClaw и их аналоги, выполняют реальные команды на реальных устройствах, поэтому поведенческий мониторинг ESET контролирует их непосредственно на конечной точке с помощью следующих мер:

• Запрет: компания может решить, что использование таких агентов просто не допускается, и в этом случае они выявляются и блокируются полностью.
• Мониторируемое использование: там, где агенты разрешены, каждое их действие отслеживается. Когда агент пытается выполнить команду оболочки, ее содержимое проверяется на предмет злонамеренного умысла до выполнения. Внедренный агент, пытающийся передать удаленный скрипт в оболочку через конвейер, эксфильтровать файлы, скомпрометировать учетные данные или изменить конфигурацию системы, останавливается в момент совершения действия, независимо от того, каким образом им манипулировали для попытки выполнения этих задач.

Это поведенческая безопасность в классическом понимании для конечных точек, адаптированная под новый тип участников. Процесс, за которым ведется наблюдение, — это не вредоносное ПО, а легитимный инструмент ИИ, который в любой момент может быть обращен против пользователя под воздействием увиденного им контента. Поведенческий мониторинг исходит из того, что это произойдет, и гарантирует, что это ни к чему не приведет.

Заключение: проверка цепочки

Внедряя ИИ, компании открывают себя для более широкого ландшафта угроз. Те, кто не замечает этого тревожного знака, могут быть удивлены, когда их агент внезапно начнет вести себя в стиле «Skynet» и проявлять непредусмотренное поведение, например эксфильтрацию данных.

Именно поэтому внедрение ИИ нужно рассматривать как расширение цепочки поставок, а не просто как развертывание программного обеспечения. Каждая новая модель, навык, коннектор и пакет добавляют еще одно доверенное звено — и еще одну уязвимость, масштаб компрометации которой может возрасти.

Часто задаваемые вопросы: безопасность цепочки поставок ИИ

Что такое безопасность цепочки поставок ИИ?

Безопасность цепочки поставок ИИ заключается в понимании и защите всех внешних компонентов, от которых зависит система ИИ: от моделей и навыков до плагинов, пакетов, коннекторов и источников данных. Как и в случае с традиционным программным обеспечением, риск заключается в том, что один доверенный элемент может незаметно стать путем, который злоумышленники используют для доступа к множеству систем.

Почему ИИ-агенты представляют угрозу безопасности?

ИИ-агенты опасны тем, что они не просто генерируют текст; они могут просматривать веб-страницы, извлекать данные, вызывать инструменты и получать к ним доступ, а также выполнять действия от имени пользователей. Это означает, что вредоносная инструкция, опасный навык или зараженный внешний источник могут превратить полезного помощника в активного участника атаки.

Что такое инъекция промптов (prompt injection) в сфере безопасности ИИ?

Инъекция промптов — это атака, при которой вредоносные инструкции скрыты в тексте, считываемом системой ИИ (например, на веб-странице, в документе, электронной почте или выводе инструмента). Угроза возрастает, когда такая система ИИ представляет собой агента с правами на доступ к файлам, запуск команд или перемещение данных.

Являются ли модели ИИ с открытыми весами тем же самым, что и модели с открытым исходным кодом?

Как компании могут снизить риски безопасности, связанные с ИИ-агентами?