Поиск агентов раскрывает намерение до выбора

Summary

Обнаружение агентов способно показать замысел организации до выбора: фильтры возможностей, географии, доверия, времени и последовательные уточнения описывают будущую работу, даже если текст запроса зашифрован.
draft-iannone-dawn-privacy-considerations-00 называет риски наблюдения, хранения, корреляции и идентификации, но остаётся незавершённым индивидуальным Internet-Draft: сравнение с DNS, вопрос приватности и аудита, анкета RFC 6973 и несколько угроз ещё помечены TBD.
Daniel Kade предлагает бюджет раскрытия выбора, охватывающий точность атрибутов, минимальный размер множества кандидатов, окно связывания, разделение ролей, путь начальной настройки, аудиторию результатов и срок хранения. Это редакционное предложение, а не требование DAWN или IETF.

Первое раскрытие происходит раньше первого контакта

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

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

Запрос «перевод» широк. Если добавить языковую пару, ограничение на медицинские данные, редкую схему аттестации, европейскую юрисдикцию, предел задержки и немедленную доступность, поиск может описать конкретный клинический процесс. Во второй попытке снимается задержка, в третьей меняется юрисдикция — и последовательность показывает, каким требованием готовы поступиться. Наблюдателю не обязательно видеть окончательно выбранного агента: траектория поиска уже раскрыла цель.

Проект требований DAWN выводит механизмы и политики выбора за рамки документа. Для требований, ещё не фиксирующих протокол, такая граница разумна. Но это не граница наблюдаемости. Сервис, видящий проверенные атрибуты, порядок их ослабления, возвращённых кандидатов и время обращений, способен восстановить политику, которую спецификация не стала определять.

Шифрование скрывает фразу, но не форму поиска

Датированный 22 мая 2026 года draft-iannone-dawn-privacy-considerations-00 прямо называет проблему. Инфраструктура обнаружения может увидеть, какие организации спрашивают о каких возможностях, и вывести из этого их интересы, режим нагрузки и операционное поведение. Сохранённая история запросов раскрывает рабочие процессы. Повторения позволяют корреляцию. Названия организаций, владельцы, операторы и метаданные возможностей могут идентифицировать участников.

Однако документ нельзя выдавать за законченную позицию IETF. Это действующий индивидуальный проект без потока RFC, ответственного Area Director или телесовещания IESG. Вторжение, ошибочная атрибуция, вторичное использование, разглашение и исключение ещё не разработаны. Сравнение с DNS, раздел «Privacy vs Auditability», анкета RFC 6973, специфические меры DAWN и Security Considerations оставлены на будущее. Сегодня проект ценен тем, что показывает незакрытые решения, а не тем, что предлагает окончательные ответы.

Шифрование может скрыть смысл сообщения от части наблюдателей. Оно не удаляет назначение, размер, момент, повтор, неудачу и объём ответа. RFC 7258 напоминает: внешние признаки и корреляция тоже могут быть формой наблюдения независимо от заявленной мотивации. Вопрос «используется ли TLS?» слишком узок. Для управления важнее, кто способен соединить какие фрагменты и на какой срок.

Полезное сравнение даёт Oblivious HTTP из RFC 9458. Ретранслятор может знать клиента, не читая открытый запрос; шлюз может читать запрос, не видя клиента напрямую. Но размер, синхронизация, идентификаторы ключей, повторное использование соединения и неодинаковое обслуживание оставляют зацепки. Малое множество анонимности ослабляет разделение, а конструкция предполагает отсутствие сговора. Две раздельные коробки на схеме не доказывают приватность эксплуатации, если журналы, облачная учётная запись или аналитика общие.

Множество кандидатов отвечает на большее, чем спросили

Защита текста бесполезна, если выдача состоит из одной сущности. Единственный кандидат сам объясняет смысл условий. Поэтому достаточно крупное и разнообразное множество результатов — свойство приватности, а не только доступности. И наоборот, сервис, принимающий крайне редкие комбинации и мгновенно сообщающий число совпадений, превращается в оракул наличия свойств в своём каталоге.

Oblivious DoH в RFC 9230 при определённых предпосылках разделяет того, кто знает клиента, и того, кто видит открытый DNS-запрос. RFC 9156 помогает рассуждать о минимизации и детализации. В обнаружении агентов сложнее: ценность создаёт сочетание многих атрибутов, а не разрешение одного имени. Поэтапный поиск от широких классов к необходимым деталям позволяет не вкладывать весь план в одну посылку. Но общий идентификатор, соединение или точное время снова склеивают этапы. Детализацию и связываемость нельзя регулировать независимо.

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

У выдачи нет единой аудитории. Публичный результат, результат для авторизованного клиента и персонализированный ответ создают разные поверхности. Ограничение доступа защищает чувствительные сведения поставщика, но крепче привязывает удостоверенную личность к фильтрам. Персонализация повышает полезность, однако различия ответов раскрывают классы клиентов или внутренние правила. Смена защищаемой стороны перемещает утечку, не обязательно устраняя её.

Приватность и аудит не обязаны быть ложным выбором

Незавершённый раздел «Privacy vs Auditability» указывает на самый трудный институциональный вопрос. Оператор хочет расследовать злоупотребления, массовый сбор, ошибочное исключение и падение качества. Договор или надзор могут требовать объяснения. Если для этого централизованно хранить каждый запрос, полный список кандидатов и постоянный идентификатор, аудиторская система становится архивом намерений пользователей.

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

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

Бюджет раскрытия выбора

Daniel Kade предлагает бюджет раскрытия выбора, а не центральный журнал каждого поиска. Бюджет заранее определяет, сколько политики выбора может стать видимым за один запрос или их серию, измеряет реальную работу и делает исключения срочными и пересматриваемыми.

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

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

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

В бюджет не следует собирать сырые запросы, удостоверения, содержимое задания, персональные данные, закрытые веса ранжирования или личности всех кандидатов. Грубые агрегаты, короткие локальные счётчики, синтетические тесты и независимая проверка конфигурации покрывают значительную часть задач. Не иметь лишние данные надёжнее, чем обещать ими не пользоваться.

Чего документы пока не доказывают

Изученные источники не подтверждают производственное внедрение DAWN, масштабы принятия, показатели быстродействия, реальный инцидент приватности или юридический вывод. PIR назван возможным компонентом, но не выбранным способом и не доказанным решением в таком масштабе. Из технических документов нельзя вывести соответствие конкретному закону.

Предложенный здесь бюджет не является консенсусом IETF, обязательным требованием реализации или правовой нормой. Это способ преобразовать видимый пробел в проверяемые эксплуатационные вопросы. Надёжно можно сказать проще: обнаружение полезно потому, что сравнивает атрибуты машинно, а те же атрибуты и порядок сравнения выражают намерение.

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

Поиск агентов раскрывает намерение ещё до выбора агента

Почему это важно

Summary

Первое раскрытие происходит раньше первого контакта

Шифрование скрывает фразу, но не форму поиска

Множество кандидатов отвечает на большее, чем спросили

Приватность и аудит не обязаны быть ложным выбором

Бюджет раскрытия выбора

Чего документы пока не доказывают

Sources

Подробный контекст профиля

Стратегическое сообщество

Альянс лидеров

Брифинг Стратегического сообщества

Обзор Альянса лидеров