AI-воркфорс безпека: де ламається ізоляція агентів
Агент, якому видали один токен із правами на читання й запис відразу до всіх суміжних систем, перестає бути акуратним виконавцем.
Він бачить сервіси, що не стосуються завдання, і рано чи пізно викликає не той метод — не зі злим умислом, а тому що контекст підказав очевидний наступний крок.
Ціна такої помилки вища, ніж у звичайного збою в коді. Автономний агент працює ланцюжком: правка довідника тягне перерахунок, перерахунок — розсилку, розсилка — зміну зовнішніх даних. Відкотити це однією командою нічим, бо формально кожен крок був легальний.
AI-воркфорс безпека тримається не на заборонах, а на тому, що кожен агент отримує власну область видимості: свої облікові дані, свій набір інструментів, свою межу на обсяг змін.
Розмежування прав агентів будується не за звичними ролями оператора, а за конкретними викликами — що саме дозволено зробити і з якими даними.
Ризики автономних агентів майже ніколи не в самій моделі, а в способі її підключення.
Якщо немає журналу викликів, послідовність дій не відновити; якщо немає обмеження на кількість кроків, агент зациклюється; якщо перевірочний контур не відокремлений, тестовий прогін іде по бойових даних.
Нижче розбираємо, як це закривається на рівні ізоляції агентів, меж прав і журналювання — до того, як агент потрапить у робочий контур.
Що дає керована ізоляція: складання, відкати, простій
Безпека AI-воркфорсу тримається на межах, а не на довірі до моделі. Агент без обмеженого контуру бачить весь кластер: секрети, внутрішню мережу, чужі томи — і одна зайва інструкція в ланцюжку викликів відправляє його писати не туди.
Ізоляція закриває це на рівні платформи: Kubernetes дає кожному агенту окремий простір імен, ліміти за процесором і пам’яттю та мережеві політики, що дозволяють лише узгоджені вихідні з’єднання.
Що змінюється у вимірюваних величинах
- Виведення нового агента — дні замість тижнів: конфігурація, права й точка підключення збираються з шаблону.
- Відкат — хвилини: повернення до попередньої незмінної збірки відбувається перемиканням, а не відновленням із резервної копії.
- Клас відмов «агент зробив зайве» зникає: запис поза своєю областю й надсилання даних назовні блокується політикою, а не перевіркою постфактум.
- Вікно простою — один контур: збійний агент не тягне за собою решту.
Відкат, який не перетворюється на інцидент
Передбачуваний час відкату тримається на тому, що попередні ревізії зберігаються обмежено й заздалегідь відомі. Інженер повертає минулу версію однією операцією, перевіряє її стан і лише потім знімає обмеження.
Простій у такій схемі — хвилини недоступності одного агента, а не розбір наслідків його дій і чищення даних.
Режими ізоляції: контури безпеки та їхні обмеження
Режим ізоляції відповідає на питання, що станеться, якщо агент помилиться або відхилиться вбік. Чим щільніший контур безпеки, тим менший радіус ураження — і тим менше даних доступно моделі.
Повністю ізольоване середовище виконання без мережі та облікових даних захищає максимально, але агент не побачить ні довідників, ні черг завдань.
Обмеження ізоляції розкладаються за трьома осями: вихідна мережа, доступ до файлів, облікові дані. Комбінація осей і дає практичні режими — від закритої пісочниці до обмеженого доступу до внутрішніх систем.
Чотири режими та їхні межі
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Повністю ізольоване середовище виконання | Розбір чутливих масивів: знеособлення, підготовка даних, перевірка коду | Немає мережі та облікових даних, обмін лише файлами, перенесення — окремим кроком |
| Обмежений доступ до внутрішніх систем | Агенту потрібні конкретні джерела: довідник, черга завдань, сховище звітів | Список дозволених сервісів треба підтримувати: розширення прав накопичується непомітно |
| Окремий обліковий запис | Швидкий старт на наявних сервісах, коли повний контур ще не вибудовано | Успадковує спільну мережу, ізоляція слабша, аудит тримається на дисципліні прав |
| Гібридний режим | Планова обробка в закритому контурі, доступ до даних — через шлюз із перевіркою запитів | Складніше супроводження: маршрутизація, контроль схем даних, версіонування доступів |
Режими не виключають один одного: починають з окремого облікового запису, потім звужують доступ до списку сервісів і переводять планові завдання в закритий контур.
Правила доступу зберігають у конфігурації та версіонують разом із кодом, щоб посилення або відкат режиму займали один прогін, а не переписування сценаріїв.
Порядок впровадження: аудит, схема, налаштування, перевірка, передача
Починаємо з інвентаризації, а не з налаштування: без карти агентів, їхніх облікових записів і зовнішніх підключень будь-яка політика будується навмання. Нижче — послідовність, де кожен крок спирається на результат попереднього.
Етапи впровадження
- Аудит контуру агентів. Збираємо список агентів, моделей та інструментів, до яких вони звертаються, фіксуємо сервісні облікові записи, ключі, зовнішні сервіси й обсяги доступних даних. На виході — карта контуру з позначкою, де права видані ширше за завдання.
- Проєктування схеми доступу. Для кожного агента описуємо, що він читає, куди пише і що йому заборонено; розділяємо ролі агентів і людей. Схему узгоджуємо з власником процесу до першого налаштування.
- Налаштування обмежень. Видаємо мінімально достатні права, вмикаємо ізольоване середовище виконання, обмежуємо мережеві виклики й обсяг даних на одну операцію.
- Перевірка на спробах обходу. Проганяємо сценарії виходу за периметр: підміна запиту, виклик забороненого інструменту, читання чужого контексту. Кожне спрацювання закриваємо окремим правилом.
- Журналювання та розбір інцидентів. Пишемо, хто викликав агента, з якими правами і що повернулося; налаштовуємо оповіщення. Інакше розбір збою перетворюється на здогадки.
- Передача регламентів. Віддаємо схему доступу, матрицю ролей, порядок підключення нових агентів і відкликання прав під час виведення з експлуатації.
- Супроводження. Переглядаємо права при зміні завдань і за підсумками розборів — контур не повинен розростатися сам.
Артефакти впровадження: конфігурації, політики доступу, регламенти
Впровадження вважаємо завершеним не тоді, коли агенти відповідають на тестових запитах, а коли замовник керує ними без нас. Тому передаємо не презентацію, а робочий контур: описи конфігурацій, матрицю прав та інструкції, за якими чергова зміна діє самостійно.
Конфігурації, доступи та схеми інтеграцій
- Опис конфігурації кожного агента: обрана модель, обмеження за обсягом відповіді, ліміти ресурсів, перелік доступних інструментів — файлами в репозиторії замовника з історією змін.
- Матриця прав: які корпоративні системи агент читає, куди пише, де працює лише в режимі пропозиції та потребує підтвердження людини.
- Схеми інтеграцій: рух даних між агентом, внутрішніми системами та зовнішніми сервісами, з точками знеособлення персональних даних.
- Правила зберігання ключів і порядок їхньої планової заміни, окремо від коду та конфігурацій.
Журналювання та регламенти експлуатації
- Єдиний журнал дій: запит, версія конфігурації, викликані інструменти, результат, ідентифікатор співробітника — із захистом записів від правки та заданим терміном зберігання.
- Інструкція при інциденті: як вимкнути агента, відкотити конфігурацію на попередню версію, кого повідомляють і в який термін.
- Порядок додавання нових агентів: обов’язкова перевірка в ізольованому контурі, критерії допуску в продуктивне середовище.
- Регламент планового перегляду прав і версій моделей із зазначенням відповідальних.
Такі артефакти живуть у контурі замовника й залишаються робочими, навіть якщо склад команди змінюється: будь-який інженер піднімає агента, звіряє права та відтворює поведінку системи за документами, а не з пам’яті.
Кейс: як ізоляція агентів прибрала клас відмов
Агенти замовника — сервісна компанія з десятком автоматизованих сценаріїв — працювали під одним сервісним обліковим записом із широкими правами на внутрішні системи.
За квартал розібрали 14 інцидентів, де агент виходив за межі сценарію: змінював не ті записи, надсилав листи не тим адресатам, звертався до сервісу, до якого його не підключали. Гасили кожен випадок вручну й цілком по контуру — у середньому 40 хвилин простою сусідніх сценаріїв.
Що змінили і що це дало
Кожен сценарій переїхав в окреме оточення зі своїм набором прав і мережевим доступом строго за переліченими в конфігурації адресами, усе інше закрито політиками.
Зовнішні виклики йдуть через проксі з журналом «хто, куди, з якими параметрами» — на Kubernetes це окремий простір імен на сценарій. Перед випуском конфігурацію перевіряє рев’юер: якщо сценарію не потрібен доступ до бази клієнтів, він його не отримає навіть на прохання автора.
Доступи тепер видаються заявкою з обмеженим терміном: токен живе до завершення завдання й відкликається автоматично. Новий доступ узгоджується за шаблоном — відповідальний за безпеку бачить, які дані зачіпає запит, і відповідає того ж дня, а не через тиждень листування.
Частка запусків із зайвими діями агента впала з 18% до 0,3%, інцидентів за квартал стало один замість 14, і той виявився хибним спрацюванням. Зупинка сценарію займає 20 секунд: гасимо один агент, решта продовжують роботу.
Узгодження нового доступу — чотири години замість п’яти робочих днів, бо рішення ухвалюється за готовим шаблоном прав.
Клас відмов, через який агент міг зачепити чужий сервіс, зник: за межами свого оточення у сценарію немає прав. Друга людина потрібна лише на зміну самих прав — це єдина операція, де рішення ухвалюється вручну.
Що робити, якщо агенти вже працюють у спільному контурі?
Якщо агенти вже працюють у продуктивних сценаріях, зупиняти їх, щоб «перенести в ізольований контур», не можна: у них живі права, ключі доступу та зобов’язання перед суміжними системами.
Тому міграція агентів іде не перемиканням, а поетапним переходом: спочатку з’ясовуємо, чим саме ризикує спільний контур, і лише потім рухаємо по одному агенту.
Перший крок — інвентаризація. По кожному агенту фіксуємо, до яких даних і систем він звертається, які дії виконує необоротно, хто власник сценарію і що станеться, якщо доступ відкликати.
Часто вже тут видно, що частина прав агенту не потрібна: вони дісталися в спадок від сервісного облікового запису, під яким він запущений.
Далі агент піднімається в ізольованому контурі з урізаним набором дозволів і працює в режимі спостереження. Він отримує ті самі вхідні дані, але його рішення йдуть у журнал, а не в продуктив.
Це дає змогу порівняти поведінку старого й нового контуру на реальному потоці завдань, а не на тестовому наборі, і розібрати розбіжності до того, як вони стануть інцидентом.
Критерії готовності до перемикання формулюються заздалегідь і вимірно: частка збіжних рішень, відсутність відмов за правами, чи вкладається час відповіді у звичний коридор, чи перевірено повернення.
Саме перемикання — по одному агенту, з негайним відкликанням старого доступу: якщо залишити його «на всякий випадок», спільний контур залишається відкритим і сенс переходу втрачається.
Відкат теж готується заздалегідь — маршрут повертається на попередню схему, доступ відновлюється зі збереженої ролі, а не видається заново в поспіху.
Після перенесення в кожного агента з’являється власний обліковий запис, свій набір прав і короткий термін життя ключів, а всі виклики потрапляють у спільний журнал. Нові агенти заводяться одразу в ізольованому контурі, і спільний контур перестає бути місцем за замовчуванням.
Права, журналювання та відкати: технічні сумніви
Ці питання найчастіше виринають на етапі проєктування — їх ставлять інженери та служба безпеки, перш ніж узгодити доступ агентів до робочих систем. Нижче — відповіді про механіку: як обмежуються права, що потрапляє в журнал і як відкотити дію, якщо агент помилився.
Як видаються права, якщо агент працює з робочими системами?
Не користувачу, а окремому завданню: вузький набір операцій та об’єктів, термін життя обмежений, усе інше відсікає проксі перед зовнішнім викликом. Агент запускається в ізольованому оточенні, а операції, що змінюють дані, проходять окреме підтвердження й не змішуються з читанням.
Чи достатньо журналу, щоб розібрати хід рішення?
Журнал пишеться лише на додавання: вхід, викликаний інструмент, параметри, відповідь, версія інструкцій. Запис не можна переписати — правка ламає контрольну суму і видна під час аудиту. За журналом збирається причинний ланцюжок до конкретної дії агента.
Що робити, якщо агент вніс неправильну зміну?
Відкат закладається в дизайн: правки йдуть транзакційно, зі зворотною операцією, а перед масовими змінами знімається знімок цільового набору. Відкат запускається за ідентифікатором транзакції й займає хвилини, а не нічне відновлення з резервної копії.
Як перевіряється, що доступи не роздавалися зайвим?
Журналюються не лише дії агента, а й видача прав: хто розширив доступ, на який термін і під яке завдання. Аудит зводить це з журналом викликів — видно, який доступ реально використовувався. Прострочені дозволи відкликаються автоматично.
Обговоримо ваше завдання: з чого починаємо роботу
Перша розмова — не презентація, а розбір вашого контуру: які AI-виконавці вже працюють, до яких систем мають доступ і де зараз немає меж між ними. Щоб обговорити завдання предметно, а не в загальних словах, потрібен мінімум ввідних.
- Карта ландшафту: моделі та їхнє розміщення (зовнішній провайдер або ваш контур), середовище виконання, оркестратор, черги завдань.
- Ролі та права: хто з агентів що викликає, до яких баз, файлових сховищ і внутрішніх сервісів звертається.
- Межі допустимого: сценарії автономної роботи й точки, де обов’язкове підтвердження людини.
- Вимоги безпеки: що логується, скільки зберігається, які дані не залишають контур.
- Точки інтеграції: інтерфейси, сервісні облікові записи, мережі та сегменти, якими йде трафік.
- Спостережувані інциденти: випадки, коли агент вийшов за межі ролі або отримав зайвий доступ.
- Критерії приймання: за якими перевірками ви зрозумієте, що ізоляція та розмежування прав працюють.
За підсумками обговорення надсилаємо план робіт: схему ролей і політик доступу, етапи винесення агентів в ізольовані середовища та пісочниці, оцінку впровадження за строками й складом команди, перелік ризиків і порядок відкату. Опишіть завдання — повернемося з оцінкою та планом, а не із загальними обіцянками.
