Безпека ШІ для програмування: як агента розробника обманули одним файлом і які правила ввести для команди та підрядників

Ваші розробники вже пишуть код із ШІ-агентами на зразок Codex, Claude Code чи Cursor, і робота йде швидше. Проте керівник зазвичай не знає, до чого агент має доступ, що може встановити або надіслати назовні і хто відповідає, якщо через інструмент у продукт потрапить шкідливий код або витечуть ключі. Тут дослідження минулого тижня перетворено на зрозумілі правила: безпека ШІ для програмування, де запускати агентів, які дозволи лишити, що вписати в договір із підрядником і що робити в перші 24 години після підозри на витік.

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

25 жовтня 2026 року BleepingComputer розповів про дослідження Forever Security. На комп’ютері одного з клієнтів агент для програмування спробував встановити шкідливий npm-пакет function-color. Слід привів до файлу AGENTS.md у теці «Завантаження», яка водночас була робочою текою агента. Агенти самі підхоплюють файли з інструкціями з тієї теки, де їх запущено, і виконують їх, тож підкинутий файл діє як команда. Такий файл може покласти в «Завантаження» навіть звичайна вебсторінка, бо Chrome, Edge і Firefox за замовчуванням зберігають завантажене саме туди.

Цифри лабораторні, а не дані про реальні атаки. З нешкідливим навантаженням, яке лише відкривало калькулятор, атака спрацювала на OpenAI Codex у 90% тестів, а шкідливий файл CLAUDE.md перенаправив трафік Claude Code і відкрив токен входу приблизно у 50% тестів. Дослідники наголошують, що латати тут нічого: агент, який виконує файл зі своєї теки, працює як задумано, тож захищатися доводиться бізнесу.

Чому це стосується не лише програмістів, а й власника

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

Український гайд теж ставить на перше місце мінімум доступу і кнопку «Стоп»: Мінцифри в п’яти правилах радить давати ШІ лише ті дані, які критично потрібні для задачі, і мати змогу миттєво його зупинити.

Шість правил для команди: теки, дозволи, пісочниця, доступи

1. Запускайте агентів лише в теці проєкту, а не в «Завантаженнях» і не в домашній теці. OpenAI й Anthropic радять тримати робочу область якомога вужчою.
2. Перш ніж агент виконає незнайомий AGENTS.md, CLAUDE.md чи файл правил, прочитайте його.
3. Лишайте ввімкненими запити підтвердження та пісочницю, а прапорці в обхід дозволів на кшталт –dangerously-skip-permissions забороніть.
4. Запускайте неперевірений код і нові залежності в ізольованому середовищі, наприклад у контейнері, а не на основній робочій машині.
5. Застосовуйте принцип найменших привілеїв: токени на одну задачу з коротким терміном життя, а ключі тримайте поза підказками й поза файлами, які агент може прочитати, зокрема ~/.ssh та хмарними обліковими даними.
6. Ведіть журнал того, що запускають агенти, і вимагайте перевірки людиною перед злиттям, викладанням і публікацією.

Той самий принцип для безпеки ШІ-асистентів для коду закріплено в пам’ятці OWASP щодо безпеки ШІ-агентів: мінімум прав для кожного інструмента, зовнішні дані вважають недовіреними, а ризикові дії потребують підтвердження людини.

Що прописати в договорі та ТЗ із підрядником, який використовує ШІ

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

Безпеки ШІ в розробці: пункти для договору

Пункт	Що вимагати
Інструменти	Іменований перелік ШІ-агентів і повідомлення до додавання нових
Середовище	Агенти працюють у теці проєкту або в пісочниці, не в домашній теці й не в «Завантаженнях»
Ваші секрети	Ваші ключі не вставляють у підказки, підрядник користується токенами з обмеженими правами й терміном
Залежності	Кожен новий пакет проходить перевірку, версії закріплені, lock-файл лежить у репозиторії
Перевірка	Кожне злиття дивиться людина, результат агента не викладають наосліп
Інциденти	Повідомлення в узгоджений строк, зміна ключів і письмовий розбір

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

Ключі, токени й пакети: як перевірити ланцюжок постачання коду

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

• нові залежності проходять такий самий перегляд, як код;
• інсталяційні скрипти не запускаються на основній машині;
• секрети лежать у сховищі, а не у файлах .env поруч із кодом;
• токени доступу живуть хвилини чи години, а не місяці;
• у CI видно, хто підтвердив кожен реліз.

Якщо підозрюєте компрометацію: план на перші 24 години

1. Зупиніть агента й відключіть машину від мережі.
2. Відкличте та змініть усі токени, до яких агент міг дотягнутися: репозиторій, npm, хмара і власний вхід агента.
3. Складіть перелік пакетів, які встановлено, і файлів, які змінено від початку сесії.
4. Перевірте журнали CI та нещодавні злиття на зміни, про які ніхто не пам’ятає.
5. Повідомте підрядника, а якщо під загрозою дані, то й клієнтів, і запишіть, що сталося.

Такий сценарій заздалегідь налаштовують послуги DevOps і безпеки від LinkAgency. Prompt injection може трапитися будь-якого дня, тому план має існувати до першого інциденту.

Як упровадити ШІ в розробку без заборони й зайвих ризиків

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