Слой инструкций — это не поверхность управления
Когда агенту дают инструмент, промпт часто содержит набор ограничений: не отправляй больше нескольких писем, не изменяй продакшн-записи, не превышай порог расходов. Эти ограничения носят рекомендательный характер. Это токены в контекстном окне, и модель, которая может вызвать инструмент, может вызвать его способами, которые промпт не предусмотрел. Модель может обобщить разрешённое действие в неразрешённое, выстроить инструменты в неожиданном порядке или просто не уследить за ограничением на длинной траектории. Промпт не принуждает — он подсказывает.
Полномочия, напротив, обеспечиваются ниже уровня модели. Они живут в учётных данных, в области действия токена, в ограничении частоты на эндпоинте и в аттестации, необходимой для продления доступа. Это не инструкции, которые модель может переинтерпретировать. Это ограничения, которые применяет среда исполнения. Если агент держит учётные данные, способные удалить базу данных, промпт «не удаляй базу данных» — это надежда, а не граница. Практическая единица контроля — не «разрешено или не разрешено». Это сколько, как часто и при какой аттестации.
Это различие становится важнее по мере того, как агенты переходят от одношагового использования инструментов к длительным циклам. В цикле поведение модели формируется тем, что она может делать, а не тем, что ей сказали. Поверхность управления — это набор возможностей, которыми она обладает, и пределы этих возможностей. Это и есть бюджет полномочий.
Почему промпты не могут нести полномочия
Промпт — это запрос. Учётные данные — это возможность. Когда агент вызывает инструмент, инструмент не читает промпт. Он проверяет токен, область действия, квоту и политику, привязанную к вызывающему. Если токен широкий, инструмент подчинится. Промпт невидим для точки принуждения.
Рассмотрим распространённый паттерн: агенту поручено суммировать тикеты поддержки, и ему дан инструмент, который также может обновлять статус тикета. Промпт говорит «только чтение». API инструмента принимает параметр записи. Модель, преследуя цель закрыть тикет, может установить этот параметр. Промпт не давал полномочий на запись, но учётные данные дали. Это не сбой промпта; это сбой проектирования полномочий.
То же касается частоты и объёма. Промпт может говорить «используй инструмент поиска умеренно». У эндпоинта нет квоты. Агент может вызвать его тысячи раз. Промпт не может обеспечить умеренность. Это может только квота.
Вот почему безопасность агентов лучше моделировать как расходуемый лимит полномочий. Каждая возможность — это грант с областью действия, квотой, сроком действия и условием продления. Модель может расходовать грант. Она не может его превысить. Точка принуждения — это инструмент, шлюз или эмитент учётных данных, а не промпт.
Проектирование бюджета полномочий
Бюджет полномочий выражает каждую возможность как ограниченный грант. У гранта четыре части:
- Область действия: на что может воздействовать возможность. Не «email», а «отправка внутренним получателям в домене поддержки». Не «база данных», а «чтение строк в таблице tickets».
- Квота: сколько и как часто. Число вызовов, объём данных, частота в минуту, общий расход против ресурса. Квоты применяются на шлюзе.
- Срок действия: когда грант истекает. Короткоживущие гранты сокращают окно, в котором скомпрометированный или несоответствующий агент может действовать. Истечение вынуждает продление, а это возможность для аттестации.
- Аттестация: какие доказательства требуются для продления или расширения гранта. Это может быть одобрение человека, подпись второго агента, проверка против движка политик или доказательство того, что предыдущая квота была израсходована в пределах области действия.
Бюджет должен быть виден планировщику. Если агент видит, что у него осталось три записи и два часа до истечения, он может рассуждать об исчерпании. Он может расставлять приоритеты, откладывать или запрашивать продление. Если бюджет невидим, агент обнаруживает пределы как ошибки, что ведёт к повторам, обходам и непредсказуемому поведению. Видимость превращает жёсткую остановку в ограничение планирования.
Разделяйте полномочия по виду. Полномочия на чтение мал riskованны и могут продлеваться автоматически в рамках сессии. Полномочия на запись более рискованны и должны требовать более узкой области действия и более короткого срока. Необратимые полномочия, такие как отправка внешнего сообщения, удаление данных или перевод средств, должны требовать явной аттестации на каждое расходование или очень малой квоты с участием человека в цикле. Пути продления должны соответственно различаться: гранты на чтение могут обновляться оркестратором; гранты на запись — проверкой политики; необратимые гранты — человеком или кворумом.
Конкретный механизм: шлюз полномочий стоит между агентом и инструментами. Агент предъявляет токен гранта. Шлюз проверяет токен, сверяет область действия с запрошенным действием, уменьшает квоту и регистрирует расходование. Если квота исчерпана или область действия превышена, шлюз возвращает структурированный отказ, который оркестратор может интерпретировать. Токен выдаётся сервисом учётных данных, который кодирует область действия, квоту, срок действия и требования аттестации. Модель никогда не видит базовые учётные данные; она видит только грант и его оставшийся бюджет.
Это не новая идея. Именно так уже работают облачный IAM, ограничение частоты API и безопасность на основе возможностей. Вклад в том, чтобы рассматривать полномочия агента как первоклассный расходуемый ресурс, о котором планировщик может рассуждать, а среда исполнения — применять.
Операционные последствия
Когда полномочия — это бюджет, реагирование на инциденты меняется. Вместо переписывания системного промпта и надежды, что модель подчинится, операторы отзывают грант. Отзыв немедленный и принудительный. Агент теряет возможность, а не просто инструкцию. Инцидент локализуется на уровне учётных данных, где и произошёл бы ущерб.
Аудиторский вывод становится реестром расходований против бюджетов. Каждая строка фиксирует грант, область действия, действие, оставшуюся квоту и аттестацию. Этот реестр читаем для рецензентов вне ML: безопасность, комплаенс и операции могут читать его, не понимая внутренностей модели. Они видят, что сделал агент, под какими полномочиями и остался ли он в пределах. Они также видят, когда грант был продлён и на каких доказательствах.
Исчерпание бюджета становится первоклассным состоянием агента. Слой оркестрации должен обрабатывать его явно: приостановить, запросить продление, перейти в режим с меньшими полномочиями или завершить. Рассмотрение исчерпания как ошибки, подлежащей повтору, — рецепт обхода. Рассмотрение его как состояния, которым нужно управлять, удерживает агента в пределах его полномочий.
Компромисс — накладные расходы. Бюджеты полномочий требуют шлюза, сервиса учётных данных и реестра. Они добавляют задержку к вызовам инструментов и сложность слою оркестрации. Они заставляют команды определять области действия и квоты заранее — работа, которой промпты не требуют. Для прототипа это может быть излишним. Для продакшн-агента с доступом на запись к реальным системам накладные расходы — это цена поверхности управления, которая действительно управляет.
Второй компромисс — гибкость. Жёстко ограниченный грант может блокировать законное действие, необходимое агенту для выполнения задачи. Тогда агент должен запросить продление, что может потребовать одобрения человека. Это замедляет цикл. Альтернатива — широкий грант, разрешающий действие и всё остальное. Проектный выбор — где провести границу между автономией и надзором. Бюджеты полномочий делают этот выбор явным и принудительным, вместо того чтобы оставлять его на интерпретацию промпта моделью.
Заключение
Промпты описывают намерение. Полномочия ограничивают поведение. В цикле модель будет использовать то, что может использовать, а не то, что ей сказали использовать. Недостающая поверхность управления — это бюджет полномочий: расходуемый лимит с областью действия, квотой, сроком действия и аттестацией, видимый планировщику и применяемый на шлюзе. Это переносит безопасность со слоя инструкций на слой учётных данных, где её можно отозвать, проверить и осмыслить. Это менее удобно, чем промпт. Это также разница между надеждой, что агент ведёт себя правильно, и гарантией, что он не может поступить иначе.