AI-агенты теперь действуют в сети от лица миллионов людей. Для сайта такой агент может принимать разные формы. Он может быть неотличим от пользователя-человека, выполняющего задачу, или выглядеть как один посетитель, представляющий множество пользователей. Это лишает сайт возможности распознавать, обслуживать и привлекать к ответственности пользователя или пользователей, стоящих за агентом, и заставляет сайт нести убытки, когда что-то идет не так. В этой статье утверждается, что для того, чтобы сайты могли максимально эффективно предоставлять доступ агентам, экосистема должна разработать новые механизмы для сохранения отношений между сайтами и пользователями. Традиционно в сфере безопасности и предотвращения мошенничества для этого требуются три вещи: идентификация, репутация и подотчетность, что позволяет сайтам ответить на вопросы: является ли действующее лицо тем, за кого себя выдает? Можно ли доверять этому человеку? И кто несет ответственность за действия?
«Персональные AI-агенты» (сокращенно «Агенты») — это средства автоматизации, которые получают инструкции от человека («Пользователя») и преследуют цель, управляя облачным компьютером или браузером. Обычно они размещаются и обслуживаются «Оператором» как часть управляемого сервиса или потребительского предложения. Примеры включают Muse от Meta и dots от OpenAI, и постоянно появляются новые. Агенты потенциально могут совершать в интернете любые действия, доступные их пользователю, без ограничений, сдерживающих людей. Они не устают, работают круглосуточно, действуют параллельно и готовы мириться с неудобствами, которые не потерпел бы ни один человек. Большая часть интернета, от планирования мощностей сайтами до способов получения ими прибыли, строится на предположении о наличии этих ограничений.
По сути, удаленно размещенные агенты являются посредниками. Посредник — это любой субъект, который находится между пользователем и сайтом, поэтому сайт видит его, а не пользователя. Агенты — это новейший вид посредников, но посредники существовали уже давно. Облачные браузеры (размещенные браузеры, которыми программное обеспечение управляет от имени пользователя) и прокси-серверы (сервисы, которые ретранслируют трафик пользователя, включая VPN) также являются посредниками. Что изменилось, так это динамика. Агентский трафик быстро растет и в ближайшем будущем может затмить традиционный человеческий браузинг в интернете. Это заставляет задуматься любого, кто управляет сайтом сегодня. Исторически сайт мог просто заблокировать трафик посредника и потребовать от пользователей отключить посреднический сервис. Это перестает работать, когда большая часть трафика становится агентской. Как только блокировка перестает быть эффективной, операторы сайтов сталкиваются с проблемой, которую посредники создавали всегда. Сайт теряет прямую информацию о пользователе и должен решить, доверять ли посреднику без нее.
В этой статье рассматриваются агенты, размещенные не на устройстве пользователя. Локальные агенты (например, OpenClaw) или агенты, работающие в собственном браузере пользователя на его собственном устройстве, выходят за рамки основной темы, рассматриваемой в этой статье (см. ниже «Об агентах с открытым исходным кодом и локальных агентах»).
Эта статья опирается на один принцип:
Принцип посредничества: деловые отношения между пользователями и сайтами, а также обязанности каждого участника в области безопасности должны соблюдаться независимо от наличия посредничества.
Сайту нужны новые инструменты для распознавания, обслуживания и привлечения к ответственности пользователя, действующего через агента, точно так же, как если бы этот пользователь посетил сайт напрямую. Агент и стоящий за ним оператор также должны быть узнаваемы и подотчетны, поскольку агент может делать то, что не под силу ни одному пользователю. Агенты способны масштабировать доступ людей практически без ограничений, поэтому они создают новые риски даже для поведения, которое ранее было безобидным.
Проблема посредничества
Познакомьтесь с Эзрой. Эзра работает личным помощником для людей в своем городе. Ее лучший клиент — Эми, местный генеральный директор, но она также работает на Боба, Чарли и Дебру. Она выполняет их поручения: покупки продуктов, записи на приемы, оформление документов и бронирование авиабилетов. Эзра сливается с толпой.
Владелец углового продуктового магазина раньше знал Эми. Он знал, что она покупает, и откладывал то, что, по его мнению, ей понравится. Теперь приходит только Эзра с заказами для четырех человек, и владелец магазина не может понять, чьи предпочтения кому принадлежат. Он не хочет прогонять Эзру, потому что она приносит ему много заказов.
Затем Боб просит Эзру купить ему iPhone. Через неделю он звонит в магазин, говорит, что никогда не санкционировал списание средств, и оставляет телефон себе. Чтобы выиграть спор, магазин должен доказать, что Боб просил об этом. Но единственным человеком, которого магазин когда-либо видел, была Эзра.
Затем Чарли дает Эзре список паролей: «Я забыл свой, но один из них — мой». Эзра терпеливо пробует каждый из них в банке Чарли. Банк видит, что происходит атака, но единственный человек, которого он может заблокировать, — это Эзра. Блокировка Эзры также блокирует Эми, Боба и Дебру.
Ни у одного из этих владельцев бизнеса нет проблем с самой Эзрой. Их проблема в том, что они видят только Эзру, а не человека, от имени которого она действует. Замените Эзру на AI-агента, а бизнес — на веб-сайты, и вы получите современный интернет.
Владелец веб-сайта хочет иметь достаточную видимость как для предотвращения неправомерного поведения, так и для эффективной монетизации или получения выгоды от своего сайта. Но, как и в случае с Эзрой, большая часть этой видимости исчезает с появлением AI-агентов. Ниже приведен список действий, которые владелец веб-сайта может захотеть предпринять, которые ранее были решены, но стали более сложными из-за разрешения доступа агентам.
Сайт должен соответствовать юридическим требованиям по проверке информации о своих пользователях. Например, на некоторых сайтах действуют возрастные или географические ограничения.
Агенты не предоставляют гарантий, которые могли бы соответствовать требованиям сайтов для обеспечения соответствия нормативным требованиям, если они разрешают доступ агентам.
«Дружественное мошенничество» — это когда пользователь одобряет покупку агента, а затем оспаривает ее как несанкционированную. Сайты могут выиграть дело с помощью косвенных доказательств: того же устройства, IP-адреса и адреса, что и при прошлых неоспоримых покупках пользователя. Покупки агентов совершаются с инфраструктуры агента, поэтому таких доказательств не существует. Даже когда сайт выигрывает, сам спор стоит денег.
Сайтам необходимо вести учет поведения при оформлении заказа для предотвращения мошенничества. Ведение этих записей помогает сайтам снизить общие неудобства от дополнительной проверки, что приводит к более низкому уровню отклонения транзакций и в целом к большему количеству оформленных заказов.
Сайт хочет иметь возможность различать типы своих пользователей. CAPTCHA и другие методы проверки человека проверяют, является ли сущность, управляющая браузером, человеком или нет.
Никогда не ожидается, что агенты будут людьми. Решения, которые передают этот сигнал пользователю-человеку, не добавляют новой информации и просто делают агентов менее эффективными.
Сайты могут захотеть защитить себя от ошибочных действий, совершаемых новыми или более экспериментальными агентами.
Агенты совершают ошибки: не тот товар, не та дата, дублирующие заказы. Сайты могут взять расходы на себя через возвраты и поддержку, чтобы сохранить лояльность клиентов, не имея возможности определить, какие агенты надежны.
Сайты, предоставляющие бесплатные услуги или полагающиеся на вовлеченность пользователей, часто проектировались с учетом предполагаемого ограничения поведения пользователей.
Агенты постоянно опрашивают сайт (например, проверяют наличие товаров и цены), обращаются к дорогим конечным точкам (например, поиск, инвентаризация или чат поддержки) и исчерпывают бесплатные пробные версии и рекламные акции.
Сайты и платежные провайдеры должны защищать владельцев карт от несанкционированных транзакций, минимизируя при этом расходы на оспаривание платежей и другие издержки, связанные с мошенничеством.
Когда авторизованный пользователь совершает покупку по карте, ответственность несет владелец карты. Если владелец карты передает ее кому-то, кто не является авторизованным пользователем, он все равно несет ответственность за то, что передал ее. Агенты не имеют статуса авторизованного пользователя, поэтому сайт не может определить, стоит ли пользователь за этой покупкой. На практике, когда пользователь оспаривает транзакцию, сайт несет убытки.
Сайтам, монетизирующим контент, необходимы прозрачность и контроль над тем, кто получает доступ к этому контенту, чтобы применять правильную модель монетизации.
Агент считывает или извлекает контент (статьи, данные о продуктах, отзывы), чтобы ответить пользователю где-то в другом месте. Сайт платит за предоставление этого контента, но не получает ни посещения, ни показа рекламы, ни покупки.
Почти во всех вышеперечисленных проблемах основные расходы несет сайт. Этот результат вытекает из того, как работает доверие при участии посредника.
Наше видение
Наша цель — интернет, в котором все пользователи имеют равный или больший доступ к веб-сайтам, чем раньше. До появления агентов сайт обычно мог снизить эти риски с помощью набора методов, включая снятие цифровых отпечатков устройства, сессии и истории пользователя. Пользователи по-прежнему могли просматривать сайты в режиме инкогнито, и мы считаем, что агенты также должны иметь такую возможность. Но они, вероятно, не смогут войти в банковский аккаунт без дополнительной проверки.
Ничто из этого не требует, чтобы агент действовал как человек или чтобы человек присутствовал при каждом действии. Это требует, чтобы у сайтов были средства для получения или запроса информации о пользователе, чтобы привлечь его к ответственности, когда это применимо, с агентом или без него.
Что люди пробовали и почему это не работает
Распространенное предложение состоит в том, чтобы агенты передавали CAPTCHA сайта пользователю для решения. Это доказывает лишь то, что в данный момент присутствует какой-то человек («человек в цикле» или HITL), и ничего более. HITL — это прежде всего механизм предотвращения ошибок из-за несогласованности. Несогласованность — это проблема между оператором и пользователем, и ее решение не устраняет большинство вышеперечисленных проблем. Например, это не позволяет отличить Боба от кого-либо еще (смешивание трафика) и ничего не говорит о том, от чьего имени агент действует в остальное время. Кроме того, агенты существуют для устранения трения, а HITL возвращает это трение, поэтому операторы заинтересованы в том, чтобы удалить или обойти его для пользователя.
Другое распространенное предложение — использовать строго ограниченный контроль доступа. Агенты созданы для того, чтобы делать все, что может пользователь, поэтому на практике они запрашивают и получают разрешение на все. Область действия «все» ничего не говорит сайту. И даже узкая область действия говорит только о том, что агенту было разрешено делать. Она не говорит о том, кто несет ответственность, когда агент ошибается, а это именно тот вопрос, на который сайту действительно нужен ответ.
Что нужно вебу
Вебу нужны инструменты и протоколы, которые позволят сайтам и агентам сотрудничать для определения того, какие модели поведения и действия разрешены, а также выражать предпочтения и политики от сайтов к агентам, и все это таким образом, чтобы это могло быть разумно поддержано всеми сайтами и агентами. К счастью, работа по всем этим направлениям уже ведется, и многие, если не все из этих проблем, могут быть решены путем применения существующих стандартов.
Протоколы
Агенты и сайты могут использовать явные протоколы для решения некоторых из вышеперечисленных проблем. Например, MOLE — это один из перспективных подходов, направленный на ограничение скорости без использования идентификаторов пользователя, что позволяет сайтам перейти от неявных идентификаторов к явным протоколам для достижения той же цели. Это похоже на x402 protocol, который направлен на обеспечение платежей в интернете при сохранении конфиденциальности. Мы активно изучаем способы использования существующих протоколов для решения других проблем, а также рассматриваем возможность разработки новых протоколов, когда существующие решения оказываются недостаточными.
Идентификаторы
При обсуждении идентификации агента Web Bot Auth (WBA) является нашим предпочтительным методом. WBA позволяет агенту подписывать свои запросы, что обеспечивает безопасный способ идентификации агента (и, косвенно, оператора). Нам все еще необходимо определить механизм, поддерживающий нескольких посредников: когда агент А использует агента Б внутри браузера В, сайт должен знать об этом, чтобы правильно гарантировать, что доступ агента А понимается и контролируется корректно, например, для предотвращения обхода политики.
Другие типы идентификационной информации, такие как сессия, учетная запись или даже идентификаторы пользователя, могут потребоваться в зависимости от контекста. Мы работаем с соответствующими стандартами, чтобы изучить способы передачи такой идентификационной информации.
Давайте рассмотрим типы идентификации применительно к пользователю. В конечном счете, идентификация — это спектр, который предполагает обмен различными объемами информации о пользователе, при этом в идеале соблюдаются принципы минимизации данных. Идентификация предоставляет нам механизм для ответа на вопрос «кто вы?», чтобы ответить на последующие вопросы: «вы тот, за кого себя выдаете?» и «можем ли мы вам доверять?»
Во многих случаях идентификационная информация не нужна, и методы сохранения конфиденциальности для модерирования доступа к агентам, такие как Privacy Pass и MOLE, могут помочь нам ответить на вопрос «можем ли мы вам доверять?», не отвечая на вопрос «кто вы?». Private Access Tokens были одним из первых способов, с помощью которых мы пытались установить доверие без идентификации пользователя, и MOLE задуман как преемник этой технологии. Однако существуют случаи, когда потребуются градированные формы раскрытия информации в этом спектре, и их можно охарактеризовать следующим образом:
- Ничего — пользователи могут действовать в интернете, не предоставляя никаких идентификаторов.
- Сессия — сайтам требуется способ связывания запросов в рамках одной сессии с одним агентом. Это позволяет сайту установить репутацию для данной сессии и действовать соответствующим образом. Например, Poppy имеет понятие идентификатора сессии именно для этой цели.
- Учетная запись — сайтам требуется способ атрибуции запросов одному и тому же пользователю в разных сессиях. Это может быть постоянный идентификатор, назначенный оператором или третьей стороной пользователю, который сохраняется в учетной записи у оператора, например, один и тот же агент, посещающий один и тот же сайт каждый день с использованием одного и того же идентификатора. Пример варианта использования, который это позволит: «Привяжите свою учетную запись на сайте к своей учетной записи агента».
- Уникальный — некоторым сайтам может потребоваться уникальный идентификатор для каждого пользователя, предоставленный третьей стороной, который сохраняется у разных операторов, учетных записей, агентов и сессий. Это может быть полезно для действий с высоким уровнем риска или для сайтов, которым необходимо предоставить ограниченный доступ к дорогостоящему ресурсу или которые имеют очень строгие обязательства или требования по соблюдению нормативных требований. Государственные удостоверения личности, проверка личности третьей стороной и децентрализованные технологии, такие как Proof of Human, являются примерами технологий, которые могут это обеспечить.
В конечном счете, сайты сами определяют, какая информация им нужна, чтобы клиенты могли ответить на вопрос: «Разрешено ли сущности, стоящей за этим запросом, выполнять данное действие в данный момент?» Во многих случаях уже существуют или разрабатываются протоколы для передачи этой информации: WBA для передачи идентификатора платформы агента, MOLE для передачи репутации пользователя, OAuth для передачи идентификаторов учетных записей и так далее.
Заявления (Claims)
Помимо идентификации, некоторые действия требуют подтверждения фактов о реальном человеке, например, достижения 18-летнего возраста или того, что он является владельцем карты (проблемы проверки личности, дружественное мошенничество). Часто оператор проверяет это при регистрации, или эта информация уже есть у третьей стороны.
Чтобы предоставить агентам доступ к сайтам или действиям с подобными ограничениями, нам нужны механизмы, с помощью которых сайты могли бы запрашивать эту информацию, а операторы или третьи стороны — предоставлять ее.
Политика доступа агентов к сайтам
Сегодня агент делает выводы о правилах сайта, пытаясь что-то сделать и интерпретируя ответ сайта (обычно, блокируется он или нет). Это пустая трата ресурсов с обеих сторон, а в некоторых случаях заставляет добросовестных агентов выглядеть злоумышленниками. Файл Robots.txt указывает, куда может заходить краулер, но он не совсем подходит для выражения того, что агентам разрешено делать.
Сайтам нужен машиночитаемый способ публикации того, какие действия разрешены агентам. Инженерный совет Интернета (IETF) активно работает над некоторыми механизмами выражения предпочтений для этого, в основном в рамках рабочей группы AI Preferences. Однако основное внимание группы сосредоточено на выражении предпочтений для использования (таких как обучение, логический вывод и поиск), и до сих пор нет группы, сосредоточенной на более широкой потребности в механизмах выражения предпочтений, обсуждаемых здесь.
Об агентах с открытым исходным кодом и локальных агентах
Агенты, которые не работают как «посредники» (например, агенты на устройстве или локально размещенные агенты, такие как OpenClaw), вызывают другие опасения. Прежде всего, они выглядят как автоматизация (и являются ею), и у них нет единой стороны, с которой можно было бы выстраивать репутацию или нести ответственность.
Существует множество решений этой проблемы, одно из которых — попросить таких агентов предоставлять уникальный идентификатор (Unique ID). Однако решение этого вопроса не является первоочередной задачей Trusted Agent Delegation.
Что дальше
Реальные решения проблем, с которыми сталкиваются сайты, не появятся из фрагментированных, специфичных для поставщиков механизмов. Они требуют открытых, совместимых стандартов, основанных на реальном опыте. Мы активно сотрудничаем со всей экосистемой, включая крупных операторов, компании по проверке личности, платежных провайдеров, мерчантов, издателей, провайдеров прокси-серверов и компании, занимающиеся облачным браузингом, чтобы согласовать операционные требования непосредственно с активной работой над этими проблемами в IETF и других организациях.
Мы сосредоточены на преодолении разрыва между работающим кодом и новыми спецификациями в рамках рабочих групп и таких инициатив, как Web Bot Auth, AIPREFs, OAuth, WIMSE и MOLE. Мы делаем это, в частности, путем совместной разработки и доработки открытых протоколов, таких как WBA и MOLE, а также создания и развертывания реализаций этих протоколов в масштабе.
Мы также объявляем о создании коалиции Trusted Agent Delegation (TAD). Цель TAD — собрать группу представителей всей экосистемы для обсуждения общего круга проблем, изложенных в этом документе, изучения всех существующих протоколов, а затем, при необходимости, вынесения более четко сформулированных проблем на рассмотрение IETF. Мы намерены проводить параллельные встречи в рамках IETF и семинары в будущем для содействия дискуссии.
Если вы создаете агентов, среды выполнения агентов, управляете платформой периферийных или облачных вычислений или управляете коммерческими приложениями или приложениями для обеспечения соответствия требованиям, нам нужно, чтобы вы тоже приняли участие в этих усилиях. Посетите эту страницу для получения дополнительной информации о том, как принять участие.
Что вы можете сделать сегодня
Открытая, совместимая основа — это то, к чему мы стремимся, начиная с TAD. Но вам не нужно ждать появления новых протоколов, чтобы начать восстанавливать видимость и контроль. Начиная с этой недели, клиенты Cloudflare могут предпринять три конкретных шага:
Посмотрите, какие агенты находятся на вашем сайте и что они делают. Security Analytics теперь выделяет персональных помощников в отдельную категорию трафика, а новый виджет перечисляет каждого агента, посещающего ваш сайт, количество запросов от каждого из них, пути, по которым они переходят, и ошибки, с которыми они сталкиваются. Необъяснимый автоматизированный трафик становится трафиком, который можно анализировать. А для получения более широкой картины того, как ИИ-краулеры и боты влияют на ваш бизнес, включая соотношение того, сколько сканирует каждый оператор, по сравнению с трафиком, который он отправляет обратно, клиенты Enterprise Bot Management могут использовать Business Insights.
Установите доступ на своих условиях для каждого агента. Используя политики доступа для ИИ-краулеров и агентов, вы можете приветствовать агентов, которые приносят вам пользу, и ограничивать тех, кто этого не делает — разрешить агенту доступ ко всему сайту, заблокировать его только на страницах с рекламой или заблокировать полностью. Ваши политики поиска и обучения остаются независимыми.
Привяжите агента к пользователю, от имени которого он действует, и принимайте меры. Для сайтов, использующих Account Abuse Protection (ранний доступ), каждый вход в систему и регистрация теперь показывают, был ли запрос сделан персональным агентом и каким именно. Когда злоумышленник использует общего агента для доступа к одной учетной записи, вы можете ограничить эту учетную запись — с помощью правила WAF для хешированного идентификатора пользователя (Hashed User ID) — не блокируя агента для всех остальных легитимных пользователей, стоящих за ним. Это первый конкретный ответ на проблему смешивания трафика, описанную выше: вы наконец можете видеть пользователя за агентом и реагировать соответствующим образом.
Это первые строительные блоки нашего видения, которые уже внедрены в производство. По мере совершенствования стандартов их будет больше.
И если у вашей компании более строгая позиция в отношении агентов, мы будем рады узнать о ней. Свяжитесь с нами и расскажите о своих проблемах напрямую. Мы стремимся помочь построить Интернет, в котором владельцы сайтов имеют видимость и контроль, но при этом агенты имеют максимальный доступ, разумный в рамках этих элементов управления. Вы можете связаться со своей службой поддержки клиентов или написать нам по адресу crawlercontrols@cloudflare.com.
