Інтелектуальні агенти стають розумнішими, а їхня поверхня атаки зростає

Момент, коли інтелектуальні агенти почали бронювати зустрічі, виконувати код і переглядати веб-сторінки від вашого імені, змінив розмову про кібербезпеку. Не повільно, а саме в одну ніч.

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

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

Від чат-ботів до операторів

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

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

Більше доступу означає більшу вразливість

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

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

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

Введення підказки є новим SQL-введенням

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

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

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

Проблема довіри всередині багатокомандних систем

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

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

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

Як виглядає розумна безпека тут

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

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

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

Останні думки

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

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