Кошельки AI-агентов: объяснение

Кошелёк агента – это не кошелёк, а набор разрешений (permission set): смарт-аккаунт (smart account), который хранит средства, и ограниченное право подписи (scoped signing right), позволяющее агенту действовать в рамках заданных вами ограничений. Важный вопрос заключается не в том, где хранится ключ, а в том, что именно может подписать агент, от чьего имени, до какой суммы и как это право может быть отозвано. Всё остальное вытекает из этого сдвига: когда объектом контроля становится разрешение, а не ключ, работа по проектированию переносится в плоскость определения области действия (scope), лимитов и отзыва.

Кошелёк – это набор разрешений, а не ключ

Передача агенту ключа даёт ему доступ к всему вашему балансу; передача разрешения даёт ему ровно те действия, которые разрешены политикой, и ничего за их пределами.

Смарт-аккаунт (smart account): аккаунт, правила которого написаны кодом, поэтому валидной операцией считается та, которую сам аккаунт принимает; это может означать наличие подписи авторизованного подписанта, вызов конкретного контракта или оба условия сразу. Сессионный ключ (session key): отдельный ключ подписи, авторизованный аккаунтом для ограниченной цели, а не основной ключ самого аккаунта. Область действия (scope): то, что разрешено делать этому ключу, выраженное через разрешённые цели (targets), разрешённые функции и временное окно. Политика (policy): правило, которое аккаунт применяет к предлагаемой операции перед её принятием, например, лимит расходов или белый список (allowlist) получателей.

Практическое следствие состоит в том, что агенту никогда не нужно хранить ничего ценного. Он владеет правом на инструктаж, а то, как это право фактически реализуется на расчётных путях (settlement rails), описано в справочном материале об агентских платежах, тогда как средства остаются под защитой логики валидации самого аккаунта.

• Что получает агент: право подписи с областью действия, сроком жизни и потолком.
• Что агент не получает: возможность перемещать средства за пределами этой области или расширять саму область.
• Что остаётся у оператора: аккаунт, политика, определяющая область действия, и возможность отозвать право.

Сравнение моделей хранения (Custody models)

Модели хранения различаются по одному параметру: кто фактически производит подпись, а значит, какова цена компрометации агента. Это делает хранение (custody) второй половиной того же вопроса: модель определяет, что можно подписать и кто должен это сделать, а не только то, где лежит ключ.

Строка «общий ключ» – это та, которую следует распознать в вашей собственной инфраструктуре, поскольку это результат по умолчанию при передаче агенту приватного ключа и названии этого интеграцией. Последние две строки заменяют единую точку подписи координацией: пороговая схема MPC не устраняет риск, она меняет круг лиц, которым нужно пойти на сговор для совершения неверного платежа, а служба подписания внутри защищённой среды всё равно зависит от настроенной там политики. То, как одна из платформ подходит к вопросу безопасности кошельков в этой картине, изложено в сравнении платформ кошельков.

Сессионные ключи и ограниченная подпись

Сессионный ключ (session key) – это отдельный подписант со сроком истечения и определённой зоной действия, созданный так, чтобы его потеря стоила лишь лимита, а не всего аккаунта.

Этот механизм происходит из абстракции аккаунтов (account abstraction): на модульном смарт-аккаунте сессионный ключ устанавливается как модуль валидатора с прикреплёнными политиками, и каждая предлагаемая операция проверяется на соответствие этим политикам до того, как аккаунт примет её. Политика может ограничивать целевой контракт, вызываемую функцию, общую сумму перемещаемых средств и период, в течение которого ключ действителен; аккаунт отклоняет всё, что выходит за эти рамки. Практические реализации также требуют, чтобы владелец аккаунта подписал создание сессии, поэтому агент не может создать сессию для себя самостоятельно.

Сессионный ключ – это не второй пароль, и разница в этом является причиной его полезности:

• Его нельзя перевыпускать только тогда, когда вы помните об этом: он истекает автоматически, и аккаунт перестаёт его принимать.
• Это не копия основного ключа: его отзыв не требует перевыпуска основного подписанта аккаунта.
• Это не всеобъемлющее одобрение: то, что он может переместить, ограничено политикой, а не балансом.

Там, где агент платит токенами, а не собственной валютой блокчейна, та же логика ограничения проявляется на уровне токенов: разрешение (allowance) для конкретного контракта тратильщика само по себе является потолком, а то, что такое токен и как работают одобрения, описано в справочном материале о токенах.

Лимиты, белые списки и стоп-переключатель

Лимиты и белые списки (allowlists) превращают утечку учётных данных агента из потери всего в инцидент с известным максимумом.

Три элемента управления выполняют основную работу, и их стоит настроить до того, как агент увидит какие-либо средства. Потолок на одну транзакцию ограничивает худший одиночный случай ошибки. Скользящий лимит за период ограничивает цикл, повторяющий небольшой платёж. Белый список получателей делает местом назначения неверного платежа выбранный вами набор адресов, а не адрес, выбранный тем, кто подаёт запрос агенту.

• Пауза (Pause): переключатель, останавливающий новые операции при сохранении балансов и истории, используется при подозрении, а не после потери.
• Отзыв (Revoke): изъятие самой сессии, это единственный элемент управления, работающий после того, как известно о компрометации ключа.
• Эскалация (Escalate): маршрутизация любых операций выше потолка на шаг утверждения человеком вместо их отказа, что сохраняет полезность агента на границах возможностей.

Стоп-переключатель должен быть доступен, когда агент ведёт себя неправильно, что на практике означает, что он принадлежит человеку, а не агенту: отзыв, требующий сотрудничества агента, не является элементом управления. То же самое относится к оповещениям, которые никто не читает, поэтому полезная версия мониторинга – это лимит, который работает в режиме закрытия (fails closed), плюс уведомление об каждом отказе.

Что остаётся у человека

Три вещи остаются у человека в любой работоспособной конструкции: политика, ключ восстановления (recovery key) и запись о том, что сделал агент.

Политика (policy) – это реальная поверхность управления, поскольку сессионный ключ является лишь её экземпляром. Тот, кто может редактировать политику, может расширить область действия агента, поэтому эта способность должна принадлежать тому же лицу, которое может перемещать средства. Ключ восстановления – второй элемент: если основной подписант аккаунта находится у агента или в той же инфраструктуре, на которой работает агент, то после того как агент начнёт вести себя неправильно, не останется ничего, чем можно было бы воспользоваться для отзыва прав. Журнал аудита – третий элемент, и именно он делает инцидент поддающимся рассмотрению: какие операции предлагались, какие были отклонены политикой и какой подписант произвёл каждую принятую подпись.

• Политика: конфигурация, принадлежащая человеку, изменяемая преднамеренно, а не во время выполнения задач агентом.
• Восстановление: подписант, которого агент никогда не видит, хранимый там, где агент не может его прочитать.
• Аудит: журнал только для добавления записей о предложениях и отказах, достаточный для реконструкции инцидента.

Вопрос рабочего процесса вытекает из этого разделения: агент, который может запрашивать более широкий лимит, полезен, тогда как агент, который может предоставлять его себе, является обузой, и разница заключается не в коде агента, а в том, где хранится политика.

Как ломаются кошельки агентов

Кошельки агентов выходят из строя тремя узнаваемыми способами, и каждый из них имеет ранний сигнал, видимый до потери каких-либо денег.

Первый сбой – слишком широкая область действия: агент авторизован для целого контракта, когда нужна была одна функция, или для полного баланса аккаунта, когда нужен был бюджет. Сигналом является разрешение, которое невозможно описать одним предложением, а исправлением – начало работы с наименьшего возможного диапазона, в котором задача может выполняться. Второй – отсутствие отзыва: сессионный ключ без срока истечения или разрешение, остающееся активным после завершения интеграции. Сигналом является разрешение без владельца и без даты окончания, и это самый распространённый случай, потому что в момент создания ничего не ломается.

Третий – утечка сессионного ключа без потолка за ним, где область действия технически верна, но ничто не ограничивало сумму. Сигналом является политика без собственного потолка, а исправлением – потолок на сессию, а не на область действия.

Перед предоставлением доступа убедитесь, что ответ на каждый из этих вопросов является фактом, а не намерением:

• Область действия называет контракты и функции, и у агента нет пути ни к чему другому.
• Ключ истекает без необходимости чьего-либо напоминания об отзыве, и отзыв возможен уже сегодня.
• Потолок достаточно низок, чтобы потеря ключа была переживаемой, а отказы вызывают оповещение.
• Подписант-человек не хранится там, где агент может его прочитать.

Кража учётных данных (credential theft) – это окружающий риск, а не специфичный для агентов, а формы, которые он принимает в среде агента, от враждебных запросов до скомпрометированной зависимости, описаны в обзоре криптоугроз.

Частые вопросы

Нужен ли ИИ-агенту собственный кошелёк?

Отдельный кошелёк существует для того, чтобы ущерб от ошибки агента ограничивался его разрешением, а не балансом, на который он был направлен.

Это не удобство; это контроль, который придаёт смысл остальной части дизайна.

Что такое сессионный ключ?

Сессионный ключ – это отдельное право подписи с ограниченной областью действия и ограниченным сроком жизни, которое аккаунт может отозвать без перевыпуска своего основного подписанта.

Именно поэтому это не второй пароль: он истекает и имеет ограничения по области действия, тогда как пароль не обладает ни тем, ни другим.

Могут ли лимиты расходов действительно сдержать утечку?

Да, если лимиты и белый список получателей установлены до предоставления доступа, потому тогда утекнувший ключ может потратить только то, что разрешено политикой.

Утечка под потолком – это инцидент с известным максимумом, а утечка без него – это весь аккаунт.

Безопаснее ли MPC, чем смарт-аккаунт?

Они решают разные проблемы: пороговая подпись (threshold signing) устраняет единого подписанта, тогда как смарт-аккаунт определяет правила, которым должна удовлетворять операция.

На практике их комбинируют: политика находится на аккаунте, а подпись разделяется между сторонами.

Кто несёт ответственность, когда агент ошибочно платит?

Ответственность начинается с того, кто выдал разрешение, потому что политика и ключ восстановления принадлежат человеку, а не агенту.

Техническая форма этого ответа проста: человек владеет аккаунтом, поэтому человек несёт последствия.