Чому AI-токени створюють новий клас ризиків для смартконтрактів

AI-токени створюють новий клас ризиків тому, що частину рішень у продукті приймає модель, а не код. Зловмисник може вплинути на дані, які модель читає, - метадані пропозиції, відповідь оракула - і через них змінити поведінку смартконтракту. Це prompt injection, і аудит Solidity-коду його не бачить: перевіряти треба ще й AI-логіку та бізнес-процеси.

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

Ще кілька років тому «AI у блокчейні» здебільшого означало маркетинговий тег у назві токена. Сьогодні картина інша:

• AI-агенти керують гаманцями й виконують транзакції без участі людини;
• моделі попередньо аналізують governance-пропозиції;
• скорингові модулі оцінюють ризик операції до її підтвердження;
• частина бізнес-логіки фактично живе в промптах, а не в Solidity.

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

Чому AI-токени створюють інші виклики безпеки, ніж традиційні токени

Класичний ERC-20 нудний - і це його головна чеснота. Кілька функцій (transfer, approve, mint, burn), передбачувані переходи станів, чітко окреслений периметр.

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

З AI-продуктами інакше. Токен дедалі частіше є не самостійною сутністю, а частиною системи, де AI бере участь у прийнятті рішень: аналізує governance-пропозиції, оцінює ризики транзакцій, класифікує учасників. Він перестає бути «фічею збоку» і стає компонентом, від якого залежить поведінка контракту.

Кожен новий компонент - це нова точка входу

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

Раніше зловмиснику треба було знайти вразливість у самому коді. Тепер з’являється ще один шлях: вплинути на дані, які «з’їдає» AI, і так опосередковано змінити поведінку смартконтракту.

Уявіть AI-модуль у DAO-протоколі, який присвоює пропозиціям пріоритет для голосування. Смартконтракт може бути бездоганним і пройти Solidity-аудит без зауважень. А потім хтось складе опис пропозиції так, щоб модель оцінила її інакше, - і система відпрацює рівно так, як її попросили.

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

Чому традиційного захисту смартконтрактів уже недостатньо

Більшість команд сприймають аудит як перевірку коду на типові помилки:

• reentrancy;
• помилки в правах доступу та ролях;
• некоректна робота з approve та allowance;
• проблеми проксі й upgradeable-патернів;
• арифметичні переповнення - сьогодні переважно в unchecked-блоках, асемблері або на старих версіях компілятора, адже з Solidity 0.8 переповнення за замовчуванням призводить до revert.

Робота потрібна й важлива. Але перевіряє вона лише один шар системи.

Ризики живуть на стиках

В AI-продуктах найуразливішими стають не самі смартконтракти, а зони стику між елементами системи:

• зв’язка між смартконтрактом і зовнішнім AI-сервісом;
• процес інтерпретації метаданих пропозиції AI-моделлю;
• ланцюжок між зовнішнім оракулом і підсумковою бізнес-логікою.

Це проблема скоупу, а не кваліфікації

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

AI-модуль, його системний промпт, правила валідації відповіді моделі та інтеграційний шар формально «не є контрактом» - тож у скоуп вони не потрапляють.

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

Чому автотести цього не ловлять

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

Показовий приклад - оракули. У класичному DeFi-продукті оракул просто передає ціну активу, і аудитор перевіряє, чи коректно контракт обробляє це значення та чи є захист від маніпуляції ціною.

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

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

Як це виглядає на практиці: реальний AI/Web3-аудит

Найкраще цю різницю - між «перевірили код» і «перевірили систему» - видно не в теорії, а на конкретному прикладі. Показовим є White-box аудит смартконтрактів Web3-компанії з інтегрованим AI, який команда Datami провела перед запуском AI-токена.

Клієнт - міжнародна Web3-компанія, яка розробила власний смартконтракт із підтримкою AI на базі стандарту ERC-20. Продукт працював із конфіденційними платіжними даними та мав взаємодіяти з біржами, тож ціна помилки була високою: від втрати активів до повної зупинки бізнесу.

Як проходив аудит:

• Підхід: White-box, з повним доступом до вихідного коду двох контрактів.
• Крок 1 - ручний аналіз: перевірка логіки кількома аудиторами незалежно один від одного.
• Крок 2 - автоматичне сканування: статичні аналізатори (зокрема Slither і Mythril) та побудова графів викликів.
• Крок 3 - фаззинг: кастомні тести на Echidna під нетипові сценарії.
• Крок 4 - звітність: два проміжні звіти та фінальний документ з рекомендаціями.
• Тривалість: один місяць.

У двох контрактах виявили 40 вразливостей:

• 2 критичні;
• 5 середнього рівня;
• 8 низького рівня;
• 25 інформаційних.

Показовий і сам діапазон знахідок: від reentrancy та можливості впливу на AI через метадані - до надто детальних повідомлень про помилки і застарілих версій бібліотек.

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

Найпоказовішою знахідкою стала не reentrancy

Reentrancy - вразливість із підручника. Її під час аудиту теж знайшли.

Але для теми AI/Web3-безпеки показовою виявилася зовсім інша знахідка: можливість AI query injection через метадані пропозиції. За формальним рівнем ризику вона була не найвищою у звіті. Її цінність в іншому: вона демонструє цілий клас проблем, якого ще кілька років тому в аудитах смартконтрактів просто не існувало.

Що таке метадані пропозиції

У продуктах із governance-логікою учасники створюють пропозиції - наприклад, на зміну параметрів контракту чи розподіл коштів. Кожна така пропозиція супроводжується метаданими: текстовим описом, додатковими полями, контекстом.

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

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

У світі AI-безпеки цей клас атак відомий як indirect prompt injection: шкідлива інструкція потрапляє в модель не від користувача напряму, а разом із даними, які модель зобов’язана прочитати. В OWASP Top 10 для LLM-застосунків (редакція 2025 року) prompt injection стоїть під номером LLM01 - на першому місці списку.

Чим це відрізняється від класичних вразливостей

Тенденція вже перестала бути гіпотетичною. У серпні 2025 року з’явився ERC-8004 (Trustless Agents) - стандарт ончейн-ідентичності та репутації для AI-агентів, серед авторів якого інженери MetaMask, Ethereum Foundation, Google і Coinbase.

На початку 2026-го з’явилися референсні деплої в мейннеті, і вже до середини лютого в реєстрі були тисячі агентів. Паралельно розвивається x402 - протокол платежів між машинами, а в червні 2026-го MetaMask відкрив ранній доступ до Agent Wallet, який дозволяє агенту самостійно виконувати свопи й торгові операції.

Публічних інцидентів саме з prompt injection у смартконтрактах поки небагато - але це радше ознака того, наскільки молода ця поверхня атаки, ніж доказ її безпечності.

Що з цим робити на рівні архітектури

Захист від цього класу атак будується здебільшого не в моделі, а навколо неї.

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

Ліміти живуть у контракті, а не в промпті. Показовий приклад - MetaMask Agent Wallet: користувач заздалегідь задає ліміти витрат і список дозволених протоколів, і агент діє лише в цих межах, незалежно від того, до якого висновку дійшла модель. Інструкцію в промпті можна переписати ззовні, allowance у смартконтракті - ні.

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

Вихід моделі структурований і звужений. Замість вільного тексту - enum, оцінка в заданому діапазоні, фіксована схема. Усе, що в схему не вкладається, відхиляється.

Fail-closed за замовчуванням. Якщо модель повернула сміття, порожню або суперечливу відповідь, система зупиняється, а не підставляє значення за замовчуванням.

Людина або мультипідпис на останньому кроці - для дій, які неможливо відкотити.

Чому сучасний аудит має виходити за межі коду

Універсального інструмента тут немає. Є набір, у якому кожен метод бачить те, чого не бачать інші.

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

Ручний аналіз незамінний там, де йдеться про логічні помилки. Автоматичні інструменти добре знаходять типові патерни вразливостей, але погано розпізнають проблеми бізнес-логіки, специфічні для конкретного продукту.

Статичний аналіз (інструменти на кшталт Slither) швидко покриває великий обсяг коду і виявляє типові класи вразливостей. Це базовий, але необхідний рівень перевірки.

Fuzz-тестування та перевірка інваріантів - Echidna, Medusa, інваріантні тести у Foundry, а для критичних місць і символьне виконання. Саме тут виявляються сценарії, де AI-компонент поводиться не так, як очікувалося.

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

Жоден із цих методів окремо не охоплює весь спектр ризиків. Але їхня комбінація дозволяє побачити картину цілком: і помилки в коді, і проблеми на стику AI та контракту.

Чекліст безпеки перед запуском AI-токена

Сім питань, на які варто мати відповідь до лістингу, а не після нього.

Чи перевірена бізнес-логіка взаємодії AI та смартконтракту? Недостатньо переконатися, що AI-модуль і контракт працюють кожен окремо. Важливо, як саме вони обмінюються даними та чи є точки, де ці дані можна підмінити.

Чи протестовані нестандартні сценарії? Типові тест-кейси покривають очікувану поведінку. Реальні атаки часто починаються там, де хтось зробив щось, чого розробники не передбачали.

Чи проаналізовані метадані та всі зовнішні джерела даних? Будь-які дані ззовні - від оракулів, користувацьких пропозицій, зовнішніх AI-сервісів - варто вважати недовіреними, поки не доведено протилежне.

Чи перевірялися edge cases? Особливо на стику компонентів: що станеться, якщо AI поверне неочікуваний результат, порожні дані чи суперечливу відповідь.

Чи входив AI-компонент у скоуп аудиту? Промпти, правила валідації відповідей та інтеграційний шар - це частина продукту, навіть якщо вони не написані на Solidity. Якщо в договорі про них не йшлося, вважайте, що їх ніхто не перевіряв.

Чи проводився аудит після останніх змін у коді? Навіть невелика зміна логіки після завершення основного аудиту може створити нову вразливість.

Чи готовий продукт до лістингу з погляду безпеки? Це питання варто ставити не наприкінці розробки, а задовго до дедлайну запуску.

Цей список не замінює повноцінний аудит, але дає орієнтир: на що звертати увагу, готуючи AI-токен до виходу на ринок.

Висновок

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

Виправляти помилки після розгортання у Web3 надзвичайно дорого: для непоновлюваних контрактів шлях назад закритий, а для upgradeable-систем оновлення завжди пов’язані з високим ризиком.

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

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