Rehearsal создавали для платформы Token, чтобы отвечать на вопросы не одними инструкциями, а действиями: агент открывает страницы, настраивает фильтры и заполняет формы. Для этого он работает в браузере пользователя и наследует его права. Сервер видит клики, но не может отличить их от действий человека: файл cookie подтверждает сессию, а не то, кто именно ею управляет.
Этот опыт выявил три условия безопасной работы агентов: у каждого должна быть собственная идентичность, доступ — ограничен конкретной задачей, а действия — прослеживаться отдельно от действий человека. Если приложение не знает, что действует агент, кому человек поручил задачу и какие операции разрешены, оно не может надёжно решить, следует ли выполнять запрос.
У Token было преимущество: компания контролировала и Rehearsal, и платформу, в которой он работал. Агент сообщал системе о своей идентичности. Пока он управлял интерфейсом, приложение затемнялось и блокировалось, а пользователь видел, кто сейчас действует. Token записывала каждый шаг, включая заблокированные действия.
Права Rehearsal ограничили сильнее, чем права пользователя. Его панели доступны только для чтения; сохранить изменения он не может без одобрения человека, секретные поля не заполняет, а вызов, отклонённый платформой, повторно не отправляет. Элементы панели агент распознаёт по меткам доступности страницы. Такие ограничения возможны потому, что Token сама контролирует обе стороны взаимодействия.
Стороннему CRM или облачной консоли обычно неоткуда узнать, что браузером управляет агент. Агент, в свою очередь, может не понять, где находится пароль, а какая кнопка безвозвратно удаляет запись. В сессии при этом указана личность пользователя, но нет отдельного имени агента и границ порученной ему задачи.
Некоторые механизмы уже появляются, но пока решают разные части проблемы. Chrome auto-browse запрашивает одобрение перед действиями с серьёзными последствиями, например платежами или массовой рассылкой, ограничивает агента нужными для задачи сайтами и помечает посещённые им страницы в истории. Microsoft позволяет администраторам включать агентный режим отдельно для каждого сайта и приостанавливать его перед вводом паролей и номеров карт.
Другой подход предлагает WebMCP — проект, который Google и Microsoft разрабатывают в рабочей группе сообщества W3C. Сайт может предоставить агенту прямые инструменты для выполнения действий и помечать каждое как доступное только для чтения или имеющее последствия. Тогда агенту не приходится угадывать назначение кнопок. Но WebMCP сам по себе не сокращает права: инструмент работает в пользовательской сессии с полномочиями пользователя.
Черновик рабочей группы IETF под названием Web Bot Auth позволяет сайту проверить, какой агент отправил запрос. Но он не описывает делегирование и потому не сообщает, от чьего имени действует агент. Есть и разрыв между механизмами: браузер может знать, что им управляет агент, однако Chrome и Edge не определяют, как передать эту информацию приложению. WebMCP описывает доступные действия, но не сужает права, а Web Bot Auth устанавливает личность агента, но не подтверждает поручение человека.
Каждый агентный канал должен передавать приложению три вещи: идентичность агента, проверяемую связь с человеком, который поручил ему работу, и пределы доступа, более узкие, чем права этого человека. Без такого контекста приложение не сможет принять обоснованное решение о доступе, а удобный для агента интерфейс рискует стать короткой дорогой к злоупотреблению полномочиями.
Пока стандарты не связывают эти данные воедино, службе безопасности стоит считать любого агента в человеческой сессии пользователем делегированного доступа. Нужно выявить браузерных агентов, расширения и конечные агенты, работающие через авторизованные сессии, установить их владельцев и пользователей, в том числе других агентов, а затем проверить доступы и возможные пути обхода контроля. Для чувствительных или необратимых действий следует требовать явного подтверждения либо повторной аутентификации: например, запроса passkey. У SaaS-поставщиков нужно выяснить, отличают ли журналы действия агента от действий человека и поддерживается ли делегирование с ограничением по задаче. Отдельно следует искать агентные браузеры и расширения, которые используют чужие сессии. Такой доступ необходимо обнаруживать, ограничивать и проверять по журналам.
Этот опыт выявил три условия безопасной работы агентов: у каждого должна быть собственная идентичность, доступ — ограничен конкретной задачей, а действия — прослеживаться отдельно от действий человека. Если приложение не знает, что действует агент, кому человек поручил задачу и какие операции разрешены, оно не может надёжно решить, следует ли выполнять запрос.
У Token было преимущество: компания контролировала и Rehearsal, и платформу, в которой он работал. Агент сообщал системе о своей идентичности. Пока он управлял интерфейсом, приложение затемнялось и блокировалось, а пользователь видел, кто сейчас действует. Token записывала каждый шаг, включая заблокированные действия.
Права Rehearsal ограничили сильнее, чем права пользователя. Его панели доступны только для чтения; сохранить изменения он не может без одобрения человека, секретные поля не заполняет, а вызов, отклонённый платформой, повторно не отправляет. Элементы панели агент распознаёт по меткам доступности страницы. Такие ограничения возможны потому, что Token сама контролирует обе стороны взаимодействия.
Стороннему CRM или облачной консоли обычно неоткуда узнать, что браузером управляет агент. Агент, в свою очередь, может не понять, где находится пароль, а какая кнопка безвозвратно удаляет запись. В сессии при этом указана личность пользователя, но нет отдельного имени агента и границ порученной ему задачи.
Некоторые механизмы уже появляются, но пока решают разные части проблемы. Chrome auto-browse запрашивает одобрение перед действиями с серьёзными последствиями, например платежами или массовой рассылкой, ограничивает агента нужными для задачи сайтами и помечает посещённые им страницы в истории. Microsoft позволяет администраторам включать агентный режим отдельно для каждого сайта и приостанавливать его перед вводом паролей и номеров карт.
Другой подход предлагает WebMCP — проект, который Google и Microsoft разрабатывают в рабочей группе сообщества W3C. Сайт может предоставить агенту прямые инструменты для выполнения действий и помечать каждое как доступное только для чтения или имеющее последствия. Тогда агенту не приходится угадывать назначение кнопок. Но WebMCP сам по себе не сокращает права: инструмент работает в пользовательской сессии с полномочиями пользователя.
Черновик рабочей группы IETF под названием Web Bot Auth позволяет сайту проверить, какой агент отправил запрос. Но он не описывает делегирование и потому не сообщает, от чьего имени действует агент. Есть и разрыв между механизмами: браузер может знать, что им управляет агент, однако Chrome и Edge не определяют, как передать эту информацию приложению. WebMCP описывает доступные действия, но не сужает права, а Web Bot Auth устанавливает личность агента, но не подтверждает поручение человека.
Каждый агентный канал должен передавать приложению три вещи: идентичность агента, проверяемую связь с человеком, который поручил ему работу, и пределы доступа, более узкие, чем права этого человека. Без такого контекста приложение не сможет принять обоснованное решение о доступе, а удобный для агента интерфейс рискует стать короткой дорогой к злоупотреблению полномочиями.
Пока стандарты не связывают эти данные воедино, службе безопасности стоит считать любого агента в человеческой сессии пользователем делегированного доступа. Нужно выявить браузерных агентов, расширения и конечные агенты, работающие через авторизованные сессии, установить их владельцев и пользователей, в том числе других агентов, а затем проверить доступы и возможные пути обхода контроля. Для чувствительных или необратимых действий следует требовать явного подтверждения либо повторной аутентификации: например, запроса passkey. У SaaS-поставщиков нужно выяснить, отличают ли журналы действия агента от действий человека и поддерживается ли делегирование с ограничением по задаче. Отдельно следует искать агентные браузеры и расширения, которые используют чужие сессии. Такой доступ необходимо обнаруживать, ограничивать и проверять по журналам.
