Агенты ИИ должны делать больше самостоятельно. У кого есть время или внимание, чтобы одобрять каждую команду? А наблюдать за тем, как агенты выполняют работу, которую им поручили, — невыносимо скучно.
Но агентам действительно нужны ограничения, особенно в корпоративной среде. Без четких ограничений на то, что они могут делать, агентские потоки, как правило, используют весь доступный доступ.
Вот пример из реальной жизни: разработчик просит своего агента выяснить, почему не выполняется задание по ночному экспорту. Правило команды для агентов простое: они работают с ролями только для чтения. Но у разработчика также есть права администратора для работы по вызову, и оба профиля находятся в одном и том же каталоге ~/.aws/config.
При попытке перезапустить задание агент получает сообщение AccessDenied, поэтому он переключается на профиль администратора, принимает роль и запускает команду aws s3 rm для производственного сегмента, чтобы сначала удалить наполовину записанный экспорт.
Учетные данные действительны. Разработчик может получить права администратора, а администратор может удалять объекты S3. AWS проверяет подпись, а не того, у кого находится ключ, поэтому, насколько известно AWS, это сделал разработчик. Нарушение заключается в том, что агент использовал роль, которую агентам использовать не разрешается. В отличие от намерений, это можно проверить по каждому запросу.
Кто виноват? Разработчик, который не должен был передавать агенту свои учетные данные и позволять ему автоматически подтверждать действия? Производитель ремней безопасности? Это неправильный вопрос. Опять же, агенты должны делать больше самостоятельно, выступая и как разработчик, и как менеджер разработчиков, работающих с ИИ.
Вместо того чтобы возлагать вину, нам нужно знать, где на самом деле можно остановить эту попытку удаления. Существует несколько возможных точек принудительного выполнения, и каждая из них зависит от того, что может видеть элемент управления, что он может блокировать и есть ли у агента другой путь к тому же действию.
Нам нужна автономия с ограничениями, которые мы действительно можем установить
Во-первых, нам нужно определить масштаб проблемы. Постоянно возникает необходимость расширять доступ агентов, и обычно причина имеет смысл сама по себе. Например, задача застревает. Или появляется новая интеграция для сервиса, который содержит часть организационного контекста.
Результат всегда один и тот же: следующая задача начинается с более широким доступом, чем предыдущая.
Второй источник давления — это сам агент. Агенты ищут новые учетные данные, когда те, что у них есть, блокируются, не спрашивая у ответственного человека, можно ли им получить такой доступ.
Такое поведение не зависит от источника инструкций. Злонамеренная подмена запроса может привести к попыткам превысить полномочия, но то же самое может произойти и из-за ошибочных предположений при выполнении санкционированной задачи.
AWS проверяет подпись, а не владельца ключа. Когда агент получает доступ к профилю администратора, запрос выглядит так, будто он исходит от разработчика.
Token Security сопоставляет каждого агента с его владельцем, идентификационными данными и разрешениями, поэтому ваши средства контроля блокируют действия, выходящие за рамки назначенной задачи, и позволяют выполнять остальные.
Четко определите, что именно вы контролируете
Агенты используют вызовы инструментов для получения данных или выполнения действий, поэтому именно здесь контроль имеет наибольшее значение. Тем не менее «вызовы инструмента управления» — это очень грубое правило. Что, если инструмент — это оболочка, которая может запускать SDK? Это также может быть браузер с аутентифицированным сеансом. Если вы разрешаете доступ к инструменту, вы разрешаете доступ и к тому, что за ним стоит.
Чтобы правильно понять, что происходит, нам нужна информация об операции, ее аргументах, учетной записи и ресурсе, к которым осуществляется доступ, а также об используемой идентификации. Для операций с данными нам также нужно понимать, каков результат и куда он направляется.
Для принятия правильного решения о правомерности действия необходимо учитывать множество факторов.
В большинстве агентских фреймворков локальные команды, файловые операции, навыки и делегирование также являются вызовами инструментов. Они важны, потому что определяют, куда приведет выполнение команды. Например, чтение файла ~/.aws/config позволяет агенту найти профиль администратора для использования.
Поэтому критически важно обеспечить соблюдение требований при вызове инструмента, а также принять решение о действии внутри него.
Где можно обеспечить соблюдение требований
Часть ущерба можно предотвратить с помощью логических проверок, которые сопоставляют план или действие с текущей задачей. Но это вероятностный контроль, и некоторые вредоносные инструкции все же пройдут. Не существует хорошей альтернативы надлежащему контролю, который может предотвратить действие.
| Метод | Для чего это полезно | Что я бы проверил, прежде чем полагаться на него | Риск, связанный с его удалением | Стоимость автономии |
| Управляемые настройки агента | Ограничение инструментов, разрешений, режимов утверждения и разрешенных интеграций, связанных с агентом. | Какие клиенты учитывают эти настройки?Могут ли пользователь, проект или агент переопределить их?Настройки модели и усилий могут пытаться ограничить доступ, но по своей сути это поведенческие настройки. | Широкие возможности, если приложение их поддерживает; ограниченные возможности для поведенческих настроек | Низкие, за исключением режимов утверждения, которые требуют больше всего ресурсов |
| Перехватчики во время выполнения | Проверка поддерживаемой операции перед ее выполнением с учетом контекста сеанса агента. | Может ли пользователь или агент изменить или отключить эту функцию? Охватывает ли она альтернативные инструменты и субагенты? Блокирует ли она выполнение, в том числе при ошибках и превышении времени ожидания? | Для каждой операции, в зависимости от событий, которые она отслеживает. | Низкий уровень, если функция автоматизирована, и высокий, если она требует участия человека. |
| Шлюзы | Проверка и блокировка запросов, проходящих через них, с использованием общей политики для всех подключенных агентов. | Какой трафик они видят на самом деле: запросы к модели, инструменты MCP, прямые API или сетевой трафик? Может ли агент получить доступ к той же системе другим способом? | Высокий уровень для маршрутизируемого трафика, низкий для остального | Низкий, так как блокируется только вызов |
| Песочницы | Ограничение файлов, процессов, сетевых маршрутов и учетных данных, доступных агенту. | Что агент может делать в этих рамках? Ограничены ли доступные сервисы нужной учетной записью и операциями или просто разрешенным доменом? | Ограничения касаются не того, что происходит внутри | Средний уровень, так как задачи, требующие внешнего доступа, прерываются |
| Контроль конечных точек | Управление использованием локальных агентов с помощью программного обеспечения для конечных точек или уже развернутого EDR. | Может ли он остановить конкретную операцию или только процесс или хост? Что видно внутри контейнеров или виртуальных машин? Какие размещенные агенты находятся вне его досягаемости? | Только локальные агенты | Высокий уровень, если агент завершает процесс или работу хоста |
| Авторизация учетных данных и целевой службы | Ограничение полномочий, предоставленных агенту, и обеспечение доступа к системе, в которой находится ресурс. | Являются ли учетные данные специфичными для агента и задачи? Существуют ли альтернативные учетные данные? Может ли служба отличить агента от человека или общей учетной записи, за которой он стоит? | Высокий, независимо от источника запроса | Средний, так как ограниченный доступ приводит к зависанию задач и заставляет агентов искать другие варианты |
| Управление на основе API | Изменение настроек агента, удаление разрешений, отзыв учетных данных или сессий, а также отключение доступа на платформах, поддерживающих эти действия. | Когда изменения вступят в силу? Что произойдет с существующими сессиями и кэшированными токенами? Это предотвращение доступа в будущем или ответ после выполнения действия? | В основном после выполнения действия | Ничего, пока оно не сработает |
Эти методы пересекаются и дополняют друг друга. Хук, который вызывает службу политик, и шлюз, который обращается к графу идентификации, справляются с задачей лучше, потому что точки применения и принятия решений находятся там, где они наиболее уместны.
Эта таблица далеко не исчерпывающая, и некоторые из этих методов требуют более тщательного рассмотрения. Возьмем, к примеру, управляемые настройки. Настройки модели и усилий носят поведенческий характер, но в некоторых случаях разрешения — это нечто большее, чем просто просьба «пожалуйста, не выходите из себя».
Например, в Claude Code правила предоставления разрешений соблюдаются самим приложением, а управляемые настройки могут ограничивать возможности пользователя по их изменению. В этом случае контроль осуществляется через файл настроек, но это не делает его менее эффективным.
В случае с хуками основная идея полностью зависит от их расположения в цепочке выполнения. Вы не можете остановить событие, которое уже произошло, а поведение при сбое зависит от типа хука и события.
У шлюзов есть свои сложности, поскольку решения об авторизации они должны принимать на основе того, что видят. Посмотрите на AWS AgentCore, который демонстрирует проверку политик для подключенных инструментов. Обратите внимание, какие вызовы он обрабатывает.
«Песочницы» и ограниченные по области действия учетные данные решают разные проблемы. Надлежащая изоляция может лишить пользователя возможности доступа, в то время как ограниченные по области действия учетные данные ограничивают то, что происходит после предоставления доступа. См. схему аутентификации в «песочнице» от Cloudflare, которая показывает, как добавить учетные данные за пределами «песочницы», чтобы агенту не нужно было знать секретный ключ. Однако для выполнения его операций все равно потребуется авторизация.
Примените ту же политику к размещенному агенту
. Рассмотрим агента службы поддержки, которого попросили обобщить информацию по открытым обращениям. В его коннекторе используется служебная учетная запись, созданная для агентов, которые редактируют и закрывают обращения. Агент решает, что некоторые обращения выглядят решенными, и пытается их закрыть.
Опять же, эта возможность предоставляется учетными данными, и агент действует в рамках своих полномочий. Место, где действие запрещено, — это утвержденная политика агента, разрешающая только чтение.
Чтобы обеспечить соблюдение этой политики, она должна быть доступна для контроля, например: «Этот агент может читать обращения, но любые вызовы, связанные с редактированием или закрытием обращения, будут отклонены, независимо от используемой служебной учетной записи».
Если этот агент находится в хостинговой среде, то средство контроля конечных точек на ноутбуке сотрудника может оказаться бессильным, поскольку все происходит на стороне сервера.
В этом случае вам потребуется сотрудничество с собственными средствами контроля SaaS-платформы, использование инструментального шлюза или более узконаправленной идентификации сервиса. И опять же, все зависит от того, что предоставляет платформа и где выполняются вызовы.
Это подводит нас к пробелам в наших средствах контроля. Идеального средства контроля не существует. Перехватчики не лучше, чем принудительное использование конечных точек, а это, в свою очередь, не лучше, чем «песочница». Все зависит от того, что и где вы развертываете.
| Метод | Агент кодирования на ноутбуке | Агент поддержки на SaaS-платформе |
| Управляемые настройки агента | Работает, если клиент их соблюдает | Только то, что предоставляет поставщик |
| Хуки среды выполнения | На основе событий, предоставляемых средой выполнения | Только если платформа предлагает хуки |
| Песочницы | Ограничение доступа к файлам, сети и учетным данным | Агент работает на серверах поставщика |
| Контроль конечных точек | В пределах досягаемости | Вне досягаемости |
| Шлюзы | Перехватывают вызовы администратора, если трафик AWS проходит через них | Шлюз инструмента перед коннектором |
| Авторизация учетных данных и целевой службы | Недоступность администратора для агента | Учетная запись службы только для чтения для сводных данных |
| Управление на основе API | Отзыв сеанса постфактум | Отключение коннектора постфактум |
Два метода могут предотвратить оба этих сценария до того, как действие достигнет цели: шлюз, отслеживающий соответствующий трафик, и проверка области действия учетных данных на цели.Другие методы в большей степени зависят от того, где работает агент и какие возможности предоставляет среда выполнения.
Прежде всего, необходимо, чтобы агент продолжал работать в рамках утвержденной политики. Режим только для чтения не является полноценным. В зависимости от того, куда направляются выходные данные, они все равно могут содержать конфиденциальную информацию. Анализ изолированности Anthropic объясняет почему.
Выберите то, что вам подходит, а затем протестируйте способы контроля
Скорее всего, вы будете выбирать то, что вам подходит, исходя из особенностей развертывания. Например, для управляемых настроек требуются поддерживаемые клиенты и централизованное администрирование. А без среды выполнения, которая предоставляет доступ к нужным событиям, у вас не будет хуков. Шлюзы заставляют вас направлять трафик через них, а средства контроля конечных точек требуют установки и обслуживания программного обеспечения.
Все это не бесплатно. Средства контроля имеют свои недостатки, требуют обслуживания и должны учитывать постоянно растущий объем работы, выполняемой с помощью искусственного интеллекта.
Возьмем пример с AWS из начала статьи. Блокировка буквальной команды — это начало, но что, если тот же запрос поступает через SDK? С другими учетными данными? Через делегирование?
Требование безопасности о блокировке удаления остается прежним, но путей к его выполнению много.
Кроме того, есть вопрос ценности, и его нужно учитывать не меньше, чем возможности контроля. Насколько велика задержка, вызванная средствами контроля? Как часто кому-то приходится снимать блокировку из-за ложного срабатывания? Снижаем ли мы риски или создаем новые проблемы?
Отчет SACR ARISE посвящен вмешательству в работу системы во время выполнения, делегированию полномочий и решениям на уровне действий. Это должно быть конкретизировано в виде запроса, политики и доказательств того, что произошло, когда агент предпринял эти действия.
Краткое руководство, основанное на том, где работают ваши агенты и что вы там контролируете:
| Где работают ваши агенты | Что вы обычно контролируете | С чего начать | Что добавить |
| Ноутбуки разработчиков и интегрированные среды разработки | Конечную точку, настройки агента, локальные файлы учетных данных | Управляемые настройки, а также хуки, если клиент их поддерживает | Шлюз для трафика облачных API и принудительное использование конечной точки для клиентов, которых вы не можете настроить |
| Собственное облако, CI или контейнеры | Среда выполнения, сетевой исходящий трафик и идентификация рабочей нагрузки | Песочница и учетные данные для каждой рабочей нагрузки агента | Шлюз для исходящего трафика |
| Платформы SaaS | Учетные данные коннектора и настройки администратора платформы | Узкая идентификация сервиса для каждого агента | Управление платформой через API и шлюз для инструментов перед коннекторами, если это позволяет платформа |
Скорее всего, у вас не одно из этих решений. На самом деле у большинства организаций есть все вышеперечисленное, причем элементы управления распределены между разными командами. Во всех этих средах единственным общим знаменателем является идентификация. Поэтому начните с определения области действия учетных данных на целевом устройстве, поскольку от этого зависит охват, где бы ни работал агент. Затем добавьте один источник политики, с которого считываются все точки применения.
Сделайте это, и вы окажетесь в хорошей стартовой позиции.
Автор: Идо Шломо, соучредитель и технический директор Token Security
