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

Сценарій: швидкий стажер із доступом до термінала

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

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

Крок 1. Агент тільки читає код

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

Типова помилка — запускати агента з кореня особистої машини, де поруч із кодом є старі архіви, конфігурації, SSH-ключі й локальні нотатки. Кращий контроль — окремий workspace із потрібним репозиторієм. Якщо задача не потребує змін, підключіть файли в режимі read-only. Це не ідеальна безпека, але добрий перший бар’єр.

Крок 2. Агент запускає команди

Коли агент отримує право виконувати shell-команди, ризик різко зростає. Команда для тестів може бути нормальною, а команда для очищення директорії — руйнівною. Скрипти в репозиторії теж можуть робити більше, ніж очікує користувач.

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

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

Крок 3. Агент ставить залежності

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

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

Крок 4. Агент отримує токен до API

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

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

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

Крок 5. Агент працює з мережею та CI

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

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

Мінімальна модель запуску

Для локальної задачі достатньо почати з окремого workspace, режиму read-only там, де можливо, контейнера для команд, обмеженої мережі й короткого журналу дій. Для неперевіреного коду, інсталяції залежностей або доступу до API потрібна сильніша ізоляція, наприклад microVM або керована пісочниця.

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

Джерела

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