Допущение об ответственности
Правовые и регуляторные режимы для автономных систем опираются на простую предпосылку: когда возникает вред, кто-то выбрал это действие. Ответственность возлагается путём прослеживания этого выбора до принципала, который его авторизовал, деплоера, который его настроил, или разработчика, который его создал. Эта предпосылка справедлива для традиционного программного обеспечения, потому что действия детерминированы, а логи записываются кодом, который их выполняет. Для LLM-агентов она не выполняется.
Агентные системы записывают то, что модель выдала, а не почему. Траектория вызовов инструментов и наблюдений не является журналом решений, если каждое действие не привязано к объявленной полномочии. Без этой привязки нет атрибуции, и ответственность по умолчанию ложится на деплоера, независимо от того, где возник сбой. Недавние публикации об ответственности агентов в корпоративных развёртываниях иллюстрируют болевые точки [1], а параллельные обсуждения подотчётности автономных систем подчёркивают разрыв между правовыми ожиданиями и технической реальностью [2].
Результат — несоответствие: суды и регуляторы требуют цепочки хранения решений; агентные фреймворки порождают поток токенов и вызовов API, который невозможно воспроизвести до единственного ответственного шага.
Что требуется для атрибутируемой записи
Атрибутируемая запись — это не стенограмма. Это набор подписанных, добавляемых только в конец записей, где каждое действие несёт полномочие, в рамках которого оно было совершено: какой принципал, какая область действия, какая версия политики. Промпты и веса модели не являются доказательствами. Это входные данные для стохастического процесса. Подписанная запись действия является доказательством, потому что она связывает действие с предоставлением полномочий, которое можно проверить независимо от модели, породившей его.
Рассмотрим конкретный механизм. Прежде чем агент вызовет инструмент, среда выполнения создаёт запись действия со следующими полями:
{
"action_id": "act_01H...",
"principal": "user:[email protected]",
"delegation_chain": ["grant_01", "grant_02"],
"scope": "payments:read",
"policy_version": "policy_2025_04_01",
"tool": "ledger.read",
"args_hash": "sha256:...",
"timestamp": "2025-04-01T12:00:00Z",
"signature": "ed25519:..."
}
Среда выполнения подписывает запись ключом, контролируемым хостом агента. Запись добавляется в журнал, защищённый от подделки, например, в хеш-цепочку, где каждая запись включает дайджест предыдущей записи. Проверка не требует модели. Она требует открытого ключа и журнала.
Это проектное решение с компромиссами. Подпись каждого действия добавляет задержку и накладные расходы на управление ключами. Оно также заставляет среду выполнения знать принципала и область действия в момент действия, что не всегда тривиально в мультиагентных системах, где контекст разделяется. Альтернатива — логирование постфактум — порождает записи, которые не выдержат состязательной проверки, потому что их может изменить тот же процесс, который их создал.
Цепочка от принципала к действию
В мультиагентных системах делегирование часто неявно. Родительский агент порождает субагента, передаёт контекстное окно, и субагент вызывает инструменты, используя учётные данные, унаследованные от родителя. Нет записи о передаче. Нет ссылки на полномочие родителя. Субагент действует на основании полномочий родителя, не объявляя об этом.
Это основной режим отказа для ответственности. Когда субагент совершает вредоносное действие, запись показывает вызов инструмента из процесса, а не делегирование от принципала. Полномочия родителя невидимы. Реконструкция останавливается на субагенте, и ответственность по умолчанию ложится на деплоера, потому что никакой другой принципал не может быть идентифицирован.
Решение — явные записи о передаче. Субагент, действующий на основании полномочий родителя, должен ссылаться на полномочие родителя, а не наследовать учётные данные молча. Запись о передаче должна включать ID действия родителя, де
{
"handoff_id": "hand_01H...",
"parent_action": "act_01H...",
"child_agent": "agent:research-01",
"delegated_scope": "search:read",
"attenuated_from": "search:read,search:write",
"policy_version": "policy_2025_04_01",
"signature": "ed25519:..."
}
Отзыв должен распространяться по цепочке и записываться как событие. Если принципал отзывает полномочие, каждое последующее действие после этого отзыва должно быть недействительным. Журнал должен содержать событие отзыва с ID полномочия и временной меткой. Без этого отозванный агент может продолжать действовать, и запись будет показывать действия, которые выглядят авторизованными, но таковыми не являются.
Компромисс — сложность. Явные цепочки делегирования требуют от среды выполнения отслеживания полномочий между агентами, обеспечения ослабления и распространения отзывов. Общие контекстные окна проще, но порождают записи, которые не могут ответить на вопрос, который задаст суд: под чьими полномочиями произошло это действие?
Проектирование для зала суда
Журнал действий должен рассматриваться как первоклассный артефакт, версионируемый вместе с определением агента. Когда политика или набор инструментов агента меняются, журнал должен фиксировать версию, действовавшую на момент каждого действия. Это позволяет восстановить события без исходной модели. Запись должна быть самодостаточной: верификатор с журналом, открытыми ключами и версиями политик должен иметь возможность определить, что произошло и под чьими полномочиями, даже если модель устарела или недоступна.
Политика хранения — это юридический вход, а не инфраструктурное значение по умолчанию. Срок хранения должен устанавливаться юридическими и комплаенс-требованиями, применимыми к домену агента, а не стоимостью хранения. Для агентов в регулируемых секторах срок хранения может измеряться годами. Формат журнала должен поддерживать экспорт в форматы, которые могут проверять юридические команды, а хеш-цепочка должна проверяться независимо.
Восстановление без исходной модели — жёсткое требование. Если запись зависит от воспроизведения модели для интерпретации действия, это не запись. Это симуляция. Симуляции не являются доказательствами. Запись должна содержать достаточно информации, чтобы ответить: какой принципал авторизовал это действие, в рамках какой области действия, по какой версии политики, и были ли эти полномочия действительны на тот момент.
У этого подхода есть издержки. Он требует инвестиций в инструментирование среды выполнения, управление ключами и хранение журналов. Он замедляет выполнение действий. Он заставляет команды определять области действия и политики до развёртывания, а не после. Но альтернатива — режим ответственности, который не может функционировать, потому что бумажного следа не существует. Вопрос не в том, создавать ли атрибутируемые записи. Вопрос в том, кто проверяет проверяющего, когда запись отсутствует.