ШІ-агент не має отримувати необмежені права в продакшені

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

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

2. Виносьте критичні дії за межі агента

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

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

3. Ізолюйте резервні копії

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

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

4. Ведіть захищений журнал усіх дій

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

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

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

5. Призначайте відповідальних людей

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

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

6. Створюйте зовнішній і надійний механізм вимкнення

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

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

7. Тестуйте поведінку, а не лише можливості

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

Перевірки мають показати, чи агент:

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

Запропонована Бенджіо концепція «Scientist AI» є одним із можливих напрямів: це неагентна система, призначена для пояснення спостережень та оцінювання запропонованих дій, а не для самостійного переслідування операційної мети. Такий наглядовий рівень міг би оцінювати, що є правдою, і які наслідки матиме план агента.

8. Визначайте вимірювані умови зупинки

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

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

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

9. Розгортайте системи поетапно

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

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

10. Запровадьте незалежні перевірки та звітування про інциденти

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

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

П’ять запитань перед доступом до продакшену

Перед запуском компанія повинна чітко відповісти на такі запитання:

1. До чого агент має доступ і що однозначно залишається поза його межами?
2. Які дії потребують погодження і чи може інфраструктура забезпечити цю вимогу?
3. Чи зможуть фахівці відновити повну картину важливих дій після інциденту?
4. Чи може зовнішній оператор негайно відкликати доступ і зупинити систему?
5. Який виміряний показник помилок або результат тесту автоматично спричинить паузу чи відкат?

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

Головний принцип

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

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