Мы говорим клиентам три вещи о защите ИИ-агентов: им нужны собственные идентификаторы, доступ, соответствующий поставленной задаче, и отслеживаемость, отдельная от человеческой. Так было и у нас в Token. Затем мы создали агента, который по умолчанию нарушал все три правила. Это помогло нам продумать, как такие агенты должны быть защищены. Когда браузерный агент действует в рамках аутентифицированной сессии пользователя, приложение может видеть пользователя, но не агента, делегирование или предполагаемую область задачи. Создав агента, который нарушает все правила безопасности, Token понял, как компании должны использовать идентификацию для получения контроля, особенно по мере масштабирования использования агентов. Стандарты появятся, но есть шаги, которые команды безопасности могут предпринять уже сегодня. Агент, который мы создали, называется Rehearsal. Его задача — отвечать на вопросы внутри платформы Token, действуя, а не рассказывая. Он автономно открывает страницы во вкладке браузера, устанавливает фильтры и заполняет формы. С точки зрения безопасности, это типичный UI-агент, работающий в браузере пользователя. В этом и заключается его полезность. Но это также означает, что агент работает в рамках сессии пользователя и имеет его доступ. Более того, для сервера, стоящего за страницей, действия агента неотличимы от действий пользователя, поскольку в cookie сессии нет указаний на то, кто управляет сессией. Поскольку Token владеет как агентом, так и приложением, в котором он работает, мы можем устранить каждый пробел изнутри. Например, Token знает, кто управляет сессией, потому что Rehearsal сообщает ему об этом. Мы выяснили, что существует несколько лучших практик, которые можно применить, когда вы контролируете сам ИИ-агент: Это работает для нашего собственного агента, но только потому, что он полагается на доступ, которого нет ни у одного внешнего агента. Мы могли бы предоставить Rehearsal актора, область действия и карту страниц, потому что именно мы его написали. Браузерный агент, управляющий вашей CRM или облачной консолью, не имеет ничего из этого. Приложение не может определить, что он там находится, а агент не может сказать, какое поле содержит секрет или какая кнопка удаляет запись. Сама сессия несет идентификатор пользователя. Выход заключается в том, чтобы предоставить агентам собственные “полосы движения”, отдельные от человеческих пользователей. Веб начал их создавать, но не обязательно фокусируется на комплексных подходах. Браузер может отмечать, когда им управляет агент, и соответственно ограничивать себя. Например, Chrome auto-browse уже требует одобрения человека перед выполнением ответственных действий, таких как платежи или массовые рассылки, ограничивает своего агента только необходимыми для задачи сайтами и помечает посещаемые агентом страницы в истории пользователя. Microsoft позволяет администраторам включать агентное браузерное поведение для каждого сайта и приостанавливать его перед вводом паролей и номеров карт. Приложение может публиковать свои действия как инструменты. WebMCP, проект, над которым Google и Microsoft работают в рамках сообщества W3C, позволяет сайту предоставлять действия, которые агент может вызывать напрямую, и помечать каждое из них как “только для чтения” или “консеквентное”. Таким образом, агенту не нужно угадывать, что делает кнопка. Агент может подписывать свои запросы. Web Bot Auth, ныне проект рабочей группы IETF, позволяет сайту проверять, какой агент отправил запрос. Отсутствует слой, который бы их связывал. Каждая “полоса движения” знает что-то, чего не знают другие, и ни одна из них не передает это дальше. Браузер знает, что им управляет агент, но ни Chrome, ни Edge не описывают, как сообщить об этом приложению на другом конце. Инструмент WebMCP работает в рамках сессии пользователя, с правами пользователя, поэтому сам по себе не ограничивает доступ агента. Web Bot Auth называет агента, но проект ясно дает понять, что он не охватывает делегирование, поэтому он опускает человека, для которого работает агент. В итоге приложение удерживает фрагменты контекста вместо того, чтобы предоставлять что-то действенное. Теперь учтите, что агенты появляются быстрее, чем стандарты. “Дружественность к агентам” сама по себе недостаточна. Каждая “полоса движения”, созданная для агентов, должна нести идентификатор агента, проверяемую связь с человеком, для которого он действует, и область действия, более узкую, чем у этого человека. Вместе эти три сигнала предоставляют приложению минимальный контекст, необходимый для принятия решения об авторизации. В противном случае более быстрая “полоса движения” — это просто более быстрый путь к злоупотреблению привилегиями. Ждать стандартизации нельзя. Вам нужно как можно скорее начать обнаруживать агентные браузеры и расширения, включая пользователей, чьи сессии они заимствуют. И хотя вы не можете определить, кто нажал, вы можете выбрать, какие клики требуют участия человека, добавив дополнительную проверку, такую как запрос пароля. Пока браузеры и приложения не смогут совместно передавать идентификатор агента, делегирование человеком и область действия задачи, компании должны рассматривать каждого агента, использующего человеческую сессию, как делегированный доступ, который необходимо обнаруживать, ограничивать и аудировать.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – The Hacker News
