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

Агент у терміналі виглядає як колега, але діє як процес

Звична сцена: ви відкриваєте репозиторій, просите ШІ-агента виправити тест, і він упевнено пропонує план. Спочатку все виглядає як розмова з розумним колегою: подивитися файл, змінити функцію, встановити пакет, запустити перевірки. Але технічно це не колега. Це процес, який отримує доступ до файлової системи, командного рядка, мережі й іноді до секретів.

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

Крок перший: агент хоче змінити код

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

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

Анти-патерн тут — запускати агента в репозиторії з брудним робочим станом і потім намагатися зрозуміти, які зміни ваші, а які згенеровані. Перед стартом краще або зберегти свої зміни окремо, або створити одноразове середовище з чистою копією.

Крок другий: агент просить встановити пакет

Команда встановлення залежностей уже значно ризикованіша. Вона може змінити lockfile, виконати postinstall-скрипти, звернутися до мережі й додати код, який ви не переглядали. Якщо агент каже: “поставимо маленьку бібліотеку, так буде швидше”, це не обов’язково погано. Але це вже не просто редагування файлу.

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

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

Крок третій: агент запускає тести й команди

Тести здаються безпечними, бо команда виглядає знайомо: npm test, pytest, go test. Але тестовий набір теж може писати у файлову систему, відкривати порти, створювати базу, ходити в мережу або виконувати скрипти менеджера пакетів. Для звичайного проєкту це нормально. Для ШІ-агента питання в іншому: чи розумієте ви, яку саме команду він запускає і які права вона має.

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

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

Анти-патерни, які швидко стають дорогими

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

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

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

Модель рішення: де запускати дію

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

Це не про паніку і не про заборону ШІ-інструментів. Навпаки: чим краще визначені межі, тим спокійніше можна делегувати рутинну роботу. Агент може бути швидким помічником, але запускати його треба як непевний код із доступом до реальних ресурсів.

Джерела

• Docker Blog: Why AI Agents Need Isolation