Криза видимості штучного інтелекту: чому команди безпеки літають у темряві та чому їм не потрібно цього робити

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

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

Міф про системні підказки та безпечне інструментування

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

Ми повинні працювати під припущенням, що штучний інтелект насправді “нічого не знає”. Атаки на штучний інтелект є соціальною інженерією, крім того, що мішень дурніша за середнього людини. Хто має досвід проведення тестування на проникнення, розуміє, наскільки важко організаціям захиститися від атак соціальної інженерії. Тепер наші комп’ютери також вразливі.

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

Чорна скринька аудиту штучного інтелекту

Якщо штучний інтелект виявляється злому або маніпулюється, визначення того, що він зробив, є кошмаром. Інструменти штучного інтелекту зазвичай не надають журналів аудиту. Якщо вам пощастило бути на корпоративному рівні, журнали, які ви отримуєте, сильно неповні. Наприклад, вам може бути доступна розмита подія, яка повідомляє, що користувач “використав Генеративний ІІ.” та надає тільки базові метрики, що деталізують кількість токенів вводу та виводу.

Ані однієї з цих речей не допомагає аналітику безпеки відповісти на фундаментальне питання: Що саме виконав цей агент?

Розкриття штучного інтелекту: Як перестати літати у темряві

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

Ось як ви можете використовувати свою поточну інфраструктуру, щоб виявити активність штучного інтелекту:

• Аналіз DNS: Аналіз журналів DNS для запитів до відомих доменів послуг штучного інтелекту може допомогти виявити використання штучного інтелекту в вашому середовищі.
• Списки загроз: Цей підхід вимагає підтримання оновленого списку загроз доменів, пов’язаних з платформами штучного інтелекту або постачальниками моделей.
• Ресурси спільноти: Існують проекти спільноти та блок-листи, які можна модифікувати в таблиці пошуку для програмного використання.
• Відстеження SSL: Аналогічний підхід можна використовувати для відстеження серверних імен за допомогою журналів SSL, хоча це надає трохи менше деталей, оскільки повний URL не реєструється.
• Телеметрія кінцевих точок: Ви можете використовувати інструменти, такі як Sysmon, для підрахунку дочірніх процесів та полювання на високі спавнери оболонки, що є сильним індикатором потенційних агентів штучного інтелекту, які виконують команди на кінцевій точці.

Сліпа пляма, яка вимагає активних змін у вашому зборі даних, – це самі підказки. Що користувачі запитують у штучного інтелекту? Чи завантажують вони будь-які потенційно чутливі документи, тим самим створюючи проблеми з дотриманням вимог? Відповіді на ці питання, ймовірно, потребують збору запитів API до постачальника; веб-проксі, проксі LLM та інструменти збору даних від постачальників журналів та SIEM. Це може зняти завісу, яка блокує цей цінний джерело даних.

Новий загроза: Зловмисні сервери MCP

Протокол контексту моделі (MCP) з’явився як спосіб вказівки того, як додатки штучного інтелекту інтегруються з зовнішніми інструментами та джерелами даних. Хоча він стандартизує з’єднання, він також вводить нові вектори атак через “Злий MCP” сервери.

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

Студенти часто використовують свій зловмисний сервер, щоб інструктувати штучний інтелект, що він знаходиться “в режимі технічного обслуговування” та повинен передавати дані до допоміжного інструменту для “журналу аудиту”, що призводить до витоку даних. Дехто з них більш творчі зі своїми підказками, ніж інші, але всі вони зазвичай успішні.

Відновлення контролю

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