OpenClaw 2.0 та Sigil: Створення перевіряємої авторизації для автономних AI-агентів

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

За офіційними даними, це найбільше оновлення в історії OpenClaw, що включає понад 16 000 Pull Request і стосується майже всієї стек-архітектури продукту: встановлення, повідомлень, пам’яті, Skills, моделей, Automations, браузера, нативних додатків, Plugins та механізмів безпеки.

Але порівняно з цим довгим списком функцій, більш важливим є все чіткіший шлях розвитку OpenClaw 2.0: агенти все більше стають здатними реально «виконувати дії».

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

За останній рік найбільш помітною зміною AI Agent було не те, що базові моделі стали розумнішими.

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

Але саме тут і виникає проблема: у поточних інтерактивних парадигмах часто виникають два крайніх варіанти.

Один із способів — повне делегування повноважень: безпосередньо передати агенту приватний ключ або сеансовий ключ (Session Key), який діє довго і має достатні права, щоб він міг самостійно вирішувати та виконувати дії.

Автоматизований досвід цієї моделі, звичайно, найкращий, але ризики також дуже концентруються: якщо відбувається ін'єкція промптів, зловмисний веб-сайт чи забруднення даних, або ж модель сама втрачає правильне розуміння, помилка може поширюватися по всьому виконавчому ланцюжку і в кінцевому підсумку перетворюватися на реальні дії (додаткове читання: «Sign — це не тільки підпис: коли AI Agent підписує за вас, хто все ще тримає контроль?»).

На відміну від звичайних інтернет-сценаріїв, де це може бути просто відправлена неправильна електронна пошта або видалений непотрібний файл, на ланцюзі помилкова транзакція часто є незворотною.

Інший підхід — повністю відмовитися від делегування, де кожна операція та кожен вкладений виклик вимагають підтвердження через вікно підпису. Безпека зростає, але сенс автоматизації значно зменшується.

Насправді, коли агент допомагає користувачеві виконати складну стратегію DeFi, що включає кілька етапів, і кожен з них вимагає, щоб користувач брав у руки телефон і окремо «схвалював» кожну дію, то користувач фактично перетворюється не на того, хто сам натискає кнопки, а на «людську печатку», яка постійно проставляє схвалення для агента.

Іншими словами, середня свобода дій є джерелом як підвищення ефективності агента, так і нових ризиків.

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

Одна й та ж сама транзакція: 10 доларів і 100 тисяч доларів — це різні речі; взаємодія з протоколом, яким користуються довгий час, і раптове надання дозволу невідомому контракту — це не одне й те саме; виконання Swap, який явно запитав користувач, і те, коли агент самостійно розпоряджається активами, переносячи їх на інший ланцюг, — це різні рівні ризику.

Отже, чим більше автономії має агент, тим більше прав не може бути просто простим перемикачем.

Справжнім потрібним є механізм безпеки, який дозволить йому вільно діяти всередині меж, а при перетині межі автоматично зупинятися.

Насправді, OpenClaw не ігнорував цього питання.

Зараз він надає багатошаровий механізм дозволів, наприклад, плагіни можуть призупиняти виконання конкретних дій і вимагати підтвердження користувача, а при роботі з командами хоста додатково доступні окремі Exec Approvals та Allowlist тощо.

Це вже великий крок вперед порівняно з наданням всіх інструментів і прав Agent одразу. Але коли Agent справді входить у сценарії оплати, торгівлі та управління активами, виникає більш дрібна проблема: дозвіл Agent використовувати певну здатність і надання Agent дозволу на виконання певної конкретної дії — це насправді не одне й те саме.

Як дозвіл агенту використовувати браузер не означає, що йому дозволено купувати що завгодно на будь-якому сайті; дозвіл агенту отримувати доступ до пошти не означає, що він може від імені вас надсилати листи будь-кому; аналогічно, дозвіл агенту викликати гаманець ніколи не повинен означати, що він може надсилати довільні суми на довільні адреси.

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

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

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

Одним із найважливіших принципів є «Що бачиш, те й підписуєш»: бачиш щось — підписуй це.

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

Ще важливіше, це підтвердження не повинно бути просто невизначеним «Агент готовий виконати угоду, чи згодні?». Користувачі справді хочуть бачити ключові параметри, що змінюються в цій операції: які активи використовуються, яка сума, хто є партнером у взаємодії та що саме буде виконано в кінці.

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

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

Це означає, що авторизація — це не просто «хтось натиснув підтвердження», а може додатково відповідати на питання: хто схвалив, що було схвалено, і чи було справді виконано те, що було побачено на той момент.

З цієї точки зору Sigil справді прагне вирішити не «як змусити агента робити менше».

Навпаки.

Він намагається вирішити, як дозволити агенту безпечно робити більше дій, не віддаючи під контроль користувача остаточне право вирішення (додаткове читання: «Від сліпої натиснення «Так» до розуміння перед підписанням: як Sigil додає безпечний бар’єр для AI Agent?»).

Якщо ще трохи відійти назад, то стане зрозуміло, що це також зміна ролі гаманця, з якою він зараз стикається.

З моменту появи Ethereum гаманець imToken став свідком двох ключових епох: від ери 1.0, коли керувалися однією приватною ключем, до ери 2.0, де інтерактивний досвід оптимізовано за допомогою абстракції облікового запису (AA).

З поширенням автономних агентів, таких як OpenClaw 2.0, гаманці, безумовно, переходять до третьої фази розвитку і потребують подальшої допомоги користувачам у керуванні автономними агентами, які здатні приймати рішення та працювати безперервно.

Саме тому навички, накопичені в індустрії гаманців у сфері керування приватними ключами, цифровими підписами, аутентифікацією особистості та ізоляцією прав, можуть отримати нове значення в епоху агентів.

Оскільки ці технології на перший погляд вирішують питання «як безпечно підписати он-чейн транзакцію», насправді вони працюють з більш загальною проблемою: як довести, що дія справді отримала справжню авторизацію від певного суб’єкта.

Сьогодні ця дія може полягати у виведенні 1 ETH. У майбутньому це може бути відправлення листа, зміна файлу, використання певної цифрової особистості, придбання послуги або дозвіл Agent на постійне виконання певної автоматизованої стратегії протягом наступного тижня.

Ці дії не обов’язково відбуваються на блокчейні, але базова сутність дуже схожа: агент викликає здатність, що належить користувачу, від імені користувача.

Тому значення Sigil не обов’язково обмежується лише Crypto.

Коли OpenClaw, Hermes та інші агенти, що працюють на персональних пристроях або в хмарному середовищі, поступово під’єднуються до електронної пошти, миттєвих повідомлень, календарів, файлів, браузерів, терміналів та платіжних інструментів, питання «як довести, що ця дія справді була авторизована користувачем» стане все більш поширеним.

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

Загалом, як спільне дослідження imToken та OpenClaw, Sigil намагається перенести досвід imToken за останні десять років у галузі самокерованих гаманців та цифрових підписів у новий етап, коли автономні агенти починають працювати в реальних умовах.

Він не замінює агента і не витісняє гаманець.

Воно стоїть між ними.