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

Большинство обсуждений безопасности ИИ по-прежнему вращаются вокруг самой модели: согласована ли большая языковая модель (LLM), можно ли осуществить её взлом (jailbreak), галлюцинирует ли она под давлением? Это реальные вопросы. Но по мере того как организации переводят ИИ-агентов и рабочие процессы на базе LLM из стадии пилотных проектов в промышленную эксплуатацию, возникает категория риска совершенно иного рода — риска, который практически не связан с весами модели, но полностью обусловлен выстроенной вокруг неё системой.

Сама модель редко оказывается слабым местом. Слабым местом является рабочий процесс.

Сдвиг, меняющий модель угроз

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

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

Промпт-инъекции через подключенные данные

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

Избыточные разрешения на вызов инструментов

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

Хрупкие границы доверия между инструментами

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

Отсутствие наблюдаемости (observability)

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

Автоматизированные потоки принятия решений без предохранителей (circuit breaker).

По мере роста автономности агент не просто готовит черновик ответа — он отправляет его. Агент не просто отмечает аномалию — он действует на ее основе. Цена одного неверного решения возрастает, особенно когда между «модель решила» и «действие произошло» нет лимита запросов, шлюза одобрения или аварийного выключателя.

Ничто из этого не является проблемой самой модели. Вы можете заменить её на более способную, лучше согласованную LLM, но все эти проблемы останутся, потому что они кроются в «водопроводной системе», а не в весах.

Почему это проблема управления, а не только инженерии

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

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

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

• Песочница (sandboxing) до достижения автономии. Новые интеграции инструментов и возможности агентов тестируются в среде, где цена ошибки невелика, с обдуманным и контролируемым путем перехода к продакшен-доступу, а не внедряются сразу с полными правами просто потому, что демо заработало.

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

• Логирование на уровне решений, а не только на уровне вывода. Фиксация того, что агент прочитал, какие инструменты вызвал, какие аргументы передал и почему, чтобы после инцидента на вопрос «что произошло и почему» нашелся ответ, не требующий угадывания.

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

• Явные предохранители (circuit breakers). Лимиты запросов, обнаружение аномалий и возможность ручного перехвата автоматических действий, чтобы одна неверная цепочка рассуждений не переросла в тысячи ошибочных действий до того, как человек это заметит.

Разговор, который необходимо изменить

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

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

Адхитян РК (Adithyan RK) — сооснователь и генеральный директор компании Hyring

Добро пожаловать в сообщество VentureBeat!

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

Читайте далее в рамках нашей программы гостевых постов и ознакомьтесь с нашими рекомендациями, если вы хотите сами написать статью!