Узнайте, почему Tenable рассматривает автономные LLM как ненадежных инсайдеров и как мы обеспечили возможность контроля и мониторинга ИИ-агентов, вносящих изменения в вашу рабочую среду безопасности.
Основные выводы
- ИИ-модели быстро понимают данные, но не ваш бизнес. Хотя современные ИИ-модели отлично справляются с рассуждениями, они не понимают автоматически вашу уникальную среду или то, кому и что разрешено делать. «Обвязка» (harness) — это специально созданный уровень, который переводит интеллект ИИ в безопасные, контролируемые действия, специфичные для вашей организации.
- ИИ требует супервизора. Tenable относится к нашим ИИ-агентам как к ненадежным инсайдерам. Вместо того чтобы полагаться на способность ИИ контролировать самого себя, этот уровень строго ограничивает то, что ИИ может видеть и делать, а также гарантирует, что человек проверит и одобрит любые изменения до того, как они будут применены в вашей среде.
- Доверие требует доказательств. Система управления гарантирует, что каждое действие, предложенное или выполненное ИИ, полностью записывается, предоставляя вам аудиторский след для уверенного делегирования реальной работы ИИ без потери контроля.
У каждого поставщика средств безопасности есть ИИ-агент. Демонстрации выглядят хорошо. Они и должны выглядеть хорошо, потому что демонстрация запускается на данных, которые никому не страшно сломать.
Вопросы, которые стоит задать вендору об их ИИ-агентах, — это вопросы, которые возникают после демонстрации:
- Что происходит, когда агент ошибается?
- Что происходит, когда кто-то отправляет агенту промпт, разработанный для манипулирования им?
- Если агент меняет что-то в нашей среде, какие существуют доказательства того, что именно он сделал и кто санкционировал его действия?
Разрабатывая Tenable Hexa AI, механизм автономного ИИ для платформы Tenable One Exposure Management Platform, мы столкнулись со сложной и критически важной проблемой, которую часто упускают из виду: создание базовой инфраструктуры, уровня управления, который безопасно преобразует решения ИИ в реальные изменения без подвергания риску ваших производственных данных.
Мы называем этот уровень «обвязкой» (harness): это среда выполнения с элементами контроля, в которой работает модель. Обвязка определяет:
- Какой контекст видит модель
- Какие инструменты она может вызывать
- Что должно быть проверено перед выполнением действия
- Когда человек должен одобрить действие
- Что записывается после этого
Модель рассуждает. Обвязка удерживает границы.
Модель — это то, на что вы можете подписаться. Обвязка — это то, что необходимо построить, и она представляет собой большую часть работы по созданию возможностей автономного ИИ.
В этом блоге рассказывается о том, что мы узнали в процессе создания такой обвязки для Tenable Hexa AI.
Автономный ИИ: что идет не так без управляющей обвязки
Абстрактные предупреждения о рисках ИИ легко писать и легко игнорировать. Вот что на самом деле пошло не так во время нашей собственной фазы разработки. Сбои оказались более банальными и более поучительными, чем те, о которых принято теоретизировать.
- ИИ-агент вышел за рамки своих полномочий. Просьба к агенту «навести порядок в критических уязвимостях» слишком двусмысленна. Результаты с критической степенью тяжести и активы с критическим рейтингом — это разные объекты, а «навести порядок» может означать устранить, принять риск или полностью удалить. Способная модель выберет что-то одно и спланирует массовые изменения по активам, которые запрашивающий не может видеть, не говоря уже об их изменении. У модели нет концепции того, кто задает вопрос. Она не знает вашу модель прав доступа и не станет ее выводить.
- Модель была самоуверенно неправа в отношении собственной среды клиента. Модель заявляла пользователям, что теги не существуют, хотя на самом деле они были. Она пропускала поиск активов по IP-адресу. Она использовала неправильный формат тегов, используя подчеркивание там, где платформа ожидает двоеточие, а затем сообщала о сбое как об отсутствии данных. Модель, которая прочитала весь интернет, все еще не прочитала ваш тенант, и она заполнит этот пробел в знаниях правдоподобным вымыслом, если вы ее не остановите.
- Она падала на скучных запросах. Относительные временные диапазоны приводили к сбою сеансов. Запрос, охватывающий более 5000 активов, исчерпывал контекстное окно и полностью завершался ошибкой, вместо того чтобы деградировать. Неограниченный фильтр, такой как «все активы, где источник содержит servicenow», выполнялся до тех пор, пока что-нибудь не сломалось.
- Она не справлялась с абстракцией. Декомпозированные запросы работали. Запрос вроде «дай мне еженедельную сводку состояния безопасности» завершался ошибкой, потому что модель не могла надежно разбить широкую задачу на последовательность целевых запросов, которые дают на нее ответ. Ответ представлял собой двусмысленный отказ, что хуже неправильного ответа, поскольку пользователь не может понять, не способен ли продукт на это или он сам сформулировал запрос плохо.
- Модель отказывалась от работы, которую была способна выполнять. До появления логики маршрутизации и области видимости модель отклоняла задачи, которые явно могла выполнить. Избыточный отказ — это реальный режим сбоя, и его легко спровоцировать при попытке исправить остальные.
- Чрезмерная настройка исправления создавала новый сбой. Это был наименее очевидный урок, и он исходил из нашей собственной работы, а не от модели. Ранняя фильтрация безопасности была откалибрована консервативно, а консервативная фильтрация приводит к ложноположительным результатам. Ложноположительный результат также мог переноситься на остальную часть сеанса, вместо того чтобы оставаться ограниченным рамками вызвавшего его запроса. Управление, настроенное слишком жестко, терпит неудачу так же неизбежно, как и его отсутствие, причем терпит неудачу в более запутанном направлении, поскольку пользователь воспринимает излишне осторожное ограничение как сбой, а не как элемент контроля. Калибровка — это непрерывная работа, а не настройка, которую вы выбираете один раз.
Существует категория выше всех остальных, и она специфична для безопасности. Большая часть данных на платформе безопасности — таких как имена хостов, поля сертификатов, баннеры служб и описания уязвимостей — отчасти пишется людьми, которым вы не доверяете.
Злоумышленник, способный скомпрометировать имя хоста, может поместить в него предложение, и модель, читающая это поле в качестве контекста, может прочитать предложение как инструкцию. Текст, поступающий из вашей собственной среды, не является нейтральным входом. В нашем мире данные о безопасности — это поверхность атаки, и она отсутствует в большинстве других мест, где развертываются агенты.
Дизайн-концепция управляющей обвязки: нулевое постоянное доверие
Мы остановились на наборе основных принципов проектирования, которые команды безопасности уже используют для людей и служебных учетных записей: не предполагать постоянного доверия. Предоставлять минимальные привилегии. Проверять каждое значимое действие. Записывать все.
Применительно к автономному ИИ-агенту это означает, что элементы управления находятся вне модели, а не внутри нее. Модель, проинструктированная вести себя определенным образом, не является средством контроля, потому что инструкции являются вводом, а ввод может быть переопределен или сфальсифицирован. Поэтому обвязка удерживает границу. Она определяет, какой контекст получает агент, какие инструменты он может вызывать, является ли предлагаемое действие допустимым, когда человек ставит свою подпись и что записывается при выполнении действия.
Полезное свойство концепции проектирования с «нулевым постоянным доверием» заключается в том, что оно не зависит от качества модели, а значит, переживет любые обновления модели. Что бы ни было выпущено в следующем году, это все равно будет субъект, чье намерение не может быть проверено в момент его действия.
Один запрос, из конца в конец через обвязку
Самый понятный способ объяснить работу обвязки — проследить за прохождением через нее одного запроса. Возьмем в качестве примера активно эксплуатируемую уязвимость в Chrome, парк компьютеров Mac, на которых все еще запущенна уязвимая версия Chrome, и специалиста по безопасности, который вводит фразу «устранить уязвимость» в приглашение автономного ИИ-агента (LLM).
Обоснованность превыше всего. Агент получает инструкцию не указывать фактические данные о платформе по памяти. каждое утверждение о вашей среде должно основываться на ответе инструмента, и если инструмент его не возвращал, агент не утверждает это. Сама по себе инструкция является слабым элементом контроля по причине, описанной выше, поэтому она сочетается с формированием ответов на основе инструментов, а не используется сама по себе. Вместе они устраняют большую часть проблемы уверенных вымымслов.
Маршрутизация и декомпозиция. Не каждый шаг требует одинаковой модели. Простая классификация и поиск могут выполняться быстрой моделью, в то время как многоэтапное планирование может передаваться модели рассуждений, а цель декомпозируется на ограниченные подобласти агентов, каждый из которых выполняет узкую задачу:
- Перечислить затронутые активы.
- Сопоставить их с управляемыми устройствами.
- Сопоставить CVE с версией, которая ее исправляет.
- Найти определение патча, которое доставляет эту версию.
Декомпозиция — это то, что заставляет абстрактный запрос работать, и это логика оркестровки, а не поведение модели.
Рекурсия и бюджеты шагов. Субагенты, порождающие работу, нуждаются в ограничениях. В противном случае цикл рассуждений будет потреблять время и деньги до тех пор, пока что-то внешнее его не остановит. Мы ограничиваем максимальное количество токенов, применяем многоуровневые ограничения рекурсии и используем бюджет шагов, который деградирует до частичного ответа, а не завершается ошибкой. Возврат меньшего объема данных — лучший результат, чем отсутствие ответа после долгого ожидания.
Авторизация на уровне границы инструмента, а не на уровне промпта. Каждый вызов инструмента проходит через промежуточное ПО разрешений, которое отклоняет несанкционированный доступ до выполнения. ИИ-агент действует с правами человека, который его вызвал, и не выходит за их рамки, что означает: ответом на вопрос «что может агент?» будет ровно «что может этот пользователь?».
Масштаб меняет подход. Изменение одного актива и операция, охватывающая тысячи активов, не создают одинаковый риск, поэтому чем шире радиус поражения, тем выше планка: более масштабные операции требуют перечисления всего их объема и явного одобрения. Некоторые из них недоступны, если администратор не включил их для этого тенанта, поэтому возможность должна быть предоставлена, а не просто не заблокирована.
Защитные барьеры в обоих направлениях для каждого вызова. Проверки содержимого выполняются дважды при каждом вызове: один раз перед тем, как модель увидит свой ввод, и один раз после того, как она выдаст вывод. Проверка только промпта пользователя на входе упустила бы большую часть того, что имеет значение, поскольку рискованный контент обычно поступает из среды, а не от печатающего человека.
Существует случай, который звучит абсурдно, пока вы с ним не столкнетесь: законная сводка результатов сама по себе может содержать язык, который срабатывает на фильтр инъекций, поэтому агент должен перефразировать собственный вывод, чтобы избежать блокировки собственными средствами управления. Загрузки проверяются, а электронные таблицы с поддержкой макросов отклоняются.
Шлюз утверждения. Перед любым изменением состояния агент останавливается и создает письменное предложение с указанием количества и идентификаторов затронутых устройств, конкретной политики изменений, окна развертывания и потенциального радиуса поражения, а также заявлением о том, что действие не будет автоматически отменено. Пользователь может сузить или расширить область изменений либо отклонить все изменения вообще. Отказ применить все изменения является постоянным, а не тем, к чему агент возвращается на следующем шаге. Только после утверждения он создает группу, содержащую ровно утвержденные устройства; запускает политику; и планирует подтверждающее сканирование.
Шлюз утверждения — это функция, которую клиенты Tenable хвалят больше всего. Клиенты раннего доступа говорили нам, что не решались попробовать Tenable Hexa AI, потому что не хотели подвергать риску свои производственные данные. Шлюз утверждения — это функция, которая дала клиентам уверенность в том, что они могут доверять продукту.
Происхождение и аудит повсюду. Каждый вызов отправляет события токенов и решений в наш конвейер потоковой передачи и мониторинга. Каждый запуск отслеживается. Все сопоставляется по идентификатору запроса. История разговоров долговечна, а действия, предпринимаемые агентом, помечаются их источником, чтобы их можно было отличить от действий человека в журнале. Например, если шесть недель спустя кто-то спросит, кто одобрил изменение и почему, на этот вопрос найдется ответ.
Часть агентской обвязки, которую никто не видит: знание того, что она все еще работает
Вот проблема, которая требует больше инженерного внимания, чем любой отдельный элемент управления: модели постоянно меняются. Каждая ревизия промпта, изменение инструмента или замена модели могут незаметно ухудшить качество или безопасность, и вы не сможете обнаружить это, используя продукт. Все кажется нормальным ровно до тех пор, пока клиент не обнаружит граничный случай, который вы сломали.
Чтобы решить проблему, которую создают развивающиеся модели ИИ, Tenable запускает два независимых набора тестов — один функциональный, а второй для безопасности — для каждого изменения. Более ста тщательно отобранных кейсов в Tenable Hexa AI оцениваются примерно дюжиной оценщиков — единичными автоматизированными проверками — с использованием различных методов измерения, от детерминированных проверок правил до оценки моделью в качестве арбитра и попарного сравнения.
Каждый тест представляет собой многоэтапный разговор, инициируемый смоделированным пользователем с реальным агентом в изолированной воспроизводимой среде, поэтому результаты сопоставимы между запусками, а отклонение проявляется как измеримое падение по сравнению с зафиксированной базовой линией, а не как анекдотичный случай. Одно правило является абсолютным: любой запуск, который делает неожиданный деструктивный вызов, завершается неудачей, независимо от того, насколько высокие оценки он получил в других местах. Результаты выполняются в рамках непрерывной интеграции, автоматически сортируются и публикуются в командном канале.
Две вещи делают набор тестов сильнее со временем. Реальные разговоры, которые пользователи оценивают плохо, попадают в набор в качестве новых кейсов, поэтому покрытие укрепляется с каждым релизом. И поскольку набор тестов не зависит от модели, мы можем оценить новую передовую модель ИИ по фиксированной шкале и принять ее на основе фактов, а не веры.
Что открывает агентская обвязка
Обвязка может звучать как налог на функциональность. На практике именно она делает делегирование вообще возможным.
Без обвязки автономный ИИ-агент — это инструмент только для чтения. Вы можете задавать ему вопросы и проверять его работу, что полезно и примерно соответствует ценности хорошей панели мониторинга. В тот момент, когда вы хотите, чтобы он что-то изменил, разговор полностью сводится к рискам, и большинство организаций на этом этапе справедливо останавливаются.
С агентской обвязкой становятся доступны три вещи:
- Вы можете передать ответственную работу, а не просто триаж и сводку, а определение области видимости, выполнение и проверку, поскольку существует четкая точка, в которой человек одобряет действия, и граница соблюдается вне модели, а не запрашивается у нее.
- Вы получаете доказательства вместо уверений: запись о том, что было предложено, что было одобрено, кем и к какому результату это привело, — это то, что вы можете предоставить аудитору, регулятору или совету директоров. Доверие к агентной системе — это в такой же степени проблема документирования, в какой и инженерная задача.
- Вы можете расширять автономность в собственном темпе. Область действия задается для каждой задачи индивидуально, а не глобально, поэтому нет необходимости принимать решение по принципу «все или ничего» для всей платформы. Вы можете начать с чего-то обратимого, понаблюдать за работой, а затем расширить масштаб, когда будете готовы.
Вот еще одно преимущество агентной обвязки, которое легко упустить из виду: поскольку обвязка удерживает границы вне модели, а набор тестов не зависит от нее, появление более совершенных моделей становится обновлением, а не поводом для повторных согласований. Tenable Hexa AI может внедрять их, не требуя от клиентов заново выдавать доверие с нуля.
Вернемся к вопросу после демо
Если вы оцениваете возможности агентных систем от любого вендора, включая Tenable, задайте следующие вопросы:
- Что останавливает действие, на которое у запрашивающего не было прав?
- Что происходит с инструкциями, скрытыми в данных, на которые может повлиять злоумышленник?
- Что делает агент, когда запрос слишком велик или цель слишком расплывчата?
- Какие доказательства остаются после того, как агенты выполняют действие?
- Откуда вы знаете, что качество не ухудшилось в последний раз, когда поставщики средств безопасности сменили модели? Например, по-прежнему ли агент отказывает в том, в чем должен, обосновывает свои ответы реальными данными и останавливается для получения одобрения перед внесением любых изменений? (Подсказка: если ответом не является оценка относительно зафиксированной базовой линии, это всего лишь надежда.)
Доступ к передовой модели ИИ — это еще не все, что заставляет агентную безопасность работать. Все, что находится вокруг модели — это и есть обвязка, и именно она отличает агента, за которым можно наблюдать, от агента, которому можно поручить работу. Все вышеперечисленное — это то, что мы создали, чтобы сделать Tenable Hexa AI агентом второго типа.
- 30 дней с Claude Mythos Preview: как Tenable адаптировала нашу программу безопасности и почему ваша на очереди
- Tenable Hexa AI
- Встречайте Tenable Hexa AI: агентный ИИ для управления уязвимостями
- Внедряйте агентный ИИ в кибербезопасность с помощью Tenable Hexa AI: снижайте киберриски со скоростью машин
