📰 IT Дайджест

AI-агенты теперь действуют в интернете от имени миллионов людей. Для веб-сайта Агент может принимать множество форм. Он может быть неотличим от человека-пользователя, выполняющего задачу, или выглядеть как один посетитель, обслуживающий множество Пользователей. Это лишает Сайт возможности распознавать, обслуживать и привлекать к ответственности пользователя или пользователей, стоящих за Агентом, и заставляет Сайт нести издержки, когда что-то идет не так. В этом посте утверждается, что для того, чтобы Сайты могли максимально расширить доступ, предоставляемый Агентам, экосистема должна разработать новые механизмы для сохранения отношений между Сайтами и Пользователями. Традиционно в сфере безопасности и предотвращения мошенничества для этого требуются три вещи: Идентичность, Репутация и Подотчетность, позволяющие Сайтам ответить на вопросы: Правдив ли человек, совершающий действие, в отношении своей личности? Заслуживает ли этот человек доверия? И кто отвечает за действие?

«Персональные ИИ-агенты» («Агенты» для краткости) — это автоматизации, которые получают инструкции от человека («Пользователя») и преследуют цель, управляя облачным компьютером или браузером. Обычно они размещаются и обслуживаются «Оператором» в рамках управляемого сервиса или потребительского предложения. Примеры включают Muse от Meta и dots от OpenAI, и новые появляются постоянно. Агенты потенциально могут выполнять в интернете любые действия, которые мог бы выполнять их Пользователь, без ограничений, сдерживающих людей. Они не устают, работают круглосуточно, действуют параллельно и мирятся с неудобствами, которые не выдержал бы ни один человек. Большая часть веба, от планирования мощности Сайтов до способов заработка, предполагает наличие этих ограничений.

По своей сути, удаленно размещенные Агенты являются посредниками. Посредник — это всё, что находится между Пользователем и Сайтом, так что Сайт видит его вместо Пользователя. Агенты — это новейший вид посредников, но посредники существовали долгое время. Облачные браузеры (размещенные браузеры, которыми программное обеспечение управляет от имени Пользователя) и Прокси (сервисы, ретранслирующие трафик Пользователя, включая VPN) также являются посредниками. Изменилась траектория. Агентский трафик быстро растет и в ближайшем будущем может затмить традиционный человеческий просмотр веб-страниц в Интернете. Это вынуждает любого, кто управляет Сайтом сегодня, пересмотреть свои подходы. Исторически Сайт мог просто блокировать посреднический трафик и требовать от Пользователей отключения сервиса-посредника. Это перестает работать, когда большинство трафика является агентским. Как только блокировка перестает быть жизнеспособной, Операторы Сайтов остаются с проблемой, которую всегда создавали посредники. Сайт теряет прямую информацию о Пользователе и должен решить, доверять ли посреднику без нее.

Этот пост охватывает Агентов, размещенных где-то, кроме устройства Пользователя. Локальные агенты (например, OpenClaw) или Агенты, работающие в собственном браузере Пользователя на его устройстве, выходят за рамки основной темы, рассматриваемой в этом посте (см. ниже, «Об открытом исходном коде и локальных Агентах»).

Без Агентов Пользователь взаимодействует с Сайтом напрямую.

С Агентами Сайт видит Агента, а не Пользователя, и один Агент действует от имени многих Пользователей.

Иногда между Пользователем и Сайтом находится несколько посредников.

Этот пост основан на одном принципе:

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

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

Проблема посредника

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

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

Затем Боб просит Эзру купить ему iPhone. Неделю спустя он звонит в магазин, говорит, что не авторизовал платеж, и оставляет телефон себе. Чтобы выиграть спор, магазин должен доказать, что Боб просил об этом. Но единственный человек, которого видел магазин, — это Эзра.

Затем Чарли дает Эзре список паролей: «Я забыл свой, но это один из них». Эзра терпеливо пробует каждый из них в банке Чарли. Банк видит, что происходит атака, но единственный, кого он может забанить, — это Эзра. Баня Эзры также блокирует Эми, Боба и Дебру.

Ни у одного из этих владельцев бизнеса нет проблем с самой Эзрой. Их проблема в том, что они видят только Эзру, а не человека, от имени которого она действует. Замените Эзру на ИИ-агента, а бизнес — на веб-сайты, и вы получите сегодняшний веб.

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

Проблема	Цель владельца Сайта
Совместное использование аккаунтов	Сайтам необходимо гарантировать, что одна платная подписка не используется для обслуживания многих Пользователей. При доступе через Агента Сайт видит один аккаунт и одного клиента.
Соответствие требованиям и незаконная деятельность	Сайт должен соблюдать юридические требования по проверке информации о своих Пользователях. Например, на некоторых Сайтах действуют возрастные или географические ограничения. Агенты не предоставляют гарантий, которые позволили бы Сайтам оставаться соответствующими требованиям, если они разрешают доступ Агентам.
Дружественное мошенничество	Дружественное мошенничество — это когда Пользователь одобряет покупку Агента, а затем оспаривает ее как несанкционированную. Сайты могут выиграть при наличии косвенных доказательств: то же устройство, IP-адрес и адрес, что и в предыдущих неоспариваемых покупках Пользователя. Покупки Агента поступают из инфраструктуры Агента, поэтому таких доказательств не существует. Даже если Сайт выигрывает, сам спор стоит денег.
Проверка на человека неактуальна	Сайт хочет иметь возможность различать типы своих Пользователей. CAPTCHA и другие проверки на человека определяют, является ли сущность, управляющая браузером, человеком или нет. От Агентов никогда не ожидается, что они будут людьми. Решения, передающие этот сигнал человеку-Пользователю, не добавляют новой информации и просто делают Агентов менее эффективными.
Подмена идентичности	Сайт хочет ограничить доступ к контенту для людей-пользователей или наложить ограничения на то, к чему конкретные Пользователи могут получить доступ. Агенты часто работают на жилых IP-адресах и используют реальные браузеры, смешиваются с трафиком, направляемым человеком, и предпринимают усилия, чтобы не отличаться от человеческого трафика. Злоумышленники копируют строку user agent известного Агента, чтобы получить те же привилегии.
Нарушение проверки личности	Сайту может потребоваться дополнительная проверка личности Пользователя или другой информации, чтобы предоставить доступ к чувствительным операциям или контенту. Проверки присутствия, KYC-проверки документов и подобные предполагают, что присутствующий человек и есть проверяемый. Агент никогда не является этим человеком. Сайт должен либо принять проверку, переданную через Агента (что ослабляет проверку), либо отказать Агентам, либо отказаться от проверки.
Несогласованность	Сайты могут захотеть защитить себя от ошибочных действий, совершаемых новыми или более экспериментальными Агентами. Агенты совершают ошибки: неправильный товар, неправильная дата, дублирующиеся заказы. Сайты могут нести расходы через возвраты и поддержку для сохранения доброй воли клиентов, не имея возможности определить, какие Агенты надежны.
Обход политики	Сайт стремится применить политику (например, блокировка, разрешение только партнерам, ограничение скорости), основанную на идентичности, но Агенты не всегда идентифицируют себя и часто не передают информацию о Пользователе, от имени которого действуют.
Истощение ресурсов	Сайты, предоставляющие бесплатные услуги или полагающиеся на вовлеченность Пользователей, часто проектировались с учетом предполагаемого ограничения поведения Пользователей. Агенты постоянно опрашивают (например, проверки цен и наличия на складе), обращаются к дорогим конечным точкам (например, поиск, инвентаризация или чат поддержки) и используют бесплатные пробные версии и промоакции.
Нарушение риск-ориентированной аутентификации	Сайт хочет поддерживать свою систему риск-ориентированной аутентификации, которая ожидает, что устройство, местоположение и поведение соответствуют Пользователю. Агенты работают в облачной инфраструктуре и каждый раз выглядят необычно.
Смешение трафика	Сайты хотели бы защитить себя и учетные записи Пользователей от злоупотреблений или мошеннических действий. Когда один Пользователь злоупотребляет общим Агентом для подбора учетных данных, скрапинга или тестирования карт, Сайт может обнаружить злоупотребление, но может заблокировать только Агента, что также блокирует всех его легитимных Пользователей.
Неавторизованные пользователи карт	Сайтам и платежным провайдерам необходимо защищать держателей карт от несанкционированных транзакций, минимизируя при этом расходы на споры и другие издержки, связанные с мошенничеством. Когда авторизованный Пользователь совершает покупку по карте, держатель карты несет ответственность. Если держатель карты передает карту кому-то, кто не является авторизованным пользователем, он все равно несет ответственность за ее передачу. У Агентов нет статуса авторизованного пользователя, поэтому Сайт не может определить, стоит ли Пользователь за этой покупкой. На практике, когда Пользователь оспаривает ее, платит Сайт.
Некомпенсированное потребление	Сайты, монетизирующие контент, требуют видимости и контроля над тем, кто получает доступ к этому контенту, чтобы применить правильную модель монетизации. Агент читает или извлекает контент (статьи, данные о продуктах, отзывы), чтобы ответить Пользователю в другом месте. Сайт платит за его обслуживание и не получает ни посещения, ни рекламного показа, ни покупки.
Атрибуция пользователя	Сайты предлагают дополнительные возможности согласившимся Пользователям в отношении персонализации, рекомендаций и программ лояльности, используя аналитику, привязанную к сессии и устройству Пользователя. Агентский трафик либо группирует многих Пользователей в одного клиента, либо появляется без сессии Пользователя.

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

Наше видение

Наша цель — Интернет, в котором все Пользователи имеют равный или больший доступ к веб-сайтам, чем раньше. До появления Агентов Сайт, как правило, мог снижать эти риски с помощью набора методов, включая сбор цифрового отпечатка устройства Пользователя, сессии и истории. Пользователи все еще могли просматривать страницы в режиме инкогнито, и мы считаем, что Агенты также должны иметь такую возможность. Но они, вероятно, не смогут войти в банк без дополнительной проверки.

Ничто из этого не требует от Агента вести себя как человек или присутствия человека для каждого действия. Это требует, чтобы у Сайтов были средства для получения или запроса информации о Пользователе, чтобы привлечь его к ответственности, когда это применимо, с Агентом или без него.

Что люди пробовали и почему это не работает

Распространенное предложение — чтобы Агенты передавали CAPTCHA Сайта Пользователю для решения. Это доказывает, что какой-то человек присутствует в данный момент («человек в цикле», или HITL), и ничего более. HITL — это в первую очередь механизм для предотвращения ошибок из-за несогласованности. Несогласованность — это проблема между Оператором и Пользователем, и ее решение не решает большинства проблем, перечисленных выше. Например, это не позволяет отличить Боба от кого-либо еще (Смешение трафика) и ничего не говорит о том, за кого Агент действует в остальное время. Кроме того, Агенты существуют для устранения трения, а HITL добавляет это трение обратно, поэтому у Операторов есть стимул удалить или обойти его для Пользователя.

Другое распространенное предложение — использовать строго ограниченные элементы управления доступом. Агенты созданы для того, чтобы делать все, что может Пользователь, поэтому на практике они запрашивают и получают разрешение на все. Область действия «все» ничего не говорит Сайту. И даже узкая область действия говорит только о том, что Агенту было разрешено делать. Она не говорит, кто отвечает, когда Агент ошибается, а это именно тот вопрос, на который Сайту нужен ответ.

Что нужно вебу

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

Протоколы
Агенты и Сайты могут использовать явные протоколы для решения некоторых из вышеперечисленных проблем. Например, MOLE — это один из предстоящих подходов, который нацелен на ограничение скорости без идентификаторов, специфичных для Пользователя, позволяя Сайтам переходить от неявных идентичностей к явным протоколам для достижения той же цели. Это похоже на протокол x402, который направлен на обеспечение платежей в вебе с сохранением конфиденциальности. Мы активно изучаем способы использования существующих протоколов для решения других проблем, а также изучаем возможность разработки новых протоколов, когда существующие решения не подходят.

Идентичности
Говоря об Идентичности Агента, Web Bot Auth (WBA) — наш предпочтительный метод. WBA позволяет Агенту подписывать свои запросы, что обеспечивает безопасный способ для Агента идентифицировать себя (и, неявно, Оператора). Мы все еще должны определить механизм, поддерживающий несколько посредников: когда Агент A использует Агента B внутри Браузера C, Сайт должен иметь возможность узнать об этом, чтобы правильно гарантировать, что доступ Агента A правильно понят и контролируется, например, для предотвращения Обхода политики.

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

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

Во многих случаях идентифицирующая информация не нужна, и методы сохранения конфиденциальности для регулирования доступа к агентам, такие как Privacy Pass и MOLE, могут помочь нам ответить на вопрос «можем ли мы тебе доверять?», не отвечая на вопрос «кто ты?». Private Access Tokens были одним из первых способов, с помощью которых мы пытались установить доверие без идентификации пользователя, и MOLE призван стать преемником этой технологии. Однако существуют случаи, когда требуются градуированные формы раскрытия информации вдоль этого спектра, и их можно охарактеризовать следующим образом:

• Ничего - Пользователи могут действовать в интернете, не предоставляя никаких идентификаторов.
• Сессия - Сайтам требуется способ связывать запросы в рамках одной сессии с одним агентом. Это позволяет Сайту установить репутацию для данной сессии и действовать соответствующим образом. Например, у Poppy есть понятие ID сессии именно для этой цели.
• Аккаунт - Сайтам требуется способ приписывать запросы одному и тому же Пользователю в разных сессиях. Это может быть стабильный идентификатор, назначенный Оператором или третьей стороной Пользователю, который сохраняется на протяжении всего аккаунта у Оператора, например, один Агент, посещающий один и тот же Сайт каждый день, используя один и тот же идентификатор. Пример использования, который это позволит: «Привяжите свой аккаунт на Сайте к своему аккаунту Агента».
• Уникальный - Некоторым Сайтам может потребоваться уникальный идентификатор для каждого Пользователя, предоставленный третьей стороной, который сохраняется независимо от Операторов, аккаунтов, Агентов и сессий. Это может быть полезно для действий с высоким риском, для Сайтов, которым необходимо предоставить ограниченный доступ к дорогостоящему ресурсу или которые имеют очень строгие обязательства или требования соответствия. Государственные удостоверения личности, проверка личности третьей стороной и децентрализованные технологии, такие как Proof of Human, — все это примеры технологий, которые могут это обеспечить.

В конечном счете, Сайты определяют, какая информация им нужна от клиентов, чтобы ответить на вопрос «разрешено ли сущности, стоящей за этим запросом, выполнить это действие в данный момент?». Во многих случаях протоколы уже существуют или разрабатываются для передачи этой информации: WBA для идентификации платформы Агента, MOLE для передачи репутации Пользователя, OAuth для передачи идентичности аккаунта и так далее.

Утверждения
Помимо идентичностей, некоторые действия требуют факта о реальном человеке, например, достижение 18 лет или статус держателя карты (Нарушение проверки личности, Дружественное мошенничество). Часто Оператор проверял это при регистрации, или третья сторона уже располагает этой информацией. Чтобы разрешить Агентам доступ к Сайтам или действиям с такого рода ограничениями, нам нужны механизмы для запроса этой информации Сайтами и ее предоставления Операторами или третьими сторонами.

Политика доступа Агентов к Сайту
Сегодня Агент узнает правила Сайта, пробуя что-то и интерпретируя ответ Сайта (обычно, блокируется он или нет). Это тратит ресурсы обеих сторон, и в некоторых случаях заставляет честных Агентов выглядеть злонамеренными. Robots.txt указывает, куда может пойти краулер, но не полностью подходит для выражения того, что Агентам разрешено делать.

Сайтам нужен машиночитаемый способ публикации того, какие действия разрешены Агентам. Инженерный совет Интернета (IETF) активно работает над некоторыми механизмами выражения предпочтений для этого, в основном в Рабочей группе по предпочтениям ИИ (AI Preferences Working Group). Однако фокус группы сосредоточен на выражении предпочтений для использования (такого как обучение, инференс и поиск), и все еще нет группы, сосредоточенной на более широкой потребности в механизмах выражения предпочтений, обсуждаемой здесь.

Об открытом исходном коде и локальных Агентах

Агенты, которые не работают как «Посредник» (например, Агенты на устройстве или локально размещенные Агенты, такие как OpenClaw), вызывают другие проблемы. В первую очередь, они выглядят (и являются) автоматизацией, и у них нет единой стороны для создания репутации или привлечения к ответственности.

Существует много решений этой проблемы, одно из которых — попросить этих Агентов предоставить Уникальный ID. Однако решение этой проблемы не является первоначальным фокусом Trusted Agent Delegation.

Что дальше

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

Наш фокус — на преодолении разрыва между работающим кодом и появляющимися спецификациями в рамках рабочих групп и деятельности, таких как Web Bot Auth, AIPREFs, OAuth, WIMSE и MOLE. Мы делаем это, в том числе, путем совместного написания и доработки открытых протоколов, таких как WBA и MOLE, а также создания и развертывания реализаций этих протоколов в масштабе.

Мы также объявляем о создании коалиции Trusted Agent Delegation (TAD). Цель TAD — собрать группу представителей экосистемы для обсуждения всего набора проблем, изложенного в этом документе, изучить все существующие протоколы, а затем, при необходимости, вынести более четко определенные проблемы или задачи на рассмотрение IETF. Мы намерены проводить встречи на полях IETF и семинары в будущем для облегчения обсуждения.

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

Что вы можете сделать сегодня

Открытая, интероперабельная основа — вот куда мы движемся, начиная с TAD. Но вам не нужно ждать новых протоколов, чтобы начать возвращать себе видимость и контроль. Начиная с этой недели, клиенты Cloudflare могут предпринять три конкретных шага:

1. Увидеть, какие Агенты находятся на вашем сайте и что они делают. Security Analytics теперь выделяет Персональных Помощников в отдельную категорию трафика, а новый виджет отображает список всех Агентов, посещающих ваш сайт, сколько запросов каждый из них отправляет, какие пути он затрагивает и с какими ошибками сталкивается. Необъяснимый автоматизированный трафик становится трафиком, который вы можете анализировать. А для более широкой картины того, как ИИ-краулеры и боты влияют на ваш бизнес, включая то, как много каждый Оператор сканирует по сравнению с трафиком, который он отправляет обратно, клиенты Enterprise Bot Management могут использовать Business Insights.
2. Установить доступ на ваших условиях, для каждого Агента. Используя политики доступа для ИИ-краулеров и Агентов, вы можете приветствовать Агентов, которые приносят вам бизнес, и ограничивать тех, которые его не приносят — разрешить Агенту доступ ко всему сайту, заблокировать его только на страницах с рекламой или заблокировать полностью. Ваши политики для поиска и обучения остаются независимыми.
3. Привязать Агента к пользователю, от имени которого он действует, и реагировать на это. Для сайтов, использующих Account Abuse Protection (ранний доступ), каждый вход в систему и регистрация теперь показывают, сделал ли запрос персональный Агент и какой именно. Когда злоумышленник злоупотребляет общим Агентом в одной учетной записи, вы можете заблокировать эту учетную запись — с помощью правила WAF, использующего хешированный ID ее Пользователя, — не блокируя Агента для всех остальных легитимных пользователей за ним. Это первый конкретный ответ на проблему Смешения трафика, описанную выше: вы наконец можете видеть за Агентом Пользователя и реагировать соответствующим образом.

Это первые строительные блоки видения, уже запущенные в производство. Будут и другие по мере созревания стандартов.

А если у вашей компании более ограничительная позиция в отношении Агентов, мы будем рады услышать ее. Свяжитесь с нами и поделитесь своими проблемами напрямую. Мы стремимся помочь построить Интернет, где владельцы сайтов имеют видимость и контроль, но где Агенты также имеют максимально разумный доступ в рамках этих средств контроля. Вы можете обратиться в свою службу поддержки клиентов или написать нам по адресу crawlercontrols@cloudflare.com.