Паттерн в корпусе
В описаниях инцидентов и постмортемах повторяется характерная сигнатура: агент достигает живого стороннего эндпоинта — государственного портала, торговой платформы, поверхности обмена сообщениями — без указания оператора сделать это. Публичная трактовка прибегает к языку согласования: модель чего-то хотела, модель вышла из-под контроля. Операционная сигнатура уже и более податлива. Агент разрешил назначение, не входившее в его предполагаемый охват, а окружающие средства контроля этого не заметили, потому что они были построены для ограничения объёма, а не охвата.
Это различие важно, потому что оно определяет, какое средство контроля действительно устраняет проблему. Если сбой — это рассогласование, исправление — лучшая политика или лучший промпт. Если сбой — это маршрутизация и охват, исправление — бюджет исходящего трафика, выраженный как набор назначений и возможностей, применяемый вне фреймворка агента.
Почему бюджеты скорости это упускают
Бюджет скорости ограничивает запросы за единицу времени. Это средство контроля нагрузки, унаследованное от API-шлюзов, где забота состояла в защите бэкенда от шумного клиента. Он отвечает на вопрос сколько, а не куда.
Рассмотрим режим отказа напрямую. Один корректно сформированный HTTP-запрос к непреднамеренному хосту укладывается в любой разумный бюджет скорости. Один запрос в минуту — это бюджет скорости, который большинство операторов сочли бы консервативным; его также достаточно, чтобы отправить форму, опубликовать сообщение или запустить рабочий процесс в сторонней системе. Лимит скорости никогда не срабатывает, потому что объём ничтожен. Запрос не чрезмерен; он просто адресован не туда.
Путаница возникает потому, что лимиты скорости и лимиты охвата часто развёртываются вместе и оба находятся near сетевой границы. Но это разные классы контроля. Лимит скорости — это контроль ёмкости. Лимит охвата — это контроль авторизации. Контроли ёмкости деградируют плавно под нагрузкой; контроли авторизации бинарны для каждого назначения. Если принимать первое за замену второго, множество назначений остаётся неограниченным.
Сбой не в объёме. Он в множестве достижимых назначений и в возможностях, которыми агент обладает в каждом из них.
Проектирование бюджета охвата
Бюджет охвата — это перечисление классов назначений, которых может касаться запуск агента, привязанное к возможностям, разрешённым в каждом из них. Он принадлежит спецификации запуска, а не определению инструмента.
Это размещение намеренно. Определение инструмента описывает, что инструмент может делать вообще; спецификация запуска описывает, что разрешено делать именно этому запуску. Если охват объявлен на инструменте, каждый запуск, загружающий инструмент, наследует полный охват инструмента, и оператор теряет возможность ограничить конкретную задачу. Если охват объявлен на запуске, один и тот же инструмент можно загрузить под узким бюджетом для задачи суммирования только для чтения и под более широким бюджетом для задачи, которой законно требуется запись.
Запись бюджета связывает класс назначения с набором возможностей. Классы назначений должны быть достаточно грубыми, чтобы их можно было поддерживать, и достаточно конкретными, чтобы быть осмысленными: внутренний хост документации, именованный API партнёра, публичный источник данных, поверхность обмена сообщениями. Возможности следует черпать из небольшого закрытого словаря, например:
read-only fetch
authenticated write
form submission
file transfer (inbound)
file transfer (outbound)
Словарь должен быть закрытым, чтобы бюджеты можно было механически сравнивать и диффить. Открытая строка возможностей приглашает дрейф.
Два свойства делают бюджет пригодным на практике.
Во-первых, он монотонен в пределах запуска. Агент может сузить свой охват — отбросив класс назначения, который ему больше не нужен, — но не может расширить его без нового события авторизации. Сужение — безопасная операция, потому что она только удаляет возможности. Расширение — привилегированная операция, потому что оно добавляет охват, и оно должно порождать аудируемую запись: кто авторизовал расширение, для какого назначения, для какой возможности, в какой момент запуска.
Во-вторых, бюджет объявляется до начала запуска, а не выводится из наблюдаемого поведения. Бюджет, выведенный из того, что агент случайно сделал, — это описание,
](/media/circuit-board-macro-5a0c33-e1886b.jpg)
Точки применения
Бюджет хорош настолько, насколько хороша точка, в которой он применяется. Три точки применения несут большую часть веса.
Разрешайте назначения на прокси исходящего трафика, а не внутри фреймворка агента. Если фреймворк применяет охват, контроль связан с путём вызова инструментов фреймворка, его моделью плагинов и его версией. Замена фреймворка молча удаляет контроль. Прокси исходящего трафика, расположенный между средой выполнения агента и сетью, применяет охват независимо от того, какой фреймворк породил запрос. Прокси разрешает назначение — хост, порт и, где применимо, разрешённый адрес — и проверяет его по объявленному бюджету запуска до установления соединения. Фреймворк агента можно заменить, не трогая плоскость управления.
Логируйте отказы как первоклассные события. Отклонённый запрос должен порождать структурированное событие, несущее запрошенное назначение, отклонённую возможность, идентификатор запуска и запись бюджета, которая позволила бы его, если таковая есть. Отказы — не шум для фильтрации; это первичный сигнал о том, что запуск попытался превысить свой охват. Они должны быть доступны для запросов наряду с успешными запросами, а не погребены в отладочном логе.
Сверяйте после каждого запуска. После завершения запуска сравните наблюдаемое множество назначений с объявленным бюджетом. Расхождение — назначение, которого достигли, но не объявили, или возможность, которую задействовали, но не предоставили, — это дефект. Его следует сортировать, как любой другой дефект, с первопричиной и исправлением, а не отмечать как курьёз. Шаг сверки превращает бюджет из статического объявления в петлю обратной связи.
Честный компромисс
Бюджеты охвата стоят операционной гибкости. Каждый новый класс назначения — это изменение спецификации запуска, а значит, шаг управления изменениями, прежде чем агент сможет обратиться к новому хосту. В средах, где множество законных назначений действительно открыто — например, исследовательские агенты, следующие по ссылкам в публичном вебе, — строгое перечисление непрактично, и операторы будут склонны объявить широкий класс вроде публичный интернет, только чтение.
Это искушение не фатально, но его следует назвать. Широкий класс только для чтения всё ещё ограничивает возможности, а именно там сосредоточена большая часть риска: чтение публичной страницы редко бывает вредоносным действием, тогда как отправка формы или запись в аутентифицированный эндпоинт — часто. Компромисс реален, но ограничен. Альтернатива — никакого объявления охвата вообще и лимит скорости, подменяющий авторизацию, — не компромисс; это отсутствие контроля.
Практическая позиция — начать с грубого бюджета, который действительно применяется, затем сужать его по мере стабилизации наблюдаемого множества назначений. Грубый бюджет, который отклоняет не то, что нужно, полезнее точного бюджета, существующего только на бумаге.