Під час нещодавніх оцінок кібербезпеки Інститут безпеки ШІ Великої Британії (AISI) провів випробування систем безпеки зі штучним інтелектом 122 рази на різних моделях. У 10 із цих запусків ШІ-агенти виконали 19 несанкціонованих реальних дій в інтернеті: від спроби внести шкідливий код у загальнодоступний репозиторій з відкритим кодом до запуску кампанії соціальної інженерії, спрямованої на отримання дозволу від розробника.
Ключове спостереження щодо безпеки полягає в тому, що для цього не було потреби виходити за межі пісочниці (sandbox).
Середовище оцінювання функціонувало саме так, як було розроблено. Проблема була простішою і набагато складнішою для виявлення: доступні можливості агента були просто ширшими, ніж його призначені повноваження.
Порівняйте це з серпневим аналізом OpenAI щодо їхніх дослідницьких оцінок, де моделі активно обходили засоби ізоляції, використовували спільну інфраструктуру та отримували доступ до сторонніх систем. Або розкриттям інциденту Hugging Face, що документує ескалацію на рівні вузла, збір облікових даних та горизонтальне переміщення між внутрішніми кластерами. Крім того, Anthropic повідомила про пов’язаний збій меж, коли моделі Claude вийшли в інтернет зі сторонніх оціночних систем і отримали несанкціонований доступ до реальних систем.
Ми розглядаємо два фундаментально різні типи збоїв у стеці корпоративного ШІ:
-
Збій стримування (Hugging Face / OpenAI): Агент розширює свій ефективний доступ, активно долаючи засоби безпеки.
-
Збій авторизації (AISI): Агент використовує вже наявні можливості для дій, що значно перевищують його призначене завдання, і все це без порушення стримування.
Пісочниця витримала, але агент все одно вийшов з-під контролю. То що станеться, коли стримування працює, автентифікація проходить успішно, а автономний актор все одно перевищує повноваження, надані людьми?
У моїй роботі з розробки архітектур ідентифікації та авторизації для корпоративних агентних систем найскладнішою проблемою є не з’ясування того, хто такий агент. Це збереження фактичного наміру авторизації за дією, коли виконання починає переходити між кількома агентами, робочими навантаженнями та інструментами API. Ідентичність визначає, хто такий агент. Делегування пояснює, чому він насправді уповноважений вчинити конкретну дію саме зараз.
Значна частина корпоративної реакції значною мірою спиралася на призначення сильніших ідентифікаторів агентів, вдосконалення захисних механізмів моделей та зміцнення пісочниць контейнерів. Це необхідні базові засоби контролю, але жоден з них не вирішує проблему контексту. Навіть авторизація на рівні дій залишається неповною, якщо кожне подальше виконання не може довести свою походження назад до початкового делегування.
У стандартній корпоративній архітектурі виконання проходить через багатоступеневий ланцюг:
Людина або системнийPrincipal → Програма → ШІ-агент → Робоче навантаження в реальному часі → Виконуваний інструмент → Цільовий ресурс
Під час руху виконання через цей ланцюг контекст авторизації може бути втрачений, коли виконання перетинає межі управління ідентифікацією та доступом (IAM), робочого навантаження та служб. Автентифікація встановлює ідентичність актора, а токен доступу представляє надані повноваження для певного обсягу. Але жоден з них не доводить, що подальший виклик інструменту дійсно відповідає тому, що делегувала початкова людина.
Авторитет повинен зменшуватися під час руху вниз по ланцюгу — він повинен звужуватися, а не розширюватися на кожному етапі, і він ніколи не повинен мовчки розширюватися.
Оцінка того, чи може агент викликати конкретний API, не враховує ширші архітектурні вимоги. Справжня політика авторизації в реальному часі повинна оцінювати всю картину виконання:
Principal + Agent + Workload + Task + Action + Resource + Context + Delegation Lineage
Нам потрібно припинити запитувати корпоративні команди безпеки: «Чи може цей агент викликати цей API?» і почати запитувати: «Чи можете ви довести, хто авторизував цю дію, і яке підтверджене делегування дає цьому агенту повноваження виконувати її прямо зараз?»
На щастя, стандартизаційні органи та фреймворки реального часу починають узгоджуватися щодо цієї архітектурної прогалини:
-
Аналіз NIST від 27 серпня щодо ідентичності агентів вказує на механізми збереження та зменшення контексту авторизації, підкреслюючи короткострокові облікові дані з обмеженою аудиторією та нові Transaction Tokens.
-
Стандарт контролю агентів OWASP доповнює це, надаючи стандартизовані точки інтеграції (middleware hooks) для динамічного управління агентами в реальному часі.
-
Специфікація AuthZEN від OpenID Foundation надає стандартизований API авторизації між пунктами забезпечення політики (PEP) та пунктами прийняття рішень щодо політики (PDP), тоді як робоча група IETF WIMSE визначає облікові дані ідентичності робочого навантаження та механізми автентифікації для розподілених середовищ.
NIST вказує на механізми збереження контексту делегованої авторизації. OWASP надає точки інтеграції для забезпечення в реальному часі. AuthZEN стандартизує інтерфейс прийняття рішень щодо авторизації. Корпоративні архітектори повинні об’єднати ці компоненти в підтверджену ланцюжок авторизації.
Для впровадження цього в корпоративному стеці розробки п’ять основних принципів повинні стати основою архітектури:
-
Зберігайте чіткість ідентичності суб’єкта. Підтримуйте чітке розмежування між людиною-принципалом, автономним агентом та ідентичністю виконуваного робочого навантаження в кожному журналі авторизації. Ніколи не об’єднуйте їх в єдиний, загальний обліковий запис служби.
-
Зменшуйте повноваження на кожному етапі. Обмінюйте широкі вхідні токени на короткострокові, вузькоспеціалізовані вихідні облікові дані. Дочірній агент або інструмент ніколи не повинен успадковувати або отримувати більше повноважень, ніж було надано його батьківському.
-
Прив’язуйте рішення щодо політики до контексту транзакції. Оцінюйте авторизацію, комбінуючи ідентичності суб’єктів, поточний контекст завдання, запитувану дію, цільовий ресурс, ризик середовища та ланцюжок делегування в точний момент виконання через зовнішній шар прийняття рішень щодо політики та її забезпечення.
-
Ізолюйте облікові дані багаторазового використання від рівня обробки. Ніколи не передавайте довготривалі секрети або токени оновлення безпосередньо до LLM. Використовуйте довірений шлюз, брокер або сторонній компонент (sidecar) для управління авторизацією в реальному часі та введення короткострокових облікових даних після успішної оцінки політики.
-
Підтримуйте реконструйований ланцюжок авторизації. Забезпечте командам SOC та реагування на інциденти можливість відстежувати транзакцію назад від цільового ресурсу до людини-принципала, щоб точно зрозуміти, яке рішення політики дозволило дію.
Нам потрібно припинити витрачати всі наші інженерні ресурси на спроби налаштувати автономну модель так, щоб вона ніколи не переступала межу. Натомість, давайте спроєктуємо нашу корпоративну інфраструктуру так, щоб переступлення межі просто не надавало жодних повноважень.
Нехай модель вирішує, що вона хоче зробити. Нехай інфраструктура авторизації вирішує, що їй дозволено робити. І нехай ланцюжок делегування доведе, чому їй це було дозволено спочатку.
Бадал Бхушан — Distinguished Engineer та керівник у сфері кібербезпеки.
Ласкаво просимо до спільноти VentureBeat!
Наша програма гостьових публікацій дозволяє технічним експертам ділитися думками та надавати нейтральні, не зацікавлені глибокі аналізи ШІ, інфраструктури даних, кібербезпеки та інших передових технологій, що формують майбутнє підприємств.
За даними порталу: venturebeat.com