OpenClaw 2.0 и Sigil: Создание проверяемой авторизации для автономных ИИ-агентов

После периода бездействия «рак» OpenClaw выпустил версию 2.0 30 августа.

Согласно официальной информации, это крупнейшее обновление в истории OpenClaw, включающее более 16 000 запросов на слияние и затрагивающее всю продуктовую стеку — от установки, сообщений и памяти до Skills, моделей, автоматизаций, браузера, нативных приложений, плагинов и механизмов безопасности.

Но более важным, чем этот обширный список функций, является все более четко прослеживающаяся эволюционная траектория OpenClaw 2.0: агенты становятся все более способными реально «выполнять действия».

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

За последний год самым заметным изменением в AI Agent стало не только то, что базовые модели стали умнее.

По мере того как инфраструктура, включающая MCP, Skills, Plugins, управление браузером и выполнение кода, становится все более зрелой, агенты начинают обладать все большим количеством настоящих «рук» и «ног», способных влиять на внешний мир — например, изменять информацию, нажимать кнопки или напрямую управлять браузером через computer use (дополнительное чтение: Agentic AI 拐点已至？当 AI 学会「自己行动」，如何重构 Web3 的安全边界？).

Но проблема как раз и заключается здесь: в существующих интерактивных парадигмах часто возникают два крайних случая.

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

Автоматизированный опыт с таким подходом, безусловно, идеален, но риски также крайне сосредоточены: если произойдет инъекция промпта, вредоносная веб-страница или загрязнение данных, либо модель ошибочно интерпретирует информацию, ошибка может распространиться по всей цепочке выполнения и в конечном итоге превратиться в реальную операцию (дополнительное чтение: Sign — это не только подпись: когда AI Agent подписывает за вас, кто все еще контролирует процесс?).

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

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

В конце концов, когда агент помогает пользователю реализовать сложную DeFi-стратегию, включающую несколько шагов, и для каждого из них пользователю нужно брать телефон и вручную нажимать «Approve», пользователь фактически превращается не из человека, который сам нажимает кнопки, а в «человеческую печать», постоянно проставляющую одобрения для агента.

Другими словами, средняя степень свободы является как источником повышения эффективности агента, так и источником новых рисков.

С этой точки зрения, суть проблемы заключается не в «предоставлять ли полномочия агенту», а в том, насколько динамически гибкими являются уровень авторизации и механизм проверки, поскольку традиционное управление правами является бинарным (либо разрешено, либо запрещено), а задачи, с которыми сталкивается агент, значительно сложнее.

Одна и та же транзакция: 10 долларов и 100 000 долларов — это разные риски; взаимодействие с протоколом в долгосрочной перспективе и внезапная авторизация незнакомого смарт-контракта — это разные риски; выполнение Swap по явному запросу пользователя и решение агента перевести активы на другую цепочку — это разные уровни риска.

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

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

На самом деле, OpenClaw не игнорировал эту проблему.

Сейчас он предоставляет многоуровневую систему разрешений, например, плагины могут приостанавливать выполнение конкретных операций и запрашивать подтверждение от пользователя; при работе с командами хоста дополнительно используются отдельные параметры Exec Approvals и Allowlist и т.д.

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

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

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

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

Это также причина, по которой imToken исследует Sigil. Его суть не в добавлении традиционного «всплывающего окна подтверждения» для агента, а в попытке создать между пользователем и агентом четко ограниченную безопасную защиту с помощью проверяемых подписей и детализированного управления правами.

Одним из важнейших принципов является «What you see is what you sign» — что видите, то и подписываете.

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

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

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

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

Это означает, что авторизация — это не просто «кто-то нажал подтверждение», а возможность дополнительно ответить, кто утвердил, что было утверждено, и действительно ли то, что было выполнено в конце, совпадает с тем, что было видно в тот момент.

С этой точки зрения, то, что Sigil действительно хочет решить, — это не «как заставить агентов делать меньше».

Наоборот.

Он стремится решить, как позволить агенту делать больше действий, не лишая пользователя окончательного контроля (дополнительное чтение: От слепого нажатия «Yes» до осознанной подписи: как Sigil добавляет безопасный барьер для AI-агента?).

Если немного отойти и посмотреть шире, станет ясно, что это также изменение роли кошелька.

С момента появления Ethereum кошелек imToken лично пережил и стал свидетелем двух ключевых эпох: от эпохи 1.0, связанной с управлением единственным приватным ключом, до эпохи 2.0, в которой взаимодействие оптимизировано за счет абстракции аккаунтов (AA).

С распространением автономных агентов, таких как OpenClaw 2.0, кошельки несомненно переходят к третьему поколению и требуют дальнейшей помощи пользователям в управлении агентами, способными самостоятельно принимать решения и работать непрерывно.

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

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

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

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

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

По мере того как OpenClaw, Hermes и другие агенты, работающие на персональных устройствах или в облачной среде, постепенно подключаются к электронной почте, мгновенным сообщениям, календарям, файлам, браузерам, терминалам и платежным инструментам, вопрос «как доказать, что это действие действительно было авторизовано пользователем» станет все более распространенным.

Таким образом, в будущем Sigil может расшириться от цепочных транзакций до доступа к данным, использования идентичности, изменения файлов, публикации контента, покупки услуг и автоматизации задач.

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

Он не заменяет агента и не заменяет кошелек.

Оно стоит между ними.