Браузерные ИИ-агенты в пользовательских сессиях остаются неотличимы от человека

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

Компания Token проверила эту проблему на собственном UI-агенте Rehearsal. Это не описание внешней атаки или инцидента: разработчики намеренно создали агента, который изначально не соответствовал трем базовым принципам защиты агентных систем — отдельной идентификации, ограниченным задаче правам и автономной трассировке действий.

Как работает Rehearsal

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

Именно этот доступ делает агента полезным, но одновременно усложняет контроль. Сервер приложения не может отличить клик агента от клика пользователя: в сессионной cookie нет сведений о том, кто фактически управляет сессией.

Что Token ограничила в собственной среде

Token контролирует и Rehearsal, и приложение, в котором он работает. Поэтому компания может передавать приложению сведения об агенте и устранять часть рисков в пределах собственной платформы. В частности, Rehearsal сообщает сервису, что именно он управляет сессией.

Для собственного агента Token применила несколько мер:

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

В реализации Rehearsal панели инструментов доступны агенту только для чтения. Он не сохраняет изменения без одобрения человека, не заполняет поля с секретными данными и не отправляет запросы, которые сама платформа отклонила бы. Назначение элементов интерфейса агент определяет по меткам доступности страницы.

Этот подход применим к агенту, созданному разработчиком самого приложения, но не решает проблему сторонних средств. Token может выдать Rehearsal объект-актор, область полномочий и карту страницы, поскольку контролирует и агента, и приложение. Внешний браузерный агент в CRM или облачной консоли организации обычно такой информацией не располагает. Приложение не знает, что в сессии действует агент, а агент не обязательно способен определить, какое поле содержит секретные данные или какая кнопка удалит запись.

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

Для сопоставления с предыдущими наблюдениями полезен материал «Расширение для claude[.]ai может передать команды в Claude Desktop через Dispatch»; его выводы не следует автоматически переносить на текущий случай без проверки фактов.

Три разрозненных уровня контроля

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

Браузер может сигнализировать, что действия выполняет встроенный агент, и ограничивать его работу. В Chrome функция автоматического просмотра требует подтверждения человека перед чувствительными операциями, включая платежи и массовую рассылку писем. Она также ограничивает агента сайтами, необходимыми для задачи, и отмечает посещенные агентом страницы в истории пользователя. Microsoft позволяет администраторам включать агентский режим просмотра для отдельных сайтов и приостанавливать его перед вводом паролей и номеров банковских карт.

Приложение, со своей стороны, может предоставить агенту действия в виде инструментов. Проект WebMCP, над которым Google и Microsoft работают в сообществе W3C, предусматривает публикацию сайтом вызываемых действий с маркировкой: операция только читает данные или имеет последствия. Такой подход должен избавить агента от необходимости интерпретировать назначение кнопок в пользовательском интерфейсе.

Отдельно развивается Web Bot Auth — проект рабочей группы IETF, позволяющий сайту проверить, какой агент направил запрос. Однако сам проект прямо не охватывает делегирование полномочий: он может назвать агента, но не указывает, от имени какого лица тот действует.

Проблема в том, что каждый уровень владеет лишь частью контекста и не передает ее остальным. Браузер знает о работе собственного агента, но Chrome и Edge не описывают способ сообщить об этом приложению на другой стороне соединения. WebMCP действует внутри пользовательской сессии и с пользовательскими правами, поэтому сам по себе не сужает разрешения агента. Web Bot Auth идентифицирует агента, но не связывает его с человеком, который делегировал ему работу.

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

Что делать до появления стандартов

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

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

Практические рекомендации сводятся к следующему:

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

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