The Register AI 31 серпня 2026 року опублікувала розбір релізу OpenClaw 2.0 — оновлення відкритого фреймворка для побудови автономних AI-агентів, яке анонсували як крок до безпечнішої архітектури. Висновок видання не втішний: ключові вразливості агентної інфраструктури, відомі ще з попередньої версії, у релізі 2.0 залишились практично без змін.

OpenClaw належить до категорії фреймворків, на яких команди будують агентів із доступом до реальних інструментів — терміналів, API, баз даних, файлової системи. Саме тому питання «що саме змінилось під капотом, а що лише в інтерфейсі» тут не риторичне: від відповіді залежить, чи можна довіряти агенту доступ до продакшн-систем.

Наш погляд у AiiN простий: якщо ви вже будуєте агентів на OpenClaw, вихід версії 2.0 — не привід послаблювати контроль доступу. Косметичний реліз не змінює модель загроз, а отже й ваш підхід до прав агента міняти зарано.

Що конкретно показав розбір The Register?

За даними The Register AI, реліз OpenClaw 2.0 змінив переважно поверхневі елементи — інтерфейс, документацію, частину налаштувань за замовчуванням, — тоді як механізми, що відповідають за розмежування прав агента й ізоляцію виконання команд, залишились тими самими, що й у попередній гілці 1.x. Видання прямо називає це «косметичним» апгрейдом: команда розробників, за оцінкою The Register AI, обрала шлях видимих покращень замість повільнішого й дорожчого перепроєктування ядра безпеки.

Для практика це означає одне: назва мажорної версії тут не сигналізує про новий рівень довіри до системи. Номер релізу — маркетинговий, а не security-артефакт.

Чому «косметичний» патч не закриває структурні ризики агентів?

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

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

Перепроєктування будь-якого з цих пунктів зазвичай ламає зворотну сумісність і сповільнює вихід нових фіч — тому команди-розробники фреймворків часто відкладають цю роботу, обмежуючись видимими покращеннями. Ймовірно, саме цей компроміс і описує The Register AI у випадку OpenClaw 2.0, хоча видання не розкриває внутрішню мотивацію команди розробників.

Кому це загрожує найбільше просто зараз?

Найбільший ризик — у командах, які підключають агентів OpenClaw до продакшн-оточень із реальними credentials: платіжними API, CRM, репозиторіями коду. У vibecoding-темпі, коли агента налаштовують за годину і одразу дають йому доступ до бойових ключів, різниця між «косметичним» і «структурним» патчем безпеки непомітна — доки не станеться інцидент. Про подібну динаміку прискорення атак на AI-інфраструктуру ми вже писали в матеріалі про те, як OpenAI попереджає про складні AI-атаки, що прийдуть за кілька місяців — модель загроз для агентних систем змінюється швидше, ніж встигають закриватись базові діри.

Що робити командам, які вже будують на OpenClaw?

Теза AiiN тут пряма: ставтесь до кожної версії OpenClaw як до потенційно небезпечної за замовчуванням, доки не перевірите зміни самі. Практично це означає:

• надавати агенту мінімум прав, необхідних для конкретної задачі, а не весь набір інструментів «про запас»;
• тримати секрети й API-ключі поза середовищем виконання агента — у vault з обмеженим TTL, а не в змінних оточення процесу;
• вести окремий, незалежний від агента, аудит-лог кожного виклику інструменту з реальними наслідками (запис у БД, виклик платіжного API, git push);
• не покладатися на номер версії фреймворка як на індикатор security-зрілості — перевіряти конкретні зміни в release notes і, за можливості, в коді.

Оновлення інфраструктури — це нагода переглянути права доступу, а не привід їх розширити. Саме це, за нашою оцінкою, і є головний практичний висновок з розбору The Register AI: проблема OpenClaw 2.0 не в тому, що реліз щось зламав, а в тому, що він не змусив індустрію нарешті вирішити відомі структурні питання.

OpenClaw 2.0 небезпечний для продакшну?

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

Чим OpenClaw 2.0 відрізняється від 1.x у плані безпеки?

За розбором The Register AI, різниця здебільшого поверхнева — інтерфейс, документація, окремі дефолтні налаштування. Механізми розмежування прав і ізоляції виконання команд лишились з попередньої версії практично без змін.