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