Разве это не то же самое, что области доступа в OAuth?

Области - это половина, и половина более старая. Область говорит, что учётные данные вправе делать. Она не говорит, на что согласился человек за этими данными, а это другая и обычно более узкая вещь, и она не меняется, когда он передумал: область впечатана в токен при выдаче. Второй вопрос списка - тот, на который один OAuth ответить не может, а третий - тот, на который он отвечает плохо, потому что отзыв перечислением - не отзыв.

Почему запись обязана предъявляться задним числом?

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

Достаточно ли окна подтверждения?

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

Какова наименьшая версия этого, которую стоит строить?

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

СодержаниеРазделов: 7

1. Где запись и можно ли предъявить её потом?
2. Проверяет её система или несёт агент?
3. Если принципал сузит условия сегодня, станут ли уже, чем были, учётные данные, выданные месяц назад?
4. Может ли агент менять собственные условия?
5. Что происходит с запросом, выпавшим чуть за пределы?
6. Записывается ли каждый вызов с привязкой к агенту, принципалу и учётным данным?
Что значит пройти проверку

Экономика агентов14 сентября 2026 г.4 мин чтения

Шесть вопросов к любому, кто говорит, что ваш агент уполномочен

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

Mikhail Savchenko

Короткий ответ

Спросите шесть вещей. Где лежит запись о том, на что согласился принципал, и можно ли предъявить её потом. Проверяет ли её система в момент вызова или она лежит в контексте агента. Если принципал сузит условия сегодня, станут ли уже, чем были, учётные данные, выданные в прошлом месяце. Может ли агент менять собственные условия. Что происходит с запросом, который выпал чуть за их пределы. И записывается ли каждый вызов с привязкой к агенту, принципалу и учётным данным, по которым он пришёл. Система, отвечающая на все шесть, имеет полномочие. Система, отвечающая на первый, имеет страницу настроек.

Платёжные рельсы для агентов появляются быстро. И все они без исключения именно рельсы: говорят, как ценность движется после того, как решение принято, и про само решение молчат. Платёжному протоколу так и положено. Просто интересная половина остаётся тому, кто стоит выше, - а это теперь почти все.

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

Вот шесть, которые мы задали бы любому, кто заявляет, что агент уполномочен, - включая самих себя.

1. Где запись и можно ли предъявить её потом?

Не экран настроек, а именно запись: на что согласился этот человек, привязанная к этому агенту, с версиями, и достать её потом должен суметь тот, кого при этом не было.

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

2. Проверяет её система или несёт агент?

Правило в промпте агента — это совет. Агент читает чужой текст по ходу работы, часть этого текста писал тот, у кого есть интерес в исходе, и указание живёт ровно до того, как посреди задачи попадётся что-нибудь убедительнее.

Правило, которое проверяет сервер, стоит, в чём бы агента ни убедили.

На этом вопросе молча проваливается большинство решений, потому что вариант с промптом показывают точно так же. Разница видна только тогда, когда появляется противник, - а к этому моменту разница и есть всё.

3. Если принципал сузит условия сегодня, станут ли уже, чем были, учётные данные, выданные месяц назад?

Почти все говорят «да» и имеют в виду «нет».

Если права впечатаны в учётные данные при выдаче, то сужение условий не меняет ничего из уже разошедшегося. Лекарство предлагают одно - перебор: найти все выданные учётные данные и отозвать, включая забытые. А забытые как раз и важны.

Альтернатива стоит одного обращения к базе. Считайте действующие права как пересечение областей учётных данных и текущих условий принципала на каждом запросе. Тогда сужение достаёт до всего само, и «вы можете отозвать» перестаёт значить «вы можете отозвать то, что найдёте».

4. Может ли агент менять собственные условия?

Если да, никаких условий нет. Вопрос выглядит слишком очевидным, чтобы его задавать, а задавать стоит из-за того, откуда обычно берётся ответ: вызовы делает агент, и инструмент, который меняет настройки, удобнее всего положить рядом с остальными.

У нас есть область доступа для изменения мандата. Она есть, потому что принципалам нужно менять решения. Агенту её не выдают никогда.

5. Что происходит с запросом, выпавшим чуть за пределы?

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

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

6. Записывается ли каждый вызов с привязкой к агенту, принципалу и учётным данным?

Ко всем трём, потому что каждая потом отвечает на свой вопрос: что делал этот агент, что делали от имени этого человека и какими учётными данными - может быть, забытыми, может быть, теми, которые давно следовало отозвать.

Это самый дешёвый пункт списка, и откладывают его чаще прочих - на том основании, что это наблюдаемость, а не контроль. Это контроль. «Кто это разрешил» - не тот вопрос, который можно задавать только заранее.

Что значит пройти проверку

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

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

В цифрах

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

Вопросы

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