Як ШІ-агенти створюють нові ризики для безпеки підприємств? Розуміння викликів інструментів і меж дозволів

3 листопада 2026 року Binance оприлюднила попередню заяву про розслідування щодо інциденту безпеки, який стався 29 жовтня. У заяві йдеться, що зловмисники скомпрометували пристрої інженерів за допомогою шкідливого програмного забезпечення та використали внутрішні інструменти ШІ для подальшого розширення свого доступу. Згідно із заявою, атака зрештою передбачала несанкціонований доступ до внутрішнього сервісу підписання транзакцій гаманців, що вплинуло приблизно на $6,34 млрд у цифрових активах. Водночас у заяві не розкрито повну архітектуру внутрішніх інструментів ШІ та не підтверджено, що атака використала вразливості безпосередньо у великій мовній моделі або була пов’язана з ін’єкцією промптів.

Цей інцидент порушує важливе питання корпоративної безпеки: коли AI Agent може отримувати доступ до більшої кількості внутрішніх інструментів і конфіденційних систем, як підприємствам розмежовувати дозволи на обробку інформації та фактичні операційні дозволи? У цій статті пояснюються межі дозволів, ін’єкція промптів, керування обліковими даними та ризики горизонтального переміщення, починаючи з того, як AI Agents викликають інструменти. Також у ній аналізуються заходи безпеки, які можуть застосовувати підприємства.

Основні висновки

• AI Agents можуть не лише генерувати текст. Вони також можуть виконувати код, читати файли, отримувати доступ до API або керувати внутрішніми корпоративними системами через виклики інструментів.

• У попередній заяві Binance про розслідування, оприлюдненій 3 листопада 2026 року, зазначено, що зловмисники використали скомпрометовані пристрої інженерів і внутрішні інструменти ШІ, щоб отримати подальший доступ до пристроїв та дозволів інших інженерів.

• Один з основних ризиків безпеки AI Agents полягає в перетворенні інформації із зовнішніх середовищ або середовищ із низьким рівнем довіри на дії з фактичними правами виконання.

• Ін’єкція промптів, шкідливі результати роботи інструментів, надмірні дозволи та витоки облікових даних можуть посилювати одне одного. Водночас не кожна атака за участю інструментів ШІ є атакою з ін’єкцією промптів.

• Підприємствам потрібно розглядати AI Agents як суб’єкти виконання програмного забезпечення з конкретними ідентичностями та дозволами й контролювати ризики за допомогою принципу найменших привілеїв, ізоляції інструментів, схвалення операцій і механізмів аудиту.

Чим AI Agents відрізняються від традиційних чатботів зі ШІ?

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

Відмінність AI Agents полягає в тому, що вони можуть пов’язувати рішення, згенеровані моделлю, із зовнішніми інструментами. Наприклад, розробники можуть налаштувати Agent за допомогою інструментів для пошуку коду, виконання команд у терміналі, запитів до баз даних і керування Git-репозиторіями. Коли користувач надсилає завдання, Agent може спочатку отримати відповідні файли, потім викликати інструменти для отримання інформації, а далі визначити наступні дії на основі результатів. За наявності відповідних дозволів Agent навіть може створювати коміти коду, запускати тести або виконувати процеси розгортання.

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

Тому безпеку AI Agent не можна оцінювати лише за точністю відповідей моделі. Навіть якщо згенерований моделлю вміст не містить очевидних помилок, Agent усе одно може виконати операції, що виходять за межі очікувань користувача, якщо дозволи інструментів налаштовано неналежним чином. Підприємствам слід зосереджуватися не лише на тому, що генерує ШІ, а й на тому, що ШІ може читати, що він може викликати та які операції фактично можуть змінити стан системи.

Як AI Agents викликають інструменти?

Виклик інструментів є важливим механізмом взаємодії AI Agents із зовнішніми системами. Розробники зазвичай надають моделі назви, функціональні описи та структури параметрів доступних інструментів. Потім модель визначає, чи потрібно викликати конкретний інструмент, на основі поточного завдання. Фактичне виконання зазвичай здійснює середовище виконання або застосунок Agent, після чого результати роботи інструмента передаються моделі для подальшої обробки.

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

Ризики виклику інструментів переважно походять із двох джерел.

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

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

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

Чому AI Agents можуть розширювати поверхню атаки підприємства?

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

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

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

Отже, AI Agents розширюють не лише кількість програмних інтерфейсів, а й зв’язки між дозволами, що поєднують різні системи. Підприємствам потрібно оцінювати, до яких ресурсів має доступ кожен Agent, чи може він перетинати різні домени безпеки та чи існують шляхи від інструментів із низьким ризиком до систем із високим ризиком.

Чому ін’єкція промптів може впливати на виклики інструментів AI Agents?

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

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

Такі атаки зазвичай називають непрямою ін’єкцією промптів. Зловмиснику не потрібно надсилати команди безпосередньо користувачеві Agent. Натомість він може впливати на Agent через вебсторінки, документи, коментарі в коді, результати пошуку або результати роботи інструментів. OWASP відносить ін’єкцію промптів, зловживання інструментами, підвищення привілеїв і розкриття конфіденційної інформації до важливих ризиків безпеки AI Agents.

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

Які ризики для інструментів ШІ та керування дозволами виявляє інцидент безпеки Binance?

У попередній заяві про розслідування, оприлюдненій 3 листопада 2026 року, Binance повідомила про багатоступеневу атаку, що розвинулася від компрометації пристрою працівника до зловживання внутрішньою системою підписання транзакцій гаманців. Згідно із заявою, у вересні зловмисники під час фальшивої співбесіди спонукали інженера-програміста завантажити репозиторій зі шкідливим кодом. Шкідливий код виконався під час налаштування середовища та встановив контрольовані зловмисниками канали зв’язку шляхом заміни компонентів інструментів розробки й іншими методами.

20 жовтня зловмисники використали комп’ютер скомпрометованого інженера та внутрішні інструменти ШІ, щоб отримати контроль над пристроями інших інженерів. Вони також виявили Token дозволу на розгортання контейнерів на пристрої інженера з операцій із гаманцями. 29 жовтня зловмисники використали відповідні облікові дані для розгортання контейнерів і запуску шкідливих скриптів, зрештою отримавши доступ до процесу підписання операцій із гаманцями.

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

Важливо підкреслити, що Binance не розкрила конкретну реалізацію своїх внутрішніх інструментів ШІ. Тому неможливо підтвердити, чи були ці інструменти AI Agents із можливостями автономного планування, або зробити висновок, що атака була пов’язана з MCP, ін’єкцією промптів чи вразливістю конкретної моделі. Інцидент показує, що інструменти ШІ можуть бути частиною складного шляху атаки, але сам по собі не доводить, що першопричиною атаки був AI Agent.

Що таке межа дозволів AI Agent і чому принцип найменших привілеїв такий важливий?

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

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

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

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

Які нові виклики безпеки можуть створювати протоколи підключення інструментів, такі як MCP?

Model Context Protocol (MCP) — це відкритий протокол для підключення застосунків ШІ до зовнішніх інструментів і ресурсів даних. За допомогою MCP розробники можуть підключати AI Agents до файлових систем, баз даних, репозиторіїв коду та інших сервісів без потреби розробляти зовсім інший метод інтеграції для кожного інструмента.

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

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

OWASP рекомендує запровадити механізм аудиту для MCP Servers, підключених до інструментів ШІ для програмування, обмежувати інструменти, які можна викликати, і перевіряти, чи містять визначення інструментів шкідливі інструкції. Agents, які виконують код, також мають використовувати такі заходи, як ізоляція в пісочниці, обмеження мережевого доступу та незалежне керування обліковими даними.

Сам MCP не є вразливістю безпеки. Оцінювати потрібно реалізацію інструментів, автентифікацію, конфігурацію дозволів і те, як зовнішній вміст впливає на поведінку Agent після підключення протоколу.

Як підприємствам захищати ідентичності AI Agents і дозволи доступу?

Підприємствам насамперед слід створити для AI Agents систему ідентичності, яку можна ідентифікувати та перевіряти за допомогою аудиту. Традиційні застосунки зазвичай використовують сервісні акаунти або API Keys для доступу до інших систем. Однак операції AI Agent можуть одночасно охоплювати авторизацію користувача, автоматизовані завдання та кілька інструментів. Тому підприємствам потрібно чітко розмежовувати ідентичність користувача, ідентичність Agent і фактичні дозволи на виконання.

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

У лютому 2026 року Національний центр передового досвіду в галузі кібербезпеки (NCCoE) при Національному інституті стандартів і технологій (NIST) опублікував концептуальний документ про ідентичність і авторизацію програмного забезпечення та AI Agents. У документі розглядалися питання розпізнавання ідентичності Agent, автентифікації, авторизації, тимчасових облікових даних, делегованих дозволів і аудиту. Це відображає розширення безпеки AI Agents від контролю результатів роботи моделі до повноцінної системи керування ідентичностями та доступом.

У фактичних розгортаннях підприємства можуть використовувати короткострокові облікові дані доступу та обмежувати дозволи конкретними завданнями, ресурсами й часовими періодами. Для високоризикових дій, таких як розгортання у виробничому середовищі, фінансові операції та зміни дозволів, також слід вимагати незалежного схвалення та вторинної перевірки. Таким чином, навіть якщо середовище виконання Agent буде скомпрометовано, зловмисник може не отримати безпосереднього доступу до довгострокових облікових даних із високими привілеями.

Як підприємства можуть зменшити ризики безпеки викликів інструментів AI Agent?

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

• Підприємствам слід обмежувати інструменти, які може використовувати Agent, відповідно до бізнес-вимог. Agent, який лише отримує інформацію, не потребує можливостей довільного виконання коду, а Agent для перевірки коду не повинен автоматично отримувати дозволи на розгортання у виробничому середовищі. Для інструментів із можливістю запису підприємства можуть додатково обмежувати шляхи файлів, таблиці баз даних, типи операцій API та обсяги доступу.

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

• Підприємствам слід вимагати схвалення людиною для незворотних операцій. Такі операції, як видалення важливих даних, зміна дозволів, розгортання виробничих сервісів або переказ активів, не повинні виконуватися автоматично лише тому, що Agent вважає завдання обґрунтованим. Рекомендації Microsoft щодо безпеки Agent Framework також радять визначати потребу в підтвердженні людиною на основі впливу, чутливості даних і зворотності операції.

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

Ці заходи не можуть гарантувати повне усунення ризиків безпеки AI Agents. Проте вони можуть зменшити масштаб впливу після успішної атаки та підвищити ймовірність виявлення й усунення аномальної поведінки.

Чому безпека AI Agents стає важливим питанням для інфраструктури Web3?

Поєднання AI Agents та блокчейн-інфраструктури надає викликам інструментів і керуванню дозволами безпосереднішого значення для безпеки активів. У традиційних корпоративних сценаріях Agent може виконувати код, надсилати електронні листи або змінювати базу даних. У сценаріях Web3 Agent також може підключатися до гаманців, запитувати ончейн-активи, викликати смартконтракти або ініціювати запити на транзакції.

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

У цьому процесі Session Keys, смарт-акаунти та механізми детальної авторизації можуть забезпечувати різні форми керування дозволами. Проте їхня безпека залежить від конкретної реалізації. Session Keys можуть обмежувати певні операційні дозволи конкретним періодом або обсягом, тоді як смарт-акаунти можуть обмежувати поведінку транзакцій правилами контракту. Водночас ризики безпеки все ще можуть виникати, якщо умови авторизації є надто широкими, логіка перевірки містить дефекти або середовище виконання скомпрометовано.

Тому розвиток Web3 AI Agents не може зосереджуватися лише на ефективності автоматизованої торгівлі чи ончейн-платежів. Він також має охоплювати перевірку ідентичності, делегування дозволів, схвалення транзакцій і відкликання авторизації. Для систем ШІ, підключених до реальних активів, межа безпеки повинна охоплювати весь процес — від рішень моделі до викликів інструментів, формування транзакцій, перевірки підписів і ончейн-виконання.

Висновок

AI Agents змінюють спосіб використання штучного інтелекту підприємствами. У міру підключення моделей до репозиторіїв коду, внутрішніх API, баз даних і засобів автоматизації системи ШІ вже не є лише точками входу для обробки інформації. Вони дедалі більше стають суб’єктами виконання програмного забезпечення з фактичними операційними можливостями.

Попереднє розслідування Binance щодо інциденту безпеки, розкритого 3 листопада 2026 року, вказує, що внутрішні інструменти ШІ могли бути частиною складного шляху атаки. Однак доступної інформації недостатньо, щоб довести, що інцидент був безпосередньо спричинений вразливістю AI Agent або ін’єкцією промптів. Важливіший висновок полягає в тому, що підприємствам потрібно переоцінити зв’язки доступу між середовищами розробки, інструментами автоматизації та системами з високими привілеями.

У майбутньому безпека AI Agents залежатиме не лише від того, чи можуть моделі розпізнавати шкідливі інструкції, а й від того, чи можуть підприємства створити надійну автентифікацію ідентичності, принцип найменших привілеїв, ізоляцію інструментів і механізми незалежного схвалення. Лише належно відокремивши можливості ухвалення рішень ШІ від фактичних дозволів на виконання, підприємства зможуть контролювати потенційні ризики, одночасно підвищуючи ефективність автоматизації.

FAQ

Чому AI Agents мають більше ризиків безпеки, ніж звичайні чатботи?

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

Що таке виклик інструментів AI Agent?

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

Чи може ін’єкція промптів завжди контролювати AI Agent?

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

Чи доводить інцидент безпеки Binance наявність вразливостей у AI Agents?

Ні. Попереднє розслідування Binance підтвердило, що шлях атаки передбачав внутрішні інструменти ШІ, але не розкрило технічних доказів, достатніх для встановлення існування вразливості AI Agent або ін’єкції промптів.

Чи збільшує MCP ризики безпеки AI Agents?

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

Як підприємствам обмежувати дозволи AI Agent?

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