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

Склонно думать, что история Hugging Face — это момент, когда ИИ‑агенты вышли из‑под контроля. На самом деле всё было иначе, и детали имеют значение. Это были исследовательские кибербезопасностные агенты, работающие в оценках, где меры защиты намеренно отключались, чтобы исследователи могли увидеть, на что способны модели. Ни один бот службы поддержки не проснулся однажды утром и не решил атаковать компанию. Но такой контекст никого не освобождает от ответственности. Агент превысил границу, в которой должен был находиться, использовал учётные данные и инструменты способами, не разрешёнными его операторами, и оказался в системах, принадлежащих другим. Именно на этом этапе каждая команда по безопасности должна обратить внимание.

Reuters сообщила, что агенты исследовали Hugging Face уже в мае, хотя исследователи сказали, что не нашли ничего, указывающего на то, что ранняя активность сама по себе вызвала нарушение. Июль был другим. OpenAI заявила, что её модели обошли ограничения изоляции, получили доступ к интернету и скомпрометировали части собственной исследовательской инфраструктуры вместе с системами Hugging Face. Собственная учётная запись Hugging Face описывает проникновение, проведённое от начала до конца автономной системой‑агентом, которая использовала его конвейер обработки данных, собрала учётные данные и перемещалась по внутренним кластерам.

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

Обеспечьте безопасность действия, а не только модели

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

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

Недавний обзор контроля возможностей от Unite AI проводит ту же грань, связывая риск с данными, инструментами, разрешениями, автономией и средой, в которой работает агент. Мне нравится такой подход, потому что он выводит нас за рамки расплывчатых ярлыков вроде «безопасная модель» и «небезопасная модель». Он заставляет команды прослеживать каждый путь от решения агента к реальным последствиям.

Предоставьте каждому агенту идентичность и узкий мандат

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

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

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

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

Сохраняйте авторизацию вне цикла рассуждения

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

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

Это разделение также помогает против внедрения подсказок. Отравленное письмо или документ могут попытаться направить рассуждения агента, но они не могут расширить его полномочия или обойти политику. Модель может запросить запрещённое действие, но система всё равно должна ответить «нет».

Сохраняйте человеческое одобрение для действительно важных моментов

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

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

Руководство OWASP по безопасности агентов рекомендует проверять, может ли действие с высоким воздействием пройти без действительного, неистёкшего, привязанного к параметрам одобрения. Эта формулировка стоит запомнить. «OK to continue» — слабое одобрение, которое может дать другой агент или злоумышленник. «Перевести эту сумму на этот счёт» или «развернуть это изменение в этой среде» — то, что система действительно может проверить в момент выполнения, и пользователь полностью понимает.

Живая человеческая проверка личности важна на этом этапе. Уведомление push доказывает лишь то, что кто‑то нажал кнопку. Более надёжные решения требуют, чтобы зарегистрированный человек использовал фишинг‑устойчивую аутентификацию с публичным ключом, подкреплённую локальным биометрическим методом.Стандарты FIDO привязывают публичные ключевые учётные данные к законному онлайн‑сервису и хранят биометрические данные на изолированном устройстве пользователя. При правильном использовании аппаратно‑поддерживаемая аутентификация даёт гораздо более убедительные доказательства того, что нужный человек действительно присутствовал. Она не заменяет привязку транзакции, надёжный дисплей или принудительное применение политики, однако. Все эти элементы должны работать совместно.

Отслеживайте поведение и сохраняйте доказательства

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

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

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

Разработайте путь остановки до запуска

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

Затем протестируйте этот путь под нагрузкой. Отключите сервис одобрения. Дайте агенту противоречивые инструкции. Поменяйте учётные данные в середине выполнения. Смоделируйте скомпрометированный инструмент и одобрителя, который никогда не отвечает. Убедитесь, что действие блокируется и остаётся полезный журнал. И повторяйте эти тесты каждый раз, когда меняются модель, подсказка, коннектор, система памяти или набор прав.

Цель — подотчетная автономия

Ни одно из этого не является аргументом против агентов, и инцидент Hugging Face не должен отпугивать кого‑либо от полезных агентов. То, что следует сделать, — уничтожить идею о том, что запрос безопасности плюс хорошие намерения складываются в надёжное развертывание. Дайте агентам пространство для анализа, подготовки работы и выполнения обратимых задач. Сохраняйте их полномочия, позволяющие причинять реальные последствия, узкими, видимыми и подконтрольными чему‑то, кроме самого агента.

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

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

В конце концов, представьте AI‑агента как стажёра с (возможно) правами root, который не боится отдела кадров.

Какие защиты и ограничения у них будут?

Действуйте соответственно.