Більшість розмов про безпеку ШІ досі зосереджені на самій моделі: чи узгоджена велика мовна модель (LLM), чи можна її обійти (jailbreak), чи галюцинує вона під тиском. Це реальні питання. Але оскільки організації переходять від пілотних проєктів до впровадження ШІ-агентів та робочих процесів на основі LLM, виникає інша категорія ризиків, яка майже не стосується ваги самої моделі, а натомість пов’язана з системою, що її оточує.
Модель рідко стає слабкою ланкою. Слабка ланка — це робочий процес.
Зміна, що змінює модель загроз
Останні два роки більшість корпоративних дискусій про безпеку ШІ базувалася на досить вузькій моделі взаємодії: користувач вводить запит, модель повертає текст, людина читає його. Ця модель загроз вже застаріла. Сучасні виробничі системи ШІ читають дані з живих джерел, викликають зовнішні інструменти та API, записують дані в бази даних, запускають подальші автоматизації і, у зростаючій кількості випадків, вживають заходів без участі людини.
Кожна з цих можливостей також є поверхнею атаки, якої не існувало в епоху «чат-ботів».
Ін’єкція запитів через підключені дані
Коли агент отримує контент із запису CRM, запиту підтримки, зібраної вебсторінки чи спільного документа, цей контент стає частиною його контексту. Зловмиснику не потрібен доступ до вашої моделі, щоб маніпулювати її поведінкою; йому достатньо отримати доступ до чогось, що модель зрештою прочитає. Інструкції, вбудовані в PDF, підпис електронного листа або огляд продукту, можуть так само ефективно захопити наступну дію агента, як і створений запит, введений безпосередньо в чат.
Надмірні дозволи для виклику інструментів
Фреймворки для агентів все частіше надають моделям можливість викликати функції: надсилати електронні листи, запитувати бази даних, змінювати записи, виконувати код. Багато з цих інтеграцій створені з дозволами, призначеними для швидкості розробки, широкими ключами API, обліковими записами служб з набагато більшим доступом, ніж вимагає конкретне завдання, оскільки це найшвидший спосіб отримати робочу демонстрацію. У виробництві ця ж модель дозволів означає, що один маніпульований запит або одна помилка у міркуваннях може призвести до реальних наслідків: видалення неправильного запису, надсилання повідомлення не тому адресату, ініціювання платежу.
Крихкі межі довіри між інструментами
Багатоінструментальні та багатоагентні конвеєри передають вихідні дані від одного компонента до іншого, часто без повторної перевірки того, що перетинає межу. Модель, яка узагальнює недовірений документ і передає це узагальнення другому агенту, який має права на запис у виробничу систему, фактично дозволяє неавтентифікованій третій стороні впливати на цю систему, хоча жодна людина явно не надала їй такої довіри.
Відсутність спостережуваності
Традиційна безпека програмного забезпечення передбачає можливість реєструвати запит, відстежувати стек викликів і реконструювати події після інциденту. Агентні робочі процеси часто не можуть запропонувати такого. Сліди міркувань є недетермінованими, послідовності викликів інструментів варіюються від запуску до запуску, і багато команд ще не реєструють проміжні рішення агентів із такою деталізацією, яка б дозволила їм відповісти на базове питання реагування на інциденти: що насправді зробила система і чому?
Автоматизовані потоки прийняття рішень без запобіжника
Зі зростанням автономії агент не просто готує відповідь; він її надсилає. Агент не просто позначає аномалію; він діє на неї. Ціна одного поганого рішення накопичується, особливо коли між «модель вирішила» і «дія сталася» немає обмеження швидкості, важеля схвалення чи кнопки вимкнення.
Жодна з цих проблем не є проблемою моделі. Ви можете замінити її більш потужною, краще узгодженою LLM, і всі вони залишаться, оскільки вони існують у «сантехніці», а не у вазі.
Чому це проблема управління, а не лише інженерії
Частково причиною недостатнього інвестування в ризики на рівні робочих процесів є організаційна: питання безпеки ШІ зазвичай потрапляють до команд машинного навчання (ML) або науки про дані, які оснащені для оцінки поведінки моделей, але не обов’язково мають позицію чи фінансування для управління безпекою інтеграцій, контролем доступу чи виробничою спостережуваністю. Тим часом команди з безпеки та платформенної інженерії, які мають десятиліття інституційного досвіду безпечного захисту саме таких систем (сервіси, що викликають сервіси, облікові дані з обмеженими дозволами, аудит журналювання, реагування на інциденти), часто не залучаються до процесу, доки агентний робочий процес не стане активним.
Організації, які успішно масштабують ШІ, зазвичай рано закривають цю прогалину. Вони ставляться до ШІ-агента так само, як до будь-якого нового виробничого сервісу з правами запису в реальні системи, що на практиці означає досить непривабливий контрольний список:
-
Доступ за принципом найменших привілеїв за замовчуванням. Дозволи на інструменти та API мають бути обмежені точно тим, що вимагає дане завдання, а не тим, що зручно під час розробки. Якщо агенту потрібно лише читати запис клієнта, він не повинен мати облікові дані, які також дозволяють записувати до нього.
-
Ізоляція перед автономією. Нові інтеграції інструментів та можливості агентів тестуються в середовищі, де погане рішення коштує недорого, з навмисним, керованим шляхом до виробничого доступу, а не надсилаються безпосередньо з повними дозволами, тому що демонстрація працювала.
-
Важелі схвалення людиною для дій з високими наслідками. Автономія не є бінарною. Робочий процес може дозволити моделі підготувати дію, але все ще вимагати явного схвалення перед будь-якими зовнішніми діями: повернення коштів, надсилання електронного листа клієнту, зміна в активній системі. Поріг схвалення встановлюється залежно від потенційного збитку від дії, а не від того, наскільки впевнено звучить модель.
-
Журналювання на рівні прийняття рішень, а не лише на рівні вихідних даних. Захоплення того, що агент прочитав, які інструменти викликав, які аргументи передав і чому, щоб після інциденту питання «що сталося і чому» мало відповідь, яка не потребує вгадування.
-
Ставлення до сторонніх даних як до неперевіреного вхідного сигналу. Будь-який контент, який агент отримує з-за меж ваших власних перевірених систем — вебсторінка, завантажений файл, електронний лист — слід обробляти з такою ж підозрою, як і вхідні дані користувача в традиційній веб-програмі, оскільки, фактично, це саме те, чим він є.
-
Явні запобіжники. Обмеження швидкості, виявлення аномалій та можливість ручного втручання для автоматизованих дій, щоб один поганий ланцюг міркувань не міг накопичитися до тисяч поганих дій, перш ніж людина помітить.
Розмова, яка потребує зміни
Жодне з цього не є екзотичним. Це та сама інженерна дисципліна, яка керувала виробничим програмним забезпеченням протягом двох десятиліть: обмежені дозволи, валідація вхідних даних, спостережуваність, поетапні розгортання, людський перегляд відповідальних дій. Новим є те, що ймовірнісна, часом непередбачувана модель тепер знаходиться всередині цієї системи, приймаючи деякі рішення щодо того, що станеться далі.
Саме тому робочий процес навколо моделі заслуговує на більшу увагу, ніж він отримує. Більш потужна модель не робить надмірно уповноважену інтеграцію безпечнішою. Краще узгоджена LLM не виправить відсутній важель схвалення. Оскільки ШІ-агенти беруть на себе більше автономної, відповідальної роботи в реальних бізнесах, організації, які постраждають, не обов’язково будуть тими, хто використовує слабшу модель; це будуть ті, хто ніколи не питав, чи була система навколо їхньої моделі побудована для безпеки взагалі.
Дізнатися більше на: venturebeat.com