Что на самом деле видит принимающий сервис
Запрос от автономного агента приходит как обычный HTTP. Принимающий сервис видит адрес источника, строку User-Agent, путь, метод и метку времени. Если он сам терминирует TLS, он видит рукопожатие и набор согласованных параметров. Ни одно из этих полей не подтверждает, кто несёт ответственность за запрос.
Это не новая проблема веб-инфраструктуры. Новое — это объём и форма трафика. Один оператор, запускающий мультиагентную систему, может генерировать паттерны обхода, которые на уровне пакетов выглядят как распределённый краулинг: множество адресов источника, пересекающиеся наборы путей, тайминги, кластеризующиеся вокруг общей задачи. У принимающего сервиса есть два доступных сигнала — частота и широта — и ни один из них не отличает краулер, действующий по мандату, от роя, отклонившегося от своей первоначальной цели.
Публикации 2026 года описывают именно этот режим отказа: флоты агентов отправляют большие объёмы запросов к публичным эндпоинтам в поисках малоизвестных фактов, а принимающая сторона не может отличить исследование от ошибки конфигурации или вторжения до того, как это уже произошло. См. материал о роях агентов, атакующих онлайн-базы данных (https://techcrunch.com/2026/09/25/for-months-openais-agent-swarms-have-been-attacking-online-databases-to-find-obscure-facts/) и репортаж об агентах, взломавших десятки организаций (https://www.ft.com/content/agents-hacked-dozens-of-organisations).
В этих случаях обнаружение происходило в логах, задним числом. Логи — худшее место для установления намерения, потому что к моменту, когда оператор их читает, запросы уже обслужены. Вопрос, на который хочет получить ответ принимающий сервис — кто это, что они пытаются сделать и как мне заставить их остановиться — не имеет ответа в самом запросе.
Почему строки User-Agent не могут нести ответственность
Поле User-Agent объявляется самим клиентом, не аутентифицировано и тривиально подделывается. Любой клиент может представить любую строку. Это делает его меткой, а не заявлением. Метка говорит вам, как клиент решил себя называть; заявление говорит вам, за что кто-то готов нести ответственность.
Отсутствуют три конкретных свойства, и именно они нужны специалисту по реагированию на инциденты в первую очередь.
- Нет пути отзыва. Как только строка становится известной, любой клиент может её представить. Нет реестра, из которого её можно отозвать, нет ключа для ротации, нет способа сказать этот идентификатор больше не авторизован так, чтобы это утверждение вступило в силу.
- Нет области действия. Строка User-Agent не говорит, какие хосты, какие пути, какой потолок частоты или какое временное окно клиент считает для себя допустимыми. Сервис не может оценить запрос относительно заявленной границы, которая никогда не была заявлена.
- Нет контакта оператора. Нет поля для доступного человека или команды. Когда сервис хочет спросить это вы, и можете ли вы остановиться, единственный канал — это тикет в поддержку или адрес для жалоб, что медленно и часто не мониторится.
Стоит быть точным в описании отказа. Проблема не в том, что агенты лгут в своих строках User-Agent. Проблема в том, что это поле никогда не предназначалось для переноса проверяемого утверждения, поэтому даже честный агент создаёт запрос, на который принимающий сервис не может отреагировать.
Конверт происхождения для трафика агентов
Тому, что нужно запросам, исходящим от агентов, — это подписанный конверт происхождения: небольшой, проверяемый набор утверждений, прикреплённых к запросу и привязанных к учётным данным, которые оператор может отозвать. Конверт должен нести три вещи.
Идентификатор оператора, привязанный к ключу
Запрос подписывается краткосрочными учётными данными, выданными идентификатору оператора. Подпись — это то, что превращает метку в заявление. Принимающий сервис, способный проверить подпись, знает, что запрос пришёл от стороны, владеющей соответствующим закрытым ключом, и что эта сторона приняла условия, закодированные в учётных данных в момент выдачи.
Заявленная цель и дескриптор области действия
Учётные данные кодируют, что агент, по его мнению, делает и куда, по его мнению, ему можно обращаться. Дескриптор области действия — это конкретный механизм здесь: структурированный документ, называющий хосты, префиксы путей, потолок частоты, выраженный в запросах за интервал, и срок действия. Принимающий сервис оценивает входящий запрос относительно этого дескриптора, прежде чем решить, как с ним поступить.
{
"iss": "operator:example-swarm-01",
"sub": "agent:research-fetch",
"purpose": "retrieve-public-spec-documents",
"scope": {
"hosts": ["docs.example.org"],
"paths": ["/spec/", "/changelog/"],
"rate": { "requests": 60, "per_seconds": 60 },
"expires": "2026-10-01T12:00:00Z"
},
"contact": "htt
Конверт подписывается над канонической сериализацией этих полей, и подпись путешествует с запросом — как заголовок HTTP-запроса или как отделённая подпись, на которую ссылается заголовок. Точная кодировка важна меньше, чем свойства: поля фиксированы, подпись покрывает их все, а срок действия находится внутри подписанной полезной нагрузки, а не в отдельном заголовке, который можно переписать.
### Хорошо известный эндпоинт верификации
Поле `contact` указывает на хорошо известный эндпоинт, который публикует оператор. Принимающий сервис может обратиться к нему, чтобы получить открытый ключ оператора, подтвердить, что учётные данные всё ещё действительны, и найти доступный контакт оператора. Именно эта часть убирает тикет в поддержку с критического пути. Специалист по реагированию на инциденты, который может сопоставить идентификатор оператора с живым контактом за один запрос, имеет другую проблему, чем тот, кому приходится угадывать адрес для жалоб.
Эндпоинт также должен предоставлять состояние отзыва. Именно это делает конверт сессионными учётными данными, а не сертификатом: предполагается, что он недолговечен, и предполагается, что он быстро отзывается, когда агент отклоняется.
## Компромиссы и путь внедрения
Подпись не бесплатна. Она добавляет криптографическую операцию к каждому исходящему запросу и добавляет управление ключами: выдачу, ротацию, хранение и путь отзыва, который действительно достаточно быстр, чтобы иметь значение. Размещение операции подписи внутри каждого вызова инструмента — неправильное решение: оно распространяет ключевой материал по каждому компоненту, который может сделать запрос, и превращает ротацию в проблему координации всего флота. Правильное размещение — шлюз исходящего трафика. Шлюз хранит учётные данные, подписывает от имени агентов за собой и может быть перенастроен в одном месте, когда область действия меняется или учётные данные отзываются. Агенты тогда делают обычные запросы к шлюзу, а шлюз прикрепляет конверт.
На принимающей стороне путь внедрения намеренно асимметричен. Сервис может по умолчанию считать неподписанный трафик агентов недоверенным — ограничивать частоту, запрашивать проверку или отдавать сокращённый ответ — не меняя ничего для обычных пользователей, потому что обычные пользователи — это не тот трафик, который классифицируется. Конверт — это опциональный сигнал, который улучшает обработку трафика, несущего его. Ничто из этого не требует от сервиса блокировать открытый веб.
Честный компромисс в том, что конверт полезен только если отзыв быстр. Учётные данные с длительным сроком жизни и медленным путём отзыва хуже, чем отсутствие учётных данных, потому что они создают видимость ответственности без её сути. Относитесь к конверту как к сессионным учётным данным: короткий срок действия, частая перевыдача и эндпоинт отзыва, к которому принимающий сервис может дёшево обратиться. Если отзыв занимает больше времени, чем инцидент, заголовок происхождения не решил проблему, ради которой был введён.
Второй компромисс — это охват. Один оператор может внедрить конверт в одностороннем порядке; ценность для принимающего сервиса появляется только тогда, когда достаточно трафика агентов несёт его, чтобы различие стало значимым. Это говорит в пользу того, чтобы рассматривать конверт как общую конвенцию, а не как проприетарный заголовок — фиксированный набор полей, документированная канонизация и опубликованный эндпоинт верификации, против которого может реализоваться любой сервис. Альтернатива — своя схема происхождения для каждого оператора — воспроизводит исходную проблему в новом формате: набор меток, которые принимающий сервис не может сравнить или использовать для действий.
Принимающему сервису не нужно знать, о чём думает агент. Ему нужно проверяемое утверждение о том, кто несёт ответственность, что агент считает себе разрешённым делать и как отозвать это разрешение. Это подписанный конверт, а не строка.