Як безпечно запускати AI-агентів: ізоляція, секрети та контроль мережі

Один робочий день із дуже швидким стажером

AI-агент схожий на дуже швидкого стажера з доступом до термінала. Він може за хвилини знайти файл, запустити тести, поставити залежність, змінити код і відкрити запит до API. Але якщо такому стажеру одразу дати домашню директорію, production-токени й необмежений інтернет, проблема вже не в AI, а в наших правилах доступу.

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

09:30. Агент запускається просто на ноутбуці

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

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

10:15. Робочий простір стає одноразовим

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

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

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

11:40. Мережа закрита, доки її не відкрили явно

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

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

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

13:00. Секрети не лежать на столі

Секрети — найделікатніша частина. Вони можуть бути не лише у коді. GitHub у своєму матеріалі про secret scanning показує, що секрети трапляються в зверненнях підтримки, звітах про вразливості, нотатках інцидентів і wiki-сторінках. Для AI-агента це означає: не варто думати, що ризик обмежений файлом .env.

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

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

15:20. Людина лишається воротарем для небезпечних дій

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

Добра політика описує класи дій. Зелені дії виконуються без підтвердження. Жовті дії вимагають короткого пояснення агента і згоди людини. Червоні дії заборонені або доступні тільки в окремому середовищі. Це не бюрократія, а спосіб не перетворити AI-агента на процес із правами адміністратора.

Фінальна політика запуску

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

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

Джерела

• Docker: Why AI Agents Need Isolation — https://www.docker.com/blog/why-ai-agents-need-isolation/
• GitHub: How GitHub used secret scanning to reach inbox zero — https://github.blog/security/application-security/how-github-used-secret-scanning-to-reach-inbox-zero/