AI-агент із shell-доступом: як перевести workflow в ізольований режим

Почніть із побутового правила доступу

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

Поки AI лише пропонує фрагмент коду в чаті, ризик обмежений тим, що людина скопіює й запустить. Але coding agent із shell-доступом уже діє в середовищі. Він може виконати npm install, змінити файли, зчитати змінні середовища, запустити тести, зробити HTTP-запит або випадково зачепити не той каталог. Це вже не підказка, а операційний workflow.

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

Намалюйте карту ризиків за зонами

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

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

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

Четверта зона — секрети. GitHub у своєму матеріалі про secret scanning показує знайому проблему: секрети розповзаються не лише по репозиторіях, а й по тікетах, wiki, інцидентних нотатках і звітах. Якщо такі дані є на машині або в CI, AI-агент не має отримувати їх автоматично.

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

Цільова схема: агент у маленькій лабораторії

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

Далі додайте пісочницю. Це може бути контейнер, ізольоване середовище CI або microVM-підхід. Важливий не бренд інструмента, а властивості: обмежений доступ до host-системи, контрольовані mount-и, зрозумілі права на запис, відсутність доступу до домашньої директорії та системних сокетів без явної потреби.

Мережу краще будувати від заборони до дозволу. Спершу вимкніть зайвий вихідний мережевий трафік, потім додайте allowlist: package registry, внутрішній тестовий API, документація або mock-сервіси. Якщо агенту потрібен доступ до стороннього API, краще дати йому проксі з обмеженими операціями, а не повний ключ.

Секрети не мають лежати в середовищі агента просто тому, що так зручно. Для локальної роботи використовуйте тестові токени або короткоживучі доступи. Для CI — окремий набір credentials з мінімальними правами. Для production-like задач — ручне підтвердження й окремий шлях видачі доступу.

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

Поступове впровадження для команди

Почніть локально. Забороніть запуск AI-агента з повним доступом до ноутбука. Створіть шаблон: новий робочий простір, обмежені каталоги, тестові секрети, мережевий allowlist, лог команд. Додайте правило: людина переглядає diff перед merge або застосуванням змін до основної гілки.

Другий етап — CI. Агент у CI має працювати як окремий job з мінімальними правами. Він не повинен автоматично отримувати всі секрети pipeline. Якщо потрібно відкрити pull request, створити issue або викликати API, використовуйте токен із вузькими правами й коротким життям.

Третій етап — production-like задачі. Тут агент може аналізувати логи, готувати команди, писати migration draft або пропонувати rollback-план. Але виконання дій, які змінюють дані, інфраструктуру або доступи, має проходити через ручне підтвердження.

Де зупинити агента й покликати людину

Ручне підтвердження потрібне, коли агент хоче видаляти багато файлів, змінювати lock-файли, встановлювати нові залежності, редагувати CI-конфігурацію, читати змінні середовища, відкривати новий мережевий напрям або працювати з production-like ресурсами.

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

Безпечний AI-workflow не означає недовіру до AI. Це нормальна інженерна межа: автоматизація працює швидше, коли її зона дії зрозуміла, відтворювана й обмежена.

Джерела

• 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/