Як виявити та усунути ризик тіньового штучного інтелекту

Як виявити та усунути ризик тіньового штучного інтелекту?

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

Ризик тіньового ШІ в одному абзаці

Тіньовий ШІ — це будь-який інструмент, модель, агент або виклик API ШІ, що працює всередині вашої організації без перевірки безпеки чи ІТ-фахівців. Це прямий наступник тіньового ІТ, але його важче викрити: тіньовий ІТ зазвичай залишав запис про закупівлі або мережевий підпис, з яким CASB міг зіставити. Тіньовий ШІ часто не залишає ні того, ні іншого. Працівник вставляє контракт у чат-бота, увійшовши в особистий обліковий запис, або розробник передає ключ API від постачальника моделі безпосередньо в скрипт, і жоден з нього не торкається інвентарю постачальника. Дві незалежно оприлюднені цифри показують, скільки ризиків, пов'язаних з тіньовим ШІ, вже накопичилося: 80% працівників використовують інструменти ШІ, які їхня організація не схвалила, згідно зі звітом Unseen Security про стан тіньового ШІ за 2026 рік, і 86% організацій кажуть, що їм бракує розуміння того, як дані фактично надходять до та з інструментів ШІ, що вже використовуються.

Чому ризик тіньового ШІ переріс тіньові ІТ

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

  • Штучний інтелект більше не потребує встановлення. Інструменти, що визначали тіньові ІТ (несанкціонований SaaS, несанкціоновані розширення браузера), залишали докази в інвентаризації активів. Помічник ШІ, відкритий у вкладці браузера, або API моделі, викликаний з особистої картки, не залишають нічого, що можна було б позначити на моніторингу кінцевих точок або закупівлях.
  • Штучний інтелект перемістився всередину інструментів, які ви вже схвалили. Функції в стилі Copilot тепер вбудовані в платформи, які вже є в білому списку. Платформу перевірили. Можливості штучного інтелекту непомітно вмикалися всередині неї, але зазвичай цього не відбувалося.
  • Обсяг перейшов від ініціювання людиною до машинного масштабу. Команда ThreatLabz компанії Zscaler проаналізувала 536.5 мільярда транзакцій штучного інтелекту та машинного навчання у своїй хмарі та зафіксував зростання на 3 464,6% у порівнянні з минулим роком enterprise Трафік штучного інтелекту/машинного навчання. Саме такі масштаби змін є причиною того, що тіньова оцінка ризиків штучного інтелекту, проведена рік тому, вже застаріла, і чому аудити на момент часу продовжують програвати проблемі, яка щомісяця посилюється.

Де насправді ховається тіньовий ШІ

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

  • Інструменти на основі браузера без необхідності використання кінцевих точок. Штучний інтелект повністю працює у вкладці. Немає агента для виявлення, нічого для встановлення.
  • Функції штучного інтелекту, вбудовані в санкціоновані платформи. Платформу переглянули. Функцію штучного інтелекту, яка пізніше вбудовувалася в неї, зазвичай не переглянули.
  • Використання API за особисті витрати. Розробник розміщує API моделі на особистій картці та викликає його безпосередньо з коду. Він ніколи не потрапляє до відділу закупівель, а отже, ніколи не потрапляє до інвентарю.
  • Непереглянуті інструкції та файли навичок агента. Інструменти агентного кодування все частіше виконують інструкції, записані безпосередньо в репозиторій (файли навичок, правила агентів), і ці файли можуть підключати агента до моделі, набору даних або сервера MCP, на якому ніхто не виходив на роботу.

Як виявити та усунути тіньовий ШІ

Знання того, як виявляти та усувати тіньовий ШІ, означає розглядати його як дві окремі проблеми, які мають існувати разом: знайти те, що вже існує, та переконатися, що воно не повернеться некерованим.

Виявити це: три сигнали, які працюють разом

Жодне окреме сканування не виявляє всіх ризиків тіньового ШІ, оскільки кожне сховане місце зверху залишає різний слід.

  • Журнали мережі та проксі-сервера. Журнали вашого брандмауера, проксі-сервера та DNS вже записують вихідні виклики до кінцевих точок постачальників штучного інтелекту, незалежно від того, чи був інструмент схвалений. Варто звернути увагу на такі закономірності, як високочастотні виклики API з одного хоста, великі вихідні корисні навантаження або автоматизований трафік до кінцевої точки моделі в неробочий час.
  • Сигнали ідентифікації та доступу. Мережеві журнали повідомляють вам, що інструмент використовується; ваш постачальник ідентифікаційних даних повідомляє, хто за ним стоїть і який обсяг доступу він передав. Звертайте увагу на гранти OAuth для неперевірених програм штучного інтелекту, вхід до інструментів штучного інтелекту з особистих, а не корпоративних облікових записів, та активність API сервісних облікових записів, яку ніхто не може пояснити.
  • Виявлення активів та на рівні коду. Це шар standard Інструменти тіньових ІТ-технологій не враховують цього, і це стосується того, як ШІ відображається в програмному забезпеченні: моделі, набори даних, кінцеві точки виведення, агенти, MCP-сервери та інструменти кодування ШІ, на які безпосередньо посилаються в репозиторіях, pipelineта файли навичок, а не лише в трафіку браузера. Без цього шару ви можете бачити Що викликано API моделі; ви не бачите який агент зателефонував йому з який pipeline, або з чим це пов'язано, тобто саме там, де Ризик тіньового ШІ перетворюється на інцидент у ланцюжку поставок а не порушення політики.

Позбудьтеся цього: чотири кроки, які зроблять це міцним

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

  • Створіть один інвентар, а не три. Традиційні активи (репо, pipeline(контейнери) та ресурси штучного інтелекту (моделі, набори даних, агенти, сервери MCP, інструменти кодування) повинні знаходитися в одному поданні, а зв'язки між ними відображаються. Інструмент штучного інтелекту, який сам по собі виглядає нешкідливим, може стати справжнім викриттям, якщо побачити, який набір даних йому надсилає дані та з якою кінцевою точкою він взаємодіє.
  • Класифікуйте, перш ніж писати політику. Правило, що забороняє «конфіденційні дані в інструментах штучного інтелекту», нічого не означає, якщо ніхто не може сказати, які дані мають значення. Знайте, де зберігаються регульовані та конфіденційні дані, і дозвольте цій класифікації вирішувати, які випадки використання ШІ є прийнятними, а які ніколи не залишають приміщення.
  • Надайте командам швидший шлях затвердження, а не довший список заборон. Люди звертаються до тіньового штучного інтелекту, оскільки санкціонований варіант повільніший за вкладку, яка вже відкрита перед ними. Керований каталог схвалених моделей та агентів, де облікові дані вилучені від розробників, усуває причину обходити цю політику.
  • Застосовуйте там, де фактично діє ризик: під час встановлення та виклику. Блокування моделі в документі не заважає агенту встановлювати її. Застосування має відбуватися в момент встановлення пакета або виклику API, щоб заблокована дія завершувалася автоматично, а не залежала від того, чи хтось пам’ятає правило.

Що означає ризик тіньового штучного інтелекту для AppSec, а не лише для IT

Більшість посібників з тіньового ШІ розглядають це виключно як проблему запобігання втраті даних, і DLP є її законною частиною. Але зростаюча частка ризику тіньового ШІ взагалі не відображається в браузері: вона відображається як галюцинований пакет, який намагався встановити агент, MCP-сервер, який ніхто не перевіряв, або помічник кодування з постійним доступом до репозиторію, до якого він ніколи не мав права торкатися. Це не тіньовий ІТ з міткою ШІ. Це нова категорія ризику ланцюга постачання програмного забезпечення, і вона потребує тієї ж дисципліни, яку AppSec вже застосовує до будь-якої іншої залежності: знати, що там є, перевіряти це та автоматизувати перевірку, замість того, щоб сподіватися, що кожен розробник пам'ятає перевірити.

Припиніть керувати ШІ з електронної таблиці

Розрив полягає не в зусиллях, а в видимості: більшості команд бракує єдиного місця, де б знаходилися ресурси штучного інтелекту, код та… pipelineз'являються разом, що є саме тією відстанню між «у нас є тіньова політика щодо ШІ» та «ми можемо насправді її забезпечити».

Ось у чому проблема Ксігені Безпека штучного інтелекту побудована навколо. Інвентаризація штучного інтелекту безперервно та автоматично виявляє кожен ресурс штучного інтелекту у ваших репозиторіях, pipelineта середовища розробника: моделі, фреймворки, набори даних, кінцеві точки виведення, агенти, MCP-сервери та інструменти кодування штучного інтелекту, такі як Copilot, Cursor або Claude Code, відображені у вигляді графа зв'язків зі списком (BOM) штучного інтелекту, що генерується під час кожного сканування. DevAI працює як активний захист у тих самих середовищах, перевіряючи файли навичок та інструкції агента, а також блокуючи встановлення шкідливих програм до того, як агент почне діяти, без необхідності запиту. А оскільки CoreAI застосовує ту саму кореляцію та управління на основі штучного інтелекту до результатів ваших існуючих сканерів, що й до власного Xygeni, тіньовий ризик, пов'язаний зі штучним інтелектом, не зникає в черговому відокремленому інструменті: він потрапляє в те саме подання ризиків, що й усе інше у вашому SDLC.

Почніть безкоштовно. Sign up with GitHub, GitLab або Google та отримуйте доступ до 25 репозиторіїв та 50 сканувань ШІ на місяць безкоштовно, без необхідності використання кредитної картки.

FAQ

Що таке ризик тіньового ШІ, простими словами? 

Ризик тіньового ШІ – це вплив, створений інструментами ШІ, моделями, агентами або викликами API, що виконуються всередині організації без перевірки безпеки. Оскільки більшість із них не залишає записів про встановлення та закупівлі, ризик непомітно накопичується, доки хтось не почне його цілеспрямовано шукати.

Як на практиці виявляти та усувати тіньовий ШІ? 

Виявлення працює на основі трьох сигналів, що працюють разом (мережеві та проксі-журнали, сигнали ідентифікації та доступу, а також код/pipelineвиявлення активів на рівні), а ліквідація – це чотириетапний цикл: створення єдиного інвентарю, класифікація даних перед написанням політики, надання командам швидшого затвердженого шляху та забезпечення дотримання правил у момент встановлення або виклику API, а не в документі.

Чи є тіньовий ШІ тим самим, що й тіньові ІТ?

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

Чи може інструмент CASB або DLP самостійно виявляти ризик тіньового ШІ? 

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

Де саме тіньовий ШІ найчастіше проявляється в розробці програмного забезпечення? 

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

інструменти-для-аналізу-складу-програмного-засобу-sca
Визначте пріоритети, усуньте та захистіть ризики, пов'язані з програмним забезпеченням
Отримайте свій безкоштовний обліковий запис.
Не потрібна кредитна картка.

Забезпечте розробку та доставку програмного забезпечення

з пакетом продуктів Xygeni