Разрешено — не значит задумано
Механизм политик отвечает на узкий вопрос: разрешён ли этот вызов инструмента? Список разрешений перечисляет доступные инструменты, области и конечные точки. Он ничего не говорит о том, служил ли конкретный вызов на конкретном шаге той задаче, которую пользователь действительно авторизовал. Агент может иметь действующие учётные данные для платёжного API, файловой системы, почтового шлюза и интерпретатора кода, и каждый отдельный вызов может проходить политику, в то время как последовательность в целом делает то, о чём пользователь не просил. Доступность — свойство конфигурации. Оправданность — свойство запуска.
Это различие важно, потому что режимы отказа, которые беспокоят операторов, редко бывают единичными запрещёнными вызовами. Это композиции: чтение, которое втягивает документ в контекст, шаг суммирования, который тихо отбрасывает ограничение, запись, которая распространяет усечённую версию. Каждый шаг разрешён. Вопрос, на который проверяющему нужен ответ, — был ли шаг задуман: следовал ли он из задачи, наблюдения и политики, действовавшей в тот момент.
Что должна содержать запись намерения
Запись намерения — это структурированное событие, испускаемое один раз на каждый выполненный шаг. Это не строка лога, написанная для людей и разбираемая регулярным выражением позже; это схема с контрактом. Минимально жизнеспособные поля:
- Идентификатор задачи. Стабильный дескриптор авторизованной пользователем цели, созданный до первого шага и переносимый через все последующие.
- Индекс шага. Монотонный в пределах запуска, чтобы пропуски были видны.
- Вызванный инструмент. Конкретная возможность, а не обобщённая метка.
- Аргументы в том виде, в каком они поданы. Полезная нагрузка до нормализации, потому что нормализация — это место, где теряется намерение.
- Допустившее правило политики. Какое правило разрешило вызов и под какой версией набора политик.
- Дайджест наблюдения. Хеш наблюдения, вызвавшего шаг, чтобы запись нельзя было тихо переписать под более позднюю версию событий.
- Причина завершения. Почему запуск закончился — завершён, бюджет исчерпан, политика отказала, ошибка, тайм-аут — включая успешные запуски.
Поле завершения опускают чаще всего, и именно оно делает остальное проверяемым. Если ожидается, что каждый запуск закрывается терминальной записью, то отсутствие таковой само по себе является сигналом: упавший исполнитель, убитый контейнер, процесс, который так и не отчитался. Без него отсутствующие записи неотличимы от запусков, которых не было.
Конкретный механизм: исполнитель вычисляет observation_digest = H(canonical_json(observation)) непосредственно перед отправкой и сохраняет дайджест вместе с сырым наблюдением, только если политика хранения это позволяет. Дайджест дёшев, на практике неизменяем и достаточен, чтобы доказать, что наблюдение, представленное модели на шаге N, было тем, о котором заявляет запись. Если более позднему расследованию нужно полное наблюдение, его можно восстановить из хранилища контента по дайджесту, с соблюдением тех же правил хранения, что и для любого другого пользовательского контента.
Испускает исполнитель, а не модель
Если записи намерений создаются моделью — суммирующим вызовом в конце запуска или самоотчётом об обосновании — они становятся ещё одним, что модель может narrate, и, следовательно, ещё одной поверхностью, на которую может повлиять противник. Запись должен испускать компонент, который фактически отправляет вызов инструмента, после допуска политикой и перед выполнением, с прикреплённым решением механизма политик. Модель может предлагать; исполнитель удостоверяет. Это разница между показаниями свидете
Захват записи намерения недорог. Хранение содержимого внутри неё — нет. Запись, содержащая только ID задачи, индекс шага, имя инструмента, правило политики и дайджесты, мала, низкочувствительна и может храниться долго. Запись, включающая сырые аргументы и наблюдения, наследует чувствительность того, над чем работал пользователь. Честный компромисс таков: агрессивное хранение даёт ответственным за инциденты нужный материал и одновременно создаёт хранилище пользовательского контента с собственными обязательствами по контролю доступа, удалению и утечкам. Практическое разделение — хранить структурные записи долгосрочно, а контент — по дайджесту, с отдельным, более коротким окном хранения для хранилища контента. Это решение принадлежит владельцу управления данными, а не команде платформы агентов, и его следует задокументировать как политику, а не оставлять по умолчанию.
Одна схема, три потребителя
Одна и та же запись должна обслуживать оценщиков, ответственных за инциденты и учёт затрат без второго конвейера. Это полезно ограничивает схему. Оценщикам нужна последовательность шагов и допустившее правило, чтобы оценить, была ли траектория оправдана. Ответственным за инциденты нужен дайджест наблюдения и версия политики, чтобы восстановить, что видел агент и какие правила действовали. Учёту затрат нужны идентичность инструмента, размер аргументов и причина завершения, чтобы отнести расходы на задачу. Схема, несущая ID задачи, индекс шага, инструмент, дайджест и размер аргументов, правило и версию политики, дайджест наблюдения и причину завершения, обслуживает всех трёх. Схема, спроектированная только для одного потребителя, будет выведена заново из сырых логов двумя другими — так организации приходят к трём несовместимым версиям одного и того же события.
Подпись и упорядочение
Записи следует связывать в цепочку: каждая запись включает дайджест предшественника, а запуск завершается подписанным корнем. Это делает тихое удаление обнаружимым и даёт ответственным проверяемую последовательность. Цена — операционная: управление ключами, ротация и шаг верификации в пути аудита. Эта цена реальна, и именно поэтому многие команды начинают с неподписанных записей и монотонного индекса шага, а затем добавляют подпись, когда схема стабилизируется. Начинать без подписи допустимо; начинать без индекса шага — нет, потому что упорядочение — это свойство, делающее возможным любое последующее добавление.
Артефакт, закрывающий разрыв
Политика определяет пространство разрешённых действий. Запись намерения показывает, какие из этих действий были предприняты, в каком порядке, по какому правилу, вслед за каким наблюдением и почему запуск остановился. Первое — конфигурация; второе — доказательство. Командам, выпускающим агентов в среды с реальными последствиями, понадобится и то, и другое, причём второе должно создаваться средой выполнения в момент решения — а не восстанавливаться afterwards из транскрипта, который больше не содержит контекста, имевшего значение.