Сцена: «просто запусти тести»
Уявімо звичайний робочий ранок. Розробник відкриває проєкт, бачить падіння тесту й просить AI-агента: «подивись, що не так, запусти тести та запропонуй виправлення». На перший погляд це дрібне доручення. Агент не деплоїть застосунок, не відкриває production-консоль і не має окремого облікового запису адміністратора.
Але за кілька хвилин він уже читає код, дивиться конфігурації, запускає команди, може встановити пакет, звернутися до API або відкрити файл із локальними змінними середовища. Він працює в тому самому середовищі виконання, де працює людина. Саме тому ноутбук розробника перестає бути просто приватним робочим місцем. Для AI-агента це справжня операційна зона з файлами, секретами, мережевими доступами й історією команд.
Питання не в тому, що AI-агенти небезпечні самі по собі. Питання в тому, що ми часто даємо їм ключі від майстерні, не описавши правила роботи.
Епізод 1. Агент читає репозиторій
Перший крок майже завжди виглядає безпечним: агент переглядає файли. Він шукає тест, помилку, пов’язаний модуль, конфігурацію запуску. Тут з’являється перша межа довіри. У репозиторії можуть бути не лише вихідні файли, а й локальні налаштування, приклади ключів, приватні нотатки, тимчасові дампи або файли, які випадково не потрапили до .gitignore.
Операційна перевірка проста: перед тим як дозволяти агенту читати всю теку, подивіться, що в ній лежить. Чи немає поруч файлів .env, експортів бази, приватних сертифікатів, старих архівів? Якщо агенту треба виправити один модуль, не варто відкривати йому домашню теку або всі робочі проєкти.
Антипатерн: запускати агента з кореня всієї робочої директорії, де поруч лежать клієнтські репозиторії, особисті нотатки й службові ключі.
Кращий варіант: окрема робоча тека для конкретного завдання, мінімальний набір файлів і явне правило, які шляхи агент не має читати.
Епізод 2. Агент запускає команди
Далі агент пропонує: запустити тести, лінтер, збірку. Це корисно, бо він швидко перевіряє гіпотези. Але команда в терміналі — це вже не порада, а дія. Вона може створити файли, змінити кеш, запустити локальний сервер, прочитати змінні середовища або підключитися до зовнішнього сервісу.
Тут працює правило найменших привілеїв. Якщо завдання — перевірити unit-тест, агенту не потрібні права на зміну системних каталогів, доступ до production-кластера або постійні хмарні токени. Варто мати окремий профіль терміналу або контейнер, де немає зайвих облікових даних.
Практична межа: команди читання, локальні тести й форматування можна дозволяти ширше. Команди, які видаляють файли, змінюють права, працюють із мережею або запускають довгі скрипти, мають вимагати підтвердження.
Антипатерн: натискати approve для будь-якої команди, бо агент нібито краще знає, що робить.
Епізод 3. Агент ставить залежності
Після тестів агент може запропонувати встановити пакет або оновити залежність. Для початківця це виглядає як звичайна частина розробки. Насправді встановлення пакетів часто запускає додаткові скрипти, змінює lock-файли й тягне код з інтернету.
Огорожа тут має бути дуже конкретною. Перед встановленням варто перевірити назву пакета, джерело, версію, причину додавання й зміни у файлах залежностей. Якщо пакет потрібен тільки для експерименту, краще запускати це в ізоляції: контейнері, тимчасовій гілці або одноразовій робочій теці.
Антипатерн: дозволяти агенту встановлювати будь-які пакети, щоб швидше побачити зелений тест.
Кращий варіант: агент пояснює, навіщо потрібна залежність, які файли зміняться, які скрипти можуть виконатися, а людина підтверджує дію.
Епізод 4. Агент звертається назовні
Складніші агенти можуть викликати API, читати документацію, відкривати issue, створювати pull request або працювати з хмарними CLI. Тут локальний ноутбук особливо схожий на production-межу: на ньому вже є секрети, SSH-ключі, сесії браузера, токени реєстрів і доступи до тестових середовищ.
Добра практика — розділити зовнішні дії на рівні. Переглянути публічну документацію — низький ризик. Завантажити артефакт із внутрішнього сховища — середній ризик. Створити ключ, змінити інфраструктуру, опублікувати пакет або написати в зовнішню систему — високий ризик.
Для високого ризику потрібні короткоживучі токени, окремий обліковий запис або хоча б ручне підтвердження. Агент не має випадково використовувати ті самі секрети, якими розробник працює з реальними системами.
Епізод 5. Агент пропонує зміни
Наприкінці агент змінює код і просить прийняти патч. Це зручний момент для аудиторського сліду. Потрібно бачити не лише diff, а й шлях: які файли агент читав, які команди запускав, які мережеві запити робив, які помилки бачив.
GitHub у своєму changelog про enterprise-managed OpenTelemetry export для VS Code і CLI показує важливий напрям: команди хочуть керовано збирати події з IDE та CLI, налаштовувати експорт і контролювати вміст телеметрії. Це не означає, що кожній маленькій команді завтра потрібна складна платформа спостережуваності. Але сама ідея корисна: дії агента мають бути видимими.
Мінімальний варіант для початку — зберігати історію команд, лог відповідей агента, список змінених файлів і причину кожної зовнішньої дії.
Малий операційний порядок перед делегуванням
Перед фразою «виправ це сам» зробіть коротку паузу:
- Визначте робочу теку й заборонені шляхи.
- Приберіть зайві секрети з середовища виконання.
- Дайте агенту тільки ті доступи, які потрібні для задачі.
- Увімкніть підтвердження для встановлення пакетів, видалення файлів і мережевих дій.
- Запускайте ризикові експерименти в ізоляції.
- Переглядайте diff і журнал команд перед merge.
Docker у своєму матеріалі формулює ширший тренд: ноутбук розробника стає новою межею керування, бо саме там AI-агенти виконують реальні дії. Це не причина відмовлятися від агентів. Навпаки, зрозумілі межі довіри дозволяють делегувати їм більше, а не менше.
Без правил агент — це дуже швидкий колега з вашими ключами. З правилами — корисний виконавець у контрольованій майстерні.
Джерела
Короткий чеклист
- перелічити локальні секрети, до яких може дістатися агент
- розділити дії агента на безпечні, умовні та заборонені
- запускати ризикові задачі в окремій робочій теці або контейнері
- вимагати підтвердження перед мережевими запитами, встановленням пакетів і змінами поза репозиторієм
- зберігати журнал команд і змін, які виконав агент
Оціни межу довіри для AI-агента на ноутбуці
Ти допомагаєш мені безпечно використовувати AI-агента в локальному середовищі розробки. Спочатку постав до 7 уточнювальних питань про мою операційну систему, IDE або термінальний інструмент, репозиторії, секрети, доступи до хмари, тестові середовища та типові команди. Після моїх відповідей поверни результат у такому форматі: 1. Мапа доступів: які файли, команди, мережеві напрямки й облікові дані може зачепити агент. 2. Дії без підтвердження: що можна дозволити автоматично і чому. 3. Дії з підтвердженням: що агент має робити тільки після мого явного дозволу. 4. Заборонені дії: що не можна виконувати з локального ноутбука. 5. Мінімальний план ізоляції: окрема тека, профіль, контейнер або тимчасові токени. 6. Журнал перевірки: які події варто записувати для аудиторського сліду. Не пропонуй купувати конкретний продукт. Дай практичний список перевірок для початківця.