Агенты — не люди (хотя в каком-то смысле всё же люди)
- ИИ-агенты действуют в интернете от имени миллионов людей; их трафик быстро растёт и вскоре может превзойти обычный просмотр людьми.
- Сайты видят агента, а не пользователя, из-за чего сложнее проверять личность, предотвращать мошенничество и связывать действия с конкретным человеком.
- Для работы с агентами статье предлагает создать механизмы идентичности, репутации и ответственности пользователей, агентов и их операторов.
Почему это важно: Такие механизмы, по тексту, нужны, чтобы расширять доступ агентов к сайтам, сохраняя связь между сайтами и пользователями.
ИИ-агенты уже действуют в интернете от имени миллионов людей. Для сайта агент может принимать самые разные формы. Он может быть неотличим от человека, выполняющего задачу, а может выглядеть как один посетитель, представляющий множество пользователей. Из-за этого сайт теряет возможность распознавать пользователей, стоящих за агентом, обслуживать их и привлекать к ответственности, а когда что-то идет не так, именно сайт несет связанные с этим расходы. В этой статье утверждается, что для максимального расширения доступа агентов к сайтам экосистеме необходимо разработать новые механизмы, сохраняющие связь между сайтами и пользователями. В сфере безопасности и предотвращения мошенничества для этого традиционно нужны три составляющие: идентичность, репутация и ответственность. Они позволяют сайтам ответить на вопросы: правдиво ли действующее лицо сообщает, кто оно? Можно ли ему доверять? И кто отвечает за его действия?
«Персональные ИИ-агенты» (для краткости — «агенты») — это автоматизированные системы, которые получают инструкции от человека («пользователя») и добиваются цели, управляя облачным компьютером или браузером. Обычно их размещает и обслуживает «оператор» в рамках управляемого сервиса или потребительского предложения. В качестве примеров можно назвать 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 для этой цели предусмотрен идентификатор сессии.
- Учетная запись — сайтам нужен способ связывать запросы с одним и тем же пользователем в разных сессиях. Это может быть постоянный идентификатор пользователя, назначенный оператором или третьей стороной и сохраняющийся в учетной записи у оператора. Например, один и тот же агент может каждый день посещать один сайт с одним и тем же идентификатором. Такой подход позволит реализовать, например, сценарий «Свяжите учетную запись на вашем сайте с учетной записью агента».
- Уникальный идентификатор — некоторым сайтам может понадобиться уникальный идентификатор для каждого пользователя, выданный третьей стороной и сохраняющийся при смене операторов, учетных записей, агентов и сессий. Он может пригодиться для операций с высоким уровнем риска, а также сайтам, которым нужно ограничивать доступ к дорогостоящему ресурсу или соблюдать очень строгие обязательства и требования. Для этого могут использоваться государственные удостоверения личности, проверка личности третьей стороной и децентрализованные технологии, такие как Proof of Human.
В конечном счете сами сайты решают, какие сведения нужны, чтобы клиент мог ответить на вопрос: «Разрешено ли субъекту, стоящему за этим запросом, выполнить это действие в данный момент?». Во многих случаях для передачи таких сведений уже существуют или разрабатываются протоколы: WBA передает идентификатор платформы агента, MOLE — сведения о репутации пользователя, OAuth — идентификаторы учетных записей и так далее.
Утверждения
Помимо идентификации, для некоторых действий нужны сведения о реальном человеке, например о том, исполнилось ли ему 18 лет или является ли он держателем карты (Сбой проверки личности, Мошенничество со стороны клиента). Часто оператор проверяет эти сведения при регистрации или ими уже располагает третья сторона.
Чтобы разрешить агентам доступ к сайтам или действиям с такими ограничениями, нужны механизмы, с помощью которых сайты смогут запрашивать эти сведения, а операторы или третьи стороны — предоставлять их.
Правила доступа агентов к сайтам
Сегодня агент узнает правила сайта, пробуя выполнить действие и анализируя ответ сайта (обычно — блокируют ли его). Это напрасно расходует ресурсы обеих сторон, а в некоторых случаях заставляет добросовестных агентов выглядеть злоумышленниками. Файл robots.txt указывает, куда может заходить поисковый робот, но он не вполне подходит для описания действий, разрешенных агентам.
Сайтам нужен машиночитаемый способ публиковать список действий, разрешенных агентам. Рабочая группа по разработке интернет-стандартов (IETF) активно работает над механизмами выражения предпочтений, прежде всего в рамках рабочей группы по предпочтениям в сфере ИИ. Однако группа сосредоточена на выражении предпочтений по использованию данных (например, для обучения, инференса и поиска), и пока нет отдельной группы, занимающейся более широкой потребностью в механизмах выражения предпочтений, о которых говорится здесь.
Об открытом исходном коде и локальных агентах
Агенты, которые не работают как «посредники» (например, агенты на устройстве или локально размещенные агенты, такие как OpenClaw), вызывают другие опасения. В первую очередь они выглядят как автоматизированные системы — и являются ими, —, но для формирования репутации или привлечения к ответственности не существует единой стороны.
Существуют разные способы решения этой проблемы; один из них — требовать от таких агентов уникальный идентификатор. Однако ее решение не входит в число первоначальных приоритетов Trusted Agent Delegation.
Что дальше
Практические решения проблем, с которыми сталкиваются сайты, не появятся на основе разрозненных механизмов отдельных поставщиков. Для них нужны открытые, совместимые стандарты, опирающиеся на реальный опыт. Мы уже активно сотрудничаем с представителями всей экосистемы и продолжим эту работу: с крупными операторами, компаниями по проверке личности, поставщиками платежных услуг, продавцами, издателями, поставщиками прокси-сервисов и компаниями, предлагающими облачные браузеры. Наша цель — согласовать операционные требования с текущей работой над этими проблемами в IETF и других организациях.
Мы стремимся устранить разрыв между работающим кодом и разрабатываемыми спецификациями в разных рабочих группах и инициативах, таких как Web Bot Auth, AIPREFs, OAuth, WIMSE и MOLE. В частности, для этого мы участвуем в совместной разработке и совершенствовании открытых протоколов, таких как WBA и MOLE, а также создаем и внедряем их реализации в промышленных масштабах.
Мы также объявляем о создании коалиции Trusted Agent Delegation (TAD). Цель TAD — собрать представителей всей экосистемы для обсуждения общего круга проблем, изложенных в этом документе, и анализа существующих протоколов, а затем при необходимости передавать в IETF более четко сформулированные проблемы для дальнейшей проработки. В будущем мы планируем проводить встречи на полях IETF и семинары, чтобы содействовать обсуждению.
Если вы разрабатываете агентов или среды их выполнения, управляете периферийной или облачной платформой, а также занимаетесь коммерческими приложениями, приложениями для обеспечения соответствия требованиям или связанной с ними инфраструктурой, нам важно ваше участие. Подробнее о том, как присоединиться, можно узнать на этой странице.
Что можно сделать уже сегодня
Мы движемся к открытой совместимой основе, начиная с TAD. Но не нужно ждать появления новых протоколов, чтобы вернуть себе видимость и контроль. Начиная с этой недели, клиенты Cloudflare могут предпринять три конкретных шага:
Узнайте, какие агенты посещают ваш сайт и что они делают. В аналитике безопасности теперь персональные помощники выделены в отдельную категорию трафика. Кроме того, новый виджет показывает всех агентов, посещающих ваш сайт, количество отправленных каждым из них запросов, посещаемые ими страницы и возникающие ошибки. Необъяснимый автоматизированный трафик становится понятным. А чтобы получить более полное представление о влиянии ИИ-краулеров и ботов на ваш бизнес, в том числе узнать, сколько запросов отправляет каждый оператор и сколько трафика он возвращает, клиенты Enterprise Bot Management могут воспользоваться инструментом Business Insights.
Настраивайте доступ для каждого агента по своим правилам. С помощью правил доступа для ИИ-краулеров и агентов можно приветствовать агентов, которые приносят вам пользу, и ограничивать доступ тем, от кого пользы нет: разрешить агенту доступ ко всему сайту, заблокировать его только на страницах с рекламой или полностью запретить ему доступ. Правила для поиска и обучения остаются независимыми.
Связывайте агента с пользователем, от имени которого он действует, и принимайте меры. На сайтах, использующих Account Abuse Protection (ранний доступ), при каждой попытке входа или регистрации теперь отображается, отправил ли запрос персональный агент и какой именно. Если злоумышленник использует общего агента для атаки на одну учетную запись, вы можете принять меры в отношении этой учетной записи — с помощью правила WAF, использующего хешированный идентификатор пользователя, — не блокируя агента для всех остальных добросовестных пользователей. Это первый конкретный ответ на проблему Смешения трафика, описанную выше: теперь можно видеть не только агента, но и пользователя, и действовать соответствующим образом.
Это первые элементы нашего видения, уже работающие в промышленной среде. По мере развития стандартов появятся и другие.
Если ваша компания придерживается более строгой позиции в отношении агентов, мы будем рады ее услышать. Свяжитесь с нами и расскажите о своих проблемах напрямую. Мы хотим помочь создать интернет, в котором владельцы сайтов располагают видимостью и контролем, а агенты при этом получают максимально широкий доступ в разумных пределах. Вы можете обратиться в службу поддержки клиентов или написать нам по адресу crawlercontrols@cloudflare.com.
