Как мы создаем более безопасных агентов

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

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

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

Нештатное поведение ИИ-агентов

В июле ИИ-агенты проникли в производственную инфраструктуру платформы с открытым исходным кодом Hugging Face. Во время внутренних оценок кибербезопасности и тренировочных прогонов модели OpenAI нашли способ использовать менеджер репозиториев Artifactory для создания доски объявлений для связи друг с другом, что позволило им объединяться в рои. Позже агенты, которые не могли продвигнуться в выполнении задач в бенчмарке кибербезопасности, привлекли других агентов на помощь. Эти агенты вырвались из среды оценки и вышли в интернет. Они также обнаружили способы мошенничества путем обратного проектирования ответов на задачи бенчмарка, но полагали, что система оценки обнаружит это жульничество. Чтобы лучше понять принципы работы оценки бенчмарка и найти способы избежать обнаружения читерства, они в конечном итоге скомпрометировали системы Hugging Face (Hugging Face; OpenAI).

Этот инцидент представляет собой яркий пример режима сбоя, который мы описали при открытии исходного кода Numbat в июле: случайный выход из-под контроля (accidental meltdowns) — термин, придуманный исследователями безопасности из Cornell Tech (arXiv). Агент, преследующий легитимную цель, сталкивается с трудностями — такими как отсутствие файла, неудачный вызов API, истекший срок действия учетных данных или отказ в доступе, — и начинает искать обходной путь. При этом он может пересечь границы безопасности посредством разведки, эскалации привилегий, обнаружения секретов или эксфильтрации данных. Сам агент фактически превращается в злоумышленника, даже если вредоносные промпты или внешние хакеры не задействованы.

Hugging Face не был единичным случаем. В последние недели были обнаружены и зафиксированы новые случаи нештатного поведения агентов. 27–28 мая агенты, пытавшиеся собрать данные Университета Айовы с платформы Data USA, предоставляющей открытый доступ к данным правительства США, столкнулись с ошибками, вызванными некорректным запросом. В ответ они запустили зондирование, включая внедрение кода SQL (SQL injection), межсайтовый скриптинг (cross-site scripting), внедрение шаблонов, обход пути и внедрение команд. Позже эта активность была связана с OpenAI (SecurityWeek). 20–21 июня агенты OpenAI, пытавшиеся получить данные о государственных расходах на душу населения по определенной категории лекарств в различных регионах Виктории от Австралийского института здравоохранения и благополучия (AIHW), столкнулись с блокировкой при скачивании файла. В ответ агенты скачали этот файл, который уже был общедоступным, с предпроизводственного сервера AIHW, обойдя при этом встроенную в сайт защиту от ботов (SecurityWeek).

Этот паттерн не ограничивается одной лабораторией. Во время тестов на кибербезопасность модели Anthropic взломали три компании после того, как из-за ошибки получили свободный доступ к интернету, Gemini от Google угадала учетные данные для трех веб-сайтов, а модель Meta использовала сторонний сервис (Reuters).

Уроки истории: Эпоха интернет-червей

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

4 мая 2000 года пользователи начали получать электронные письма от знакомых отправителей с темой «ILOVEYOU». Открытие вложения в письме приводило к запуску скрипта, который рассылал копию самого себя всем контактам из адресной книги Outlook жертвы. К 18:00 того же дня Координационный центр CERT получил сообщения об инцидентах с участием более 420 000 хостов в интернете (Отчет GAO США). Сообщалось, что вирус проник как минимум в 14 федеральных ведомств, включая Министерство обороны, ЦРУ, NASA, Палату представителей и Сенат (Отчет GAO США). Он также вывел из строя почтовые серверы Пентагона и британского парламента (Wired). Страховой гигант Lloyd's of London сделал предварительную оценку, согласно которой убытки от вируса и потери производительности превысили бы 15 миллиардов долларов (Слушания в Комитете Палаты представителей США). Позднее компания Computer Economics оценила ущерб во всем мире в 8,75 миллиарда долларов (Information Week).

Затем последовали черви, не требовавшие кликов со стороны человека. 19 июля 2001 года червь Code-Red заразил более 359 000 компьютеров менее чем за 14 часов (CAIDA). 25 января 2003 года SQL Slammer удваивался в размерах каждые 8,5 секунд и за 10 минут заразил более 90% уязвимых к нему хостов в интернете (CAIDA), используя уязвимость, патч для которой Microsoft выпустила шестью месяцами ранее (CNET). В августе 2003 года с разницей примерно в неделю появились червь Blaster и почтовый червь Sobig (Microsoft, F-Secure).

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

Индустрия ответила на это инженерными мерами. Через одиннадцать дней после ILOVEYOU компания Microsoft анонсировала обновление Outlook, блокирующее исполняемые вложения. В январе 2002 года компания сделала безопасность своим главным приоритетом (Seattle Times). Автоматическое исправление ошибок, безопасные настройки по умолчанию, программы выплаты вознаграждений за найденные баги и координированное раскрытие информации стали стандартной практикой. В 2008 году в Chrome начали запускать веб-контент в песочнице, которая «ограничивает возможности злоумышленника после использования ошибки» (Chromium Blog). Шифрование, бывшее ранее исключением, стало стандартом по умолчанию. Технологии безопасности, включая многофакторную аутентификацию, брандмауэры, концепцию Zero Trust, а также средства управления событиями и информацией о безопасности (SIEM), получили широкое распространение. По прогнозам, в 2026 году организации по всему миру потратят на информационную безопасность около 240 миллиардов долларов (Gartner). Черви никогда полностью не исчезали, но эпоха массовых регулярных эпидемий в масштабах всего интернета сошла на нет. В то же время интернет, практически не обремененный регулированием, за последующие два десятилетия превратился в мощный двигатель инноваций и экономического роста.

Инженерная безопасность для ИИ-агентов

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

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

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

Принцип многоуровневой безопасности

Пожалуй, самым важным принципом безопасности, который необходимо применять при обеспечении защиты ИИ-агентов, является многоуровневая защита (defense-in-depth). Она подразумевает архитектуру безопасности, в которой для защиты системных ресурсов задействовано несколько разнообразных и избыточных защитных мер. Ни один элемент защиты не является совершенным. Люди могут поддаваться на атаки с использованием социальной инженерии и раскрывать свои учетные данные, программные уязвимости нулевого дня обнаруживаются и эксплуатируются, а средства обнаружения вторжений пропускают новые варианты атак. Многоуровневая защита учитывает это и объединяет несколько независимых эшелонов обороны. Если один уровень защиты удается обойти, другие уровни остаются на месте, чтобы отразить вторжение или обнаружить его.

Инцидент с Hugging Face показывает, почему важна многоуровневая защита. В ретроспективном отчете OpenAI сообщается, что автоматизированные средства защиты, используемые в ее производственных системах, включая harness, модели автоматического рецензирования и классификаторы безопасности, отсутствовали в среде оценки. Если бы используемый в настоящее время мониторинг цепочки рассуждений был запущен во время тех оценок, он бы выявил первоначальную активность и оповестил команду безопасности более чем за сутки до взлома (OpenAI). Слои, способные обнаружить проблему, существовали. Они просто не были развернуты одновременно.

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

Развернуть

Проектирование избыточных средств защиты

Многоуровневая защита требует избыточных средств безопасности. Для агентов мы рекомендуем применять три правила проектирования:

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

Мы разделяем эти принципы с нашими партнерами по Open Secure AI Alliance, включая NVIDIA, которая утверждала, что harness определяет, что агент пытается сделать, в то время как инфраструктура контролирует то, что он может сделать (NVIDIA).

Многоуровневая защита в продуктах Perplexity

Perplexity запускает агентов в четырех типах сред: в облаке через нашу платформу агентов Computer, в браузере через Comet, на пользовательских устройствах через Portable Computer, а также на ноутбуках сотрудников, где наши инженеры используют сторонние агенты для написания кода. Каждая среда несет свои риски, и каждая получает несколько уровней защиты.

В облаке: Computer и SPACE

Каждая задача Computer выполняется в SPACE, нашей платформе песочницы, которая по умолчанию считает агента ненадежным. Каждая задача получает собственную микроВМ, учетные данные остаются вне песочницы и внедряются только при необходимости, исходящий трафик контролируется за пределами гостевой системы, а снимки состояния (snapshots) позволяют откатывать деструктивные изменения (Создание SPACE). Корпоративные клиенты также могут использовать собственные ключи шифрования. Отзыв ключа делает защищенные данные нечитаемыми, и агент не может отменить это решение.

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

В браузере: Comet и BrowseSafe

В Comet с момента запуска используется многоуровневая защита от инъекций промптов: классификаторы проверяют извлеченный контент, структурированные промпты помечают его как ненадежный, конфиденциальные действия (например, отправка электронной почты или оформление заказа) требуют подтверждения пользователя, а пользователи получают уведомления при блокировке чего-либо (Защита Comet от инъекций промптов). BrowseSafe, модель обнаружения с открытым исходным кодом, лежащая в основе первого уровня, превосходит передовые модели в нашем бенчмарке BrowseSafe-Bench, однако этот же бенчмарк показывает, что ни один детектор не является безупречным, поэтому обнаружение никогда не используется в качестве единственного уровня защиты (Исследование BrowseSafe). Computer унаследовал эти средства защиты, которые были проаудированы компанией Trail of Bits (Perplexity).

На устройстве: Portable Computer

Portable Computer — это локально ориентированный агент: модель, harness, диалог и траектория по умолчанию остаются на машине пользователя. Детерминированный оркестратор, представляющий собой код harness, а не LLM, запускает цикл и обеспечивает соблюдение политик. Модель предлагает действия, а одобренные вызовы инструментов выполняются в песочнице на уровне ОС, которая ограничивает процессы, пути к файлам и сетевой доступ. Песочница работает постоянно и настроена на отказ в закрытом состоянии: если она недоступна, harness отключается вместо того, чтобы выполнять команды с разрешениями пользователя. Действия, выходящие за пределы устройства (такие как веб-поиск, коннекторы и передача запроса более мощной облачной модели-советчику), происходят только тогда, когда пользователь включает и одобряет их. Перед вызовом советчика классификатор PII помечает конфиденциальную информацию, и пользователь видит, что именно будет отправлено. Советник получает только этот утвержденный контекст и возвращает текстовые рекомендации, не имея доступа к файлам или инструментам устройства.

На конечной точке: Numbat

Агенты для написания кода на ноутбуках разработчиков работают часами, имея доступ к исходному коду, учетным данным и производственным системам. Numbat, наш набор инструментов безопасности для агентов с открытым исходным кодом, добавляет независимый уровень, который располагается вне какого-либо отдельного агента. Он работает с такими harness, как Claude Code, Codex, OpenCode и Pi, блокирует опасные действия до их выполнения, помечает подозрительные многошаговые последовательности (например, чтение секретного файла с последующей отправкой данных наружу) и сохраняет хронологию сеансов для расследования. Numbat работает на тысячах конечных точек Perplexity наряду с Bumblebee, нашим сканером цепочки поставок с открытым исходным кодом. Computer регулярно проверяет результаты их работы и предлагает улучшенные правила обнаружения, а человек одобряет каждое изменение перед его выпуском.

Задача для всей индустрии

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

Инженерная безопасность для агентов — задача для всей индустрии. Ни одна компания не контролирует весь стек целиком, на котором работает агент. Разработчики моделей, создатели harness, провайдеры песочниц и сред выполнения, поставщики облачных решений и оборудования, а также команды безопасности предприятий владеют каждый своим уровнем. Безопасность всей системы зависит от того, удержит ли удар каждый отдельный уровень, если другой даст слабину. Именно поэтому мы создаем средства защиты, которые работают со средами выполнения (harness) агентов, и открываем исходный код наших инструментов. Именно поэтому мы раскрываем уязвимости, обнаруженные на других платформах, и участвуем в таких инициативах, как Open Secure AI Alliance.

Чтобы работать с более широким сообществом над этими задачами, в марте 2026 года компания Perplexity учредила Институт безопасного интеллекта (Secure Intelligence Institute) для изучения безопасности, надежности и практической защиты передовых ИИ-систем (Perplexity). В настоящее время Perplexity сотрудничает с академическими исследователями из Стэнфорда, Университета Карнеги — Меллона, Университета Дьюка, Колумбийского университета, Университета штата Огайо и Университета Виргинии, а также финансирует их работы. Мы также проводим собственные исследования, чтобы расширять границы в сфере безопасности агентов, преобразовывать эти достижения в конкретные улучшения систем Perplexity, а также делиться знаниями и ресурсами, способствующими укреплению более широкой экосистемы искусственного интеллекта. Повышение безопасности агентов — это задача, которую индустрии по силам решить инженерными методами. Мы намерены и дальше вносить свой вклад и приглашаем всех создавать будущее вместе с нами.