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

Чому AI-агентам потрібна ідентифікація

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

У традиційній архітектурі ідентифікація тримається на API-ключах, OAuth-токенах або сертифікатах. Для автономних агентів цього недостатньо з кількох причин:

  • Довічність сесій. Агент може працювати тижнями без участі людини. Короткострокові токени доступу створюють переривання, а довгострокові ключі — вектор компрометації.
  • Множинність ролей. Один агент може взаємодіяти з десятками сервісів, кожен із яких вимагає власної моделі довіри.
  • Відсутність юридичної особи. Агент не є суб'єктом права, тому класичні KYC-процедури до нього непридатні без посередника — оператора або провайдера.
  • Машинна масштабність. Тисячі агентів одного провайдера потребують ієрархічної ідентифікації, а не індивідуального онбордингу для кожного екземпляра.

На Solana ідентифікація агентів природно лягає на криптографічну інфраструктуру: ключові пари, PDA (Program Derived Address) та налаштовувані акаунти. Це дає можливість створити ідентичність, яка не залежить від одного централізованого провайдера і яку можна перевірити на рівні консенсусу.

Моделі identity для автономних агентів

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

DID (Decentralized Identifier)

Decentralized Identifier — це стандарт W3C, який прив'язує унікальний ідентифікатор до суб'єкта через криптографічні ключі, без залежності від центрального реєстру. На Solana DID може бути реалізований як PDA, похідний від програми-реєстру, що зберігає документ ідентичності (DID Document) з публічними ключами, сервісними endpointами та метаданими.

Перевага моделі: агент володіє своїм ідентифікатором і може довести контроль над ним підписом. Це дозволяє мігрувати між провайдерами без зміни identity. Обмеження: DID сам по собі не каже нічого про репутацію чи правовий статус агента — це лише криптографічний контейнер.

Reputation-системи на блокчейні

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

Ключове архітектурне рішення — хто має право писати в репутаційний реєстр. Якщо це робить лише один сервіс, система вироджується у закритий рейтинг. Якщо будь-хто — виникає проблема сибілових атак (створення фіктивних агентів для штучного накачування репутації). Практичні рішення включають стейкінг токенів як анти-сибільний механізм або whitelisting валідаторів репутації.

Верифікація провайдером

У цій моделі ідентифікація делегується організації, яка розгортає агента. Провайдер підписує ончейн-атестацію, що підтверджує: цей агент належить до інфраструктури компанії X, працює під версією моделі Y і має обмеження Z на суму транзакцій. Сервіси-контрагенти довіряють не агенту безпосередньо, а підпису провайдера.

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

Як репутація впливає на доступ до сервісів та ціни

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

Практичні механізми впливу репутації:

  • Граничні ліміти. Сервіс ліквідності може дозволити агенту з нульовою репутацією операції на суму до 50 SOL за добу, тоді як агент із тривалим позитивним треком — до 5 000 SOL.
  • Комісії за доступ. API-шлюз може застосовувати знижену комісію для агентів із високим reputation score, оскільки вони статистично генерують менше помилкових запитів і повертають менше скарг.
  • Пріоритетизація в черзі. У періоди мережевого навантаження сервіси можуть віддавати пріоритет запитам агентів із підтвердженою ідентичністю та репутацією.
  • Доступ до закритих пулів. Деякі RWA-пули або приватні маркетмейкери можуть обмежити взаємодію лише агентами, які пройшли верифікацію конкретним набором провайдерів.

Важливо: репутаційний score не є універсальним. Агент із високою репутацією в області арбітражу може мати нульову репутацію як оракул для даних. Багаторазові репутаційні профілі в межах одного identity — відкрите архітектурне питання без загальноприйнятого рішення.

Ризики: спуфінг, крадіжка identity

Спуфінг — це ситуація, коли зловмисник створює агента, який імітує identity легітимного. На Solana це ускладнено криптографією: без приватного ключа неможливо підписати транзакцію від імені іншого агента. Проте атаки зміщуються на інші шари.

  • Крадіжка приватних ключів агента. Якщо ключі зберігаються на сервері провайдера без апаратного захисту (HSM), компрометація інфраструктури означає повну втрату control над identity. Агент продовжує працювати від імені легітимного, але під контролем зловмисника.
  • Підміна моделі при збереженні identity. Агент зберігає свій DID і репутацію, але провайдер непомітно замінює підлягаючу LLM-модель на іншу — з іншою поведінкою. Ончейн-identity не фіксує стан моделі, тому контрагенти не можуть виявити підміну без додаткових механізмів атестації.
  • Перехоплення сесії через компрометацію RPC. Якщо агент працює через скомпрометований RPC-вузол, зловмисник може модифікувати запити або відповіді, не змінюючи саму identity.
  • Сибільні атаки на репутацію. Створення великої кількості агентів з новими identity для маніпулювання репутаційними метриками або голосуваннями в управлінні протоколами.

Детальний розбір загроз та механізмів захисту на рівні інфраструктури викладено в окремому матеріалі: Безпека автономних AI-агентів: загрози та захист.

Обмеження та відкриті питання

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

  • Відсутність єдиного стандарту agent DID на Solana. Існують різні реалізації (Solana DID Method, інтеграції з Veramo), але жодна не стала де-факто стандартом. Компанії, що інтегрують агентів сьогодні, обирають між вендор-локом та самостійною розробкою.
  • Проблема revocation. Якщо identity агента скомпрометовано, потрібен механізм швидкого відкликання. У централізованих системах це тривіально, у децентралізованих — вимагає складних схем з реєстрами відкликаних ідентифікаторів та перевірки на стороні кожного сервісу.
  • Юридична невизначеність. Наявність DID або репутаційного score не створює юридичних прав чи зобов'язань. Якщо агент завдає збитків, питання відповідальності залишається відкритим: провайдер, оператор, власник моделі — кожен може стверджувати, що не контролював конкретну дію.
  • Приватність vs. прозорість. Повна ончейн-репутація означає повну прозорість поведінки агента, що може розкрити комерційну стратегію його оператора. Off-chain репутація з ончейн-хешами вирішує це частково, але додає складність.
  • Переносимість між мережами. Identity, побудована на PDA Solana, не переноситься в інші L1/L2 без мостів або кроссчейн-протоколів ідентичності, які самі перебувають на ранній стадії.

Реалістичний сценарій для бізнесу

Фінтех-компанія інтегрує AI-агента для автоматичного ребалансування портфеля RWA-токенів на Solana. Агент взаємодіє з трьома зовнішніми сервісами: пулом ліквідності, оракулом цін та смарт-контрактом свопа.

Рекомендована послідовність впровадження identity:

  1. Створення PDA-ідентифікатора агента через власну Anchor-програму. PDA генерується детерміновано з seeds, що включають ідентифікатор компанії та роль агента. Це гарантує унікальність без можливості дублювання.
  2. Підпис ончейн-атестації провайдером. Ключова особа компанії (або HSM) підписує запис, що підтверджує приналежність агента до організації, версію моделі та ліміти дій. Атестація зберігається в акаунті агента.
  3. Налаштування репутаційного трекінгу лише для критичних дій — виконані свопи та звернення до оракула. Кожен сервіс-контрагент записує хеш результату взаємодії в окремий акаунт репутації. Записи доступні лише для читання сторонніми сервісами.
  4. Градація доступу. Пул ліквідності перевіряє наявність атестації провайдера та репутаційний запис перед кожною операцією. Для перших 30 днів — ліміт 100 SOL на транзакцію. Після накопичення 50 успішних операцій без скарг — ліміт зростає до 1 000 SOL.
  5. Моніторинг аномалій. Окремий внутрішній сервіс компанії відстежує зміни в поведінці агента (девіація від типових сум, часу операцій, частоти звернень) і за потреби ініціює revocation PDA через оновлення стану в програмі-реєстрі.

Цей сценарій не вимагає створення універсальної репутаційної мережі чи інтеграції зі сторонніми DID-стандартами. Він використовує нативні механізми Solana для вирішення конкретного бізнес-завдання з мінімальним поверхнем атаки. Подальша масштабність — підключення додаткових сервісів-контрагентів, розширення репутаційних профілів — можлива без переробки базової identity-інфраструктури.

Для повноти картини рекомендуєто ознайомитися з тим, як ідентифіковані агенти здійснюють транзакції: Machine-to-machine платежі: архітектура та сценарії.

Джерела