Від інтелекту до повноважень

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

Ця відмінність має значення.

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

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

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

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

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

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

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

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

Гра в кота й мишу на машинній швидкості

Кібербезпеку давно описують як гру в кота й мишу.

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

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

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

Цей потенціал подвійного використання є ключовим для розуміння безпекових наслідків автономного ШІ.

Project Glasswing від Anthropic — приклад виявлення вразливостей за допомогою ШІ. У своєму дослідницькому оновленні за травень 2026 року Anthropic повідомила про значні результати у виявленні вразливостей, водночас наголосивши на практичних труднощах їхньої перевірки, розкриття інформації про них і випуску виправлень.

Ця відмінність має значення. Виявити вразливість — не те саме, що підтвердити можливість її використання, усунути її або довести, що вразливу систему захищено.

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

Результат для безпеки залежить від того, що відбувається далі.

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

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

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

Архітектурні стики: де перетинаються межі безпеки

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

Такі точки взаємодії я називаю архітектурними стиками.

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

Кожна система може працювати за власними правилами. Проте їхня взаємодія може призвести до передавання інформації всупереч установленим організацією межам безпеки.

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

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

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

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

Дослідження дають практичні підстави уважно вивчати такі взаємодії.

У AgentDojo дослідники оцінювали атаки з ін’єкцією промптів на ШІ-агентів, які використовують інструменти, у 97 реалістичних завданнях і 629 тестових випадках із безпеки. Результати показали, що зловмисні інструкції, передані через ненадійні результати роботи інструментів, могли порушувати окремі властивості безпеки, хоча атаки й агенти не були однаково успішними.

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

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

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

Також необхідно розподілити відповідальність між різними складниками архітектури.

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

Автономність не скасовує відповідальності. Навпаки, вона робить розуміння того, на кому лежить ця відповідальність, ще важливішим.

Ретельність у наступальному тестуванні: перевіряємо те, що, як нам здається, ми знаємо

Тут ми підходимо до поняття, яке я називаю ретельністю в наступальному тестуванні.

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

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

Ці методи об’єднує одне ключове запитання:

Які докази підтверджують, що передбачена межа безпеки справді витримує перевірку?

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

Усе це — важливі засоби захисту. Однак сама їхня наявність не доводить, що вся система працюватиме безпечно в умовах протидії.

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

Іноді я називаю це «ілюзією захисних бар’єрів»: помилковим переконанням, що сама наявність таких бар’єрів доводить нездатність системи переступити межу, яку вони мали захищати.

Захисні бар’єри корисні. Проте їхню ефективність усе одно потрібно довести.

Уявімо автономного агента, якому доручено розслідувати ймовірний злам. Він може отримувати журнали подій, аналізувати активність користувачів і рекомендувати заходи для локалізації загрози.

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

Тестування не має обмежуватися з’ясуванням того, чи виконав агент ці інструкції.

Потрібно перевірити, чи намагався агент виконати несанкціоновану дію, чи запобігли її виконанню незалежні засоби контролю, чи було зафіксовано цю спробу та чи належним чином відновилася робота системи.

Offensive Rigor поєднує п’ять видів діяльності:

1. Визначити припущення: встановити, яку властивість безпеки має забезпечувати архітектура.
2. Перевірити припущення: випробувати реалістичні сценарії атак, маніпульовані вхідні дані та поєднання легітимних можливостей.
3. Зібрати докази: з’ясувати, що намагалася зробити система, що було виконано і які засоби контролю спрацювали.
4. Усунути вразливість: виправити модель, робочий процес, дозволи, архітектуру або операційну процедуру, що спричинили збій.
5. Перевірити виправлення: повторно випробувати відповідний сценарій атаки й підтвердити, що потрібна властивість безпеки забезпечується.

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

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

Те, що інструмент є легітимним, не означає, що кожен спосіб його використання також легітимний.

Мета Offensive Rigor — не виходити з припущення, що автономні системи є незахищеними. Мета — за допомогою тестування з’ясувати, де проходять межі їхньої безпеки.

Умовна автономність: розмежування інтелекту та повноважень

Один із архітектурних підходів — відокремити те, що система ШІ здатна робити, від того, на що вона має дозвіл.

Я називаю цей підхід умовною автономністю.

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

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

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

Ці межі не повинні розширюватися лише тому, що агент вирішив: ширший доступ допоможе йому досягти мети.

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

У OWASP: 10 найважливіших ризиків для застосунків на основі LLM цю проблему розглянуто в категорії LLM06:2025 — надмірна агентність. OWASP визначає надмірну функціональність, дозволи й автономність як джерела ризику та рекомендує обмежувати можливості й забезпечувати авторизацію незалежними засобами.

Умовна автономність застосовує ці принципи з урахуванням операційного ризику.

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

Ці запобіжні заходи особливо важливі під час автономного тестування на проникнення.

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

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

Це відповідає усталеним принципам найменших привілеїв і розподілу обов’язків.

Це також порушує цікаве питання про архітектуру Bring Your Own Model (BYOM) або «власна мовна модель» (BYO-LLM).

Якщо завтра базову модель замінять, які гарантії безпеки залишаться чинними?

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

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

Повноцінне оцінювання має перевіряти як засоби контролю, які мають залишатися незмінними, так і поведінку, що змінюється після заміни моделі.

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

Коли ШІ діє на ШІ: проблема перевірки

Розгляньмо гіпотетичний робочий процес у сфері операційної безпеки:

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

Агент-розслідувач аналізує телеметрію. Інший агент рекомендує заходи стримування. Агент із правом на виконання вносить зміни. Агент перевірки оцінює результат.

Це приклад автономного реагування на інцидент із замкненим циклом, а не задокументований збій у всій галузі.

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

Вибрану операцію виконано.

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

Перевірка не може зводитися лише до підтвердження того, що агент виконав вибрану ним дію.

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

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

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

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

Засоби контролю мають відповідати тяжкості наслідків можливої помилки.

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

Чотири запитання допомагають розрізнити відповідні властивості безпеки:

• Чи правильно система зрозуміла поставлене завдання?
• Чи входила дія до меж делегованих їй повноважень?
• Чи залишалося виконання в дозволених межах?
• Чи відповідав отриманий результат визначеній меті безпеки?

Ці запитання пов’язані, але не взаємозамінні.

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

Жоден із цих випадків не слід автоматично вважати успішним забезпеченням безпеки.

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

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

Довіра має ґрунтуватися на доказах

Наслідки використання автономного ШІ для безпеки не є винятково негативними.

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

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

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

Є й вагомий контраргумент проти думки, що автономний ШІ потребує принципово нових засад безпеки.

Багато базових проблем — надмірні привілеї, недовірені вхідні дані, слабка авторизація, непослідовне застосування політик і недостатня перевірка — досліджують уже десятиліттями.

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

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

Докази підказують поставити корисніше запитання: за яких умов можна довірити автономним системам делеговані повноваження і як довести, що ці умови виконано?

Самих лише можливостей моделі для відповіді недостатньо.

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

Також потрібне послідовне, але водночас гнучке бачення безпеки й ризиків.

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

У цьому й полягає мета суворої наступальної перевірки.

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

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

Гра в кота-мишку триває. Обидві сторони дедалі частіше можуть мати автономних гравців.

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

Довіра має ґрунтуватися на доказах.

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