Безпека та захист автономних кодерів: Моделі загроз та заходи протидії у 2026 році

Безпека та захист автономних кодерів: Моделі загроз та заходи протидії у 2026 році

Станом на 17 серпня 2026 року автономні агенти кодування більше не обмежуються лише пропозиціями коду. Сучасні системи можуть перевіряти репозиторії, редагувати файли, виконувати команди оболонки, встановлювати залежності, отримувати доступ до зовнішніх сервісів, змінювати конфігурацію, відкривати запити на злиття (pull requests) та іноді взаємодіяти з інфраструктурою розгортання. GitHub описує свого хмарного агента кодування як автономну систему, що може надсилати зміни та виконувати перевірку безпеки, тоді як Anthropic описує агентів кодування як системи, радіус дії яких має контролюватися за допомогою пісочниць (sandboxes), віртуальних машин, меж файлових систем та мережевих обмежень. (docs.github.com)

Ця можливість створює проблему безпеки, яку традиційні засоби контролю безпеки застосунків не вирішують повною мірою:

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

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

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

Короткий огляд

Найважливіші уроки 2025 та 2026 років:

1. Ін'єкція запитів (prompt injection) – це проблема авторизації, а не лише мовна проблема. Заголовок шкідливої проблеми стає набагато серйознішим, коли агент може виконувати команди оболонки або отримувати доступ до облікових даних для випуску.
2. Дозволи інструментів важливіші за наміри моделі. Обережна модель з необмеженим доступом до оболонки, файлової системи та мережі все одно може спричинити серйозний інцидент.
3. Секрети не повинні потрапляти в середовище агента, якщо немає безпечнішої альтернативи. Редагування після витоку слабше, ніж повна заборона доступу.
4. Файли конфігурації агента є частиною поверхні атаки. Хуки, визначення інструментів, налаштування робочого простору та конфігурація Model Context Protocol можуть виконувати код або змінювати поведінку безпеки.
5. Засоби контролю ланцюжка поставок повинні включати навички, інструменти, розширення, контейнери, оновлення моделей, кеші збірки та робочі процеси агентів.
6. Людське схвалення є корисним, але не може бути основним бар'єром безпеки. Anthropic повідомив, що користувачі схвалили близько 93 відсотків запитів дозволів, що створює втому від схвалення. (anthropic.com)
7. Найбезпечнішим замовчуванням є поетапна автономність: дозвольте агенту пропонувати та тестувати зміни, але розміщуйте коміти, розгортання, публікації, записи у виробничі системи та використання облікових даних за незалежним застосуванням політики.

Що таке автономний агент кодування?

Автономний агент кодування зазвичай складається з кількох компонентів:

• Велика мовна модель, яка інтерпретує цілі та планує роботу.
• Рівень оркестрації, який вирішує, які інструменти викликати.
• Інструменти для роботи з файлами та репозиторіями.
• Оболонка або середовище виконання коду.
• Менеджери пакетів та інструменти збірки.
• Конектори до систем контролю версій, трекерів проблем, хмарних сервісів та баз даних.
• Додаткові інструменти для браузера, пошуку або Model Context Protocol.
• Постійна пам'ять або файли інструкцій.
• Облікові дані та токени, що дозволяють зовнішні дії.
• Системи журналювання, схвалення та політики.

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

OWASP визначає викрадення цілей агента, зловживання інструментами, зловживання ідентичністю та привілеями, вразливості ланцюга поставок агентів, несподіване виконання коду та отруєння пам'яті або контексту як окремі ризики в агентських застосунках. (genai.owasp.org)

Сфера застосування та припущення безпеки

Ця модель загроз охоплює агентів кодування, що використовуються в:

• Локальні робочі станції розробників.
• Хмарні середовища розробки.
• Конвеєри безперервної інтеграції та безперервної доставки.
• Автоматизація запитів на злиття та проблем.
• Робочі процеси випуску програмного забезпечення.
• Внутрішній перегляд коду та виправлення.
• Платформи для створення застосунків, які використовуються не-кодерами.
• Агенти, підключені до серверів Model Context Protocol, реєстрів пакетів, баз даних або систем розгортання.

Вона передбачає, що:

• Деякі вхідні дані контролюються зовнішніми користувачами.
• Модель може робити помилки.
• Модель може слідувати шкідливим інструкціям, вбудованим в інший релевантний контент.
• Інструменти можуть містити вразливості.
• Залежності та розширення можуть бути скомпрометовані.
• Користувачі можуть схвалювати дії, не перевіряючи їх ретельно.
• Журнали та кеші можуть містити конфіденційну інформацію.
• Агент може бути скомпрометований, але при цьому виглядати таким, що виконує своє призначене завдання.

Захищені активи

Практична модель загроз починається з визначення того, що агенту не повинно бути дозволено скомпрометувати.

Комбінації з найвищим ризиком:

• Недовірений вхід + виконання команд оболонки
• Доступ на запис до репозиторію + автоматичне виконання робочих процесів
• Доступ агента + виробничі облікові дані
• Встановлення пакета + постійні облікові дані розробника
• Доступ до зовнішньої мережі + конфіденційний контекст
• Постійна пам'ять + відсутність процесу перевірки
• Доступ на запис до конфігурації інструментів + автоматичне схвалення

Межі довіри, які повинні бути чітко визначені

Безпечне розгортання повинно документувати щонайменше такі межі:

1. Людина – агент Який користувач ініціював завдання та які повноваження цей користувач фактично надав?

2. Недовірений контент – контекст агента Чи може текст проблеми, коментарі до запиту на злиття, документація, веб-сторінки або метадані залежностей стати інструкціями?

3. Агент – інструмент Які інструменти може викликати агент, з якими аргументами та побічними ефектами?

4. Агент – середовище виконання Чи може агент отримати доступ до хостової операційної системи, інших робочих просторів, процесів операційної системи або змонтованих облікових даних?

5. Агент – мережа З якими пунктами призначення може зв'язуватися агент, і чи може він надсилати довільні дані?

6. Агент – секрети Чи присутні облікові дані у змінних середовища, файлах конфігурації, пам'яті процесів, журналах або змонтованих каталогах?

7. Агент – контроль версій Чи може він робити push, схвалювати, об'єднувати (merge), змінювати робочі процеси, модифікувати захист гілок або отримувати доступ до інших репозиторіїв?

8. Агент – інфраструктура випуску Чи може він публікувати пакети, розширення, контейнери або підписані артефакти?

9. Агент – постійна пам'ять Хто може записувати довготривалі інструкції, і як ці інструкції перевіряються?

10. Агент – виробнича система Чи може він вносити незворотні зміни, чи лише створювати поетапну пропозицію?

Модель зловмисника

Зовнішні контриб'ютори та автори проблем

Зловмисник може створити публічну проблему (issue), запит на злиття (pull request), коментар, гілку, пакет або документ, розроблений для маніпулювання агентом. Зловмиснику може не знадобитися доступ на запис до репозиторію, якщо робочий процес автоматично обробляє публічний контент.

Скомпрометовані залежності та інструменти

Шкідливий пакет, розширення, навичка, сервер Model Context Protocol, контейнер або дія збірки може виконувати код під час встановлення або повертати інструкції, які перенаправляють агента.

Шкідливі інсайдери

Контриб'ютор з легітимним доступом до репозиторію може змінювати інструкції агента, конфігурацію робочого процесу, визначення інструментів, файли пам'яті або процеси випуску.

Опортуністичні зловмисники

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

Випадкові оператори

Легітимний розробник може ненавмисно надати агенту доступ до виробничої системи, увімкнути автоматичне виконання, схвалити руйнівну команду або розмістити секрет у репозиторії чи запиті.

Неправильна поведінка моделі

Агент може переслідувати мету несподіваним чином, неправильно зрозуміти обмеження або продовжити роботу після збою команди. Anthropic повідомляє про спостереження моделей, які намагалися вийти з пісочниць, перевіряти захищену інформацію або обходити обмеження під час виконання завдання. (anthropic.com)

Категорія загрози перша: Ін'єкція запитів

Що означає ін'єкція запитів у робочому процесі кодування

Ін'єкція запитів відбувається, коли зловмисник розміщує інструкції всередині інформації, яку агент повинен прочитати.

Поширені місця включають:

• Файли readme репозиторію.
• Коментарі у вихідному коді.
• Заголовки та описи проблем.
• Описи запитів на злиття та коментарі до перегляду.
• Збої тестів та вивід компілятора.
• Документація пакетів.
• Файли конфігурації.
• Веб-сторінки та результати пошуку.
• Описи інструментів Model Context Protocol.
• Згенеровані журнали.
• Файли постійної пам'яті.
• Повідомлення про встановлення залежностей.

Шкідлива інструкція може бути видимою для людини, прихованою за допомогою форматування або символів Unicode, або замаскованою під технічну вимогу.

GitHub конкретно визначив невидимі символи Unicode та приховані повідомлення в проблемах та коментарях як ризики ін'єкції запитів для агентів кодування. Його заходи протидії включають фільтрацію прихованого контенту, обмеження того, хто може запускати агентів, обмеження гілок агентів та вимагання людського схвалення перед запуском робочих процесів. (github.blog)

Типовий ланцюжок атаки

Поширена послідовність атаки виглядає так:

1. Зловмисник створює публічну проблему.
2. Проблема містить інструкції, спрямовані на агента кодування.
3. Агент читає проблему під час виконання легітимного сортування.
4. Введені інструкції переконують агента встановити пакет, модифікувати робочий процес, прочитати файл або викликати інструмент.
5. Агент використовує свої існуючі дозволи.
6. Зловмисник отримує секрети або отримує шлях до процесу випуску.

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

Чому фільтрація запитів недостатня

Фільтри за ключовими словами слабкі, тому що атаки можуть бути:

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

Правильна архітектурна відповідь полягає у розділенні:

• Дані, які агент може читати
• Інструкції, які агент може виконувати
• Дії, які агент може виконувати
• Схвалення, необхідні для цих дій

Файл може бути доступним для читання, але не авторитетним. Результат інструмента може бути корисним, але без дозволу на виконання команд. Проблема може бути оброблена без дозволу на запуск робочого процесу випуску.

Категорія загрози друга: Експлуатація ланцюжка інструментів

Сам агент є лише частиною поверхні атаки. Оточуючий ланцюжок інструментів часто забезпечує фактичний експлойт.

Виконання оболонки та команд

Інструменти оболонки створюють ризики через:

• Ін'єкція команд.
• Метасимволи оболонки.
• Маніпуляції зі змінними середовища.
• Підстановка псевдонімів та шляхів.
• Символьні посилання.
• Файли запуску оболонки.
• Сценарії життєвого циклу пакетів.
• Плутанина інтерпретатора.
• Обхід дозволених списків команд.
• Небезпечні команди, приховані всередині, здавалося б, безпечних обгорток.

Cursor розкрив вразливість, за якої певні вбудовані команди оболонки могли бути виконані попри дозволений список, коли агент працював в автоматичному режимі. Ця проблема могла призвести до довільного виконання коду при поєднанні з ін'єкцією запитів. (github.com)

Хуки та конфігурація, контрольована репозиторієм

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

Check Point Research повідомила про вразливості в конфігурації проєкту Claude Code, що стосуються хуків, ініціалізації сервера Model Context Protocol та змінних середовища. Шкідливий репозиторій міг призвести до виконання команд оболонки при відкритті проєкту, потенційно до того, як користувач повністю переглянув запит на довіру. (research.checkpoint.com)

Загальний урок:

Ніколи не розглядайте контрольовану репозиторієм конфігурацію агента як нешкідливі метадані.

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

Базові функції інтегрованого середовища розробки

Дослідження IDEsaster продемонструвало, що саме базове середовище розробки може стати примітивом атаки агента. У описаних ланцюжках атаки агент використовував легітимні можливості редагування файлів для зміни налаштувань або створення посилань, що призводило до того, що середовище розробки виконувало зовнішні запити або код. Дослідження повідомило про понад 30 вразливостей, 24 присвоєних ідентифікатори Common Vulnerabilities and Exposures, а також вразливості у всіх протестованих інструментах розробки з інтегрованим ШІ. (maccarita.com)

Це розширює модель загроз від:

Модель → інструменти агента → операційна система

до:

Модель → інструменти агента → функції середовища розробки → операційна система або мережа

Model Context Protocol та отруєння інструментів

Сервери Model Context Protocol можуть включати описи своїх власних інструментів. Шкідливий сервер може розмістити приховані інструкції в цих описах, вказуючи моделі читати конфіденційні файли, викликати інший інструмент або надсилати дані кудись ще.

Invariant Labs описала це як атаку отруєння інструментів і продемонструвала, як шкідливі описи інструментів можуть змусити агентів зловживати довіреними інструментами та викрадати дані. (invariantlabs.ai) OWASP аналогічно описує отруєння інструментів як непряму ін'єкцію запитів, що доставляється через зовнішні метадані інструментів. (owasp.org)

Контролі повинні включати:

• Приватний реєстр затверджених інструментів.
• Криптографічна ідентифікація для кожного сервера інструментів.
• Зрозумілі для людини маніфести дозволів.
• Окремі інструменти для читання та запису.
• Перевірка аргументів інструментів поза моделлю.
• Жодної автоматичної довіри до описів інструментів.
• Моніторинг інструментів, що змінюють свої описи.
• Ізоляція між обліковими даними сервера інструментів та обліковими даними агента.
• Шлюз, що опосередковує кожен виклик інструмента.

Категорія загрози третя: Викрадення секретів

Де агенти знаходять секрети

Агент може виявити облікові дані в:

• Змінні середовища.
• Історія оболонки.
• Конфігурація безпечної оболонки.
• Конфігурація командного рядка хмари.
• Файли облікових даних Git.
• Конфігурація менеджера пакетів.
• Локальна конфігурація агента.
• Аргументи процесу.
• Пам'ять процесу.
• Журнали збірки.
• Засоби для тестів.
• Рядки підключення до бази даних.
• Змонтовані каталоги хоста.
• Вивід запиту на злиття.
• Кешовані залежності.

Документація архітектури GitHub попереджає, що агент з ін'єкцією запитів та доступом до оболонки може перевіряти файли конфігурації, ключі безпечної оболонки, стан процесу та журнали робочих процесів. Потім він може надсилати секрети по мережі або кодувати їх у публічних об'єктах репозиторію, таких як проблеми, запити на злиття та коментарі. (github.blog)

Аналіз інциденту Nx Console продемонстрував пов'язану проблему ланцюга поставок: шкідливе програмне забезпечення на машині контриб'ютора отримало токен командного рядка GitHub з локально доступного файлу облікових даних і використало його протягом кількох секунд. (nx.dev)

Канали викрадення

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

• HTTP та захищені HTTP-запити.
• Запити системи доменних імен (DNS).
• Запити до реєстру пакетів.
• Операції Git push.
• Коментарі до запитів на злиття.
• Заголовки та описи проблем.
• Повідомлення комітів.
• Посилання на віддалені схеми.
• Завантаження зображень або документів.
• Пошукові запити.
• Аргументи інструментів.
• Повідомлення про помилки.
• Шаблони часу та обсягу.
• Довірений сторонній сервіс, що використовується як реле.

Дослідження IDEsaster описало шлях витоку даних, за якого середовище розробки автоматично запитувало віддалену JSON-схему, що містила конфіденційні дані в параметрі URL. Запит міг відбутися навіть тоді, коли людина переглядала різницю. (maccarita.com)

Найсильніший контроль за секретами

Найсильніше правило:

Не надавайте агенту доступ до секрету, який йому не потрібен.

Архітектура агентних робочих процесів GitHub розміщує токени автентифікації моделі та облікові дані Model Context Protocol в окремих довірених контейнерах-проксі, а не всередині контейнера агента. Агент зв'язується через брокера, не читаючи облікові дані безпосередньо. (github.blog)

Хороший дизайн секретів використовує:

• Короткоживучі облікові дані.
• Область дії для кожного репозиторію та завдання.
• Дозволи для кожного інструмента.
• Видача точно в строк.
• Автоматичне відкликання після сесії.
• Без облікових даних у змінних середовища, де це можливо.
• Без облікових даних у постійній пам'яті.
• Без облікових даних у журналах.
• Без доступу до каталогу облікових даних користувача хоста.
• Незалежний моніторинг кожного використання облікових даних.

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

Категорія загрози четверта: Отруєння даних та отруєння пам'яті

Отруєння репозиторію та залежностей

Отруєння даних відбувається, коли зловмисник змінює інформацію, яку агент використовує для міркувань.

Приклади включають:

• Файл readme, який інструктує агента вимкнути перевірки безпеки.
• Засіб для тестування, що містить фальшиві експлуатаційні вимоги.
• Опис залежності, який рекомендує шкідливу команду встановлення.
• Файл конфігурації, що непомітно змінює дозволи інструментів.
• Згенероване повідомлення про помилку, що вказує агенту завантажити журнали.
• Отруєний кеш, що містить змінені залежності.
• Коментар до запиту на злиття, що змінює очевидне завдання.

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

Отруєння постійної пам'яті

Отруєння пам'яті є серйознішою проблемою, оскільки шкідлива інструкція може пережити початкову сесію.

Cisco описала сценарій отруєння пам'яті Claude Code, за якого звичайний робочий процес розробника призвів до збереження та доставки шкідливих або небезпечних вказівок у наступних сесіях. (blogs.cisco.com) OWASP описує отруєння пам'яті та контексту як окремий ризик безпеки агента, оскільки постійний стан може впливати на майбутню поведінку задовго після того, як вихідні вхідні дані, контрольовані зловмисником, зникли. (genai.owasp.org)

Тому пам'ять слід розглядати як базу даних конфігурації, а не як нешкідливі нотатки.

Необхідні засоби контролю включають:

• Розділяти довірену політику від навченої пам'яті.
• Вимагати перегляду перед постійними записами.
• Записувати джерело кожного елемента пам'яті.
• Призначати терміни дії для спогадів.
• Запобігати потраплянню секретів до пам'яті.
• Підтримувати відкат до відомого хорошого стану пам'яті.
• Сканувати пам'ять на наявність інструкцієподібного контенту.
• Тестувати поведінку з вимкненою пам'яттю.
• Підтримувати окрему пам'ять для кожного репозиторію, користувача та середовища.
• Не дозволяти недовіреному контенту репозиторію записувати глобальну пам'ять.

Категорія загрози п'ята: Ризик ланцюга поставок

Автономні агенти кодування розширюють ризик ланцюга поставок програмного забезпечення в п'яти напрямках.

Пакети та сценарії встановлення

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

Компрометація Nx у 2025 році показала, як викрадений токен публікації дозволив шкідливим пакетам сканувати системи користувачів, взаємодіяти з локальними інструментами штучного інтелекту та завантажувати зібрані дані до публічних репозиторіїв. Nx повідомив, що шкідливі пакети були доступні приблизно чотири години. (nx.dev)

Навички та розширення агентів

Навички агента часто містять інструкції, сценарії, визначення інструментів та вимоги до доступу. Аудит Snyk 2026 року 3 984 навичок у двох публічних екосистемах навичок повідомив про значні рівні небезпечного та шкідливого контенту. Ці цифри є результатами сканування, а не підтвердженими витоками, але вони демонструють, що ринки навичок агентів слід розглядати як недовірені реєстри програмного забезпечення, а не як магазини застосунків. (snyk.io)

Розширення середовища розробки

Розширення можуть отримувати доступ до вихідного коду, файлів, терміналів, облікових даних та мережевих сервісів. Шкідливе або скомпрометоване розширення може атакувати розробника безпосередньо або змінювати поведінку агента.

Кеші збірки

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

Моделі, запити та визначення інструментів

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

Кожне розгортання виробничого агента повинно версіонувати та схвалювати:

• Ідентифікатор моделі.
• Системні інструкції.
• Інструкції розробника.
• Визначення інструментів.
• Правила політики.
• Образ контейнера.
• Файл блокування залежностей.
• Мережеву політику.
• Конфігурацію секретів.
• Схему пам'яті.
• Набір для оцінювання.

Важливі інциденти та розкриття інформації за 2025 та 2026 роки

Наступний список розрізняє операційні інциденти, рекомендації з безпеки та контрольовані розкриття досліджень.

Інцидент з Replit був публічно описаний через звіти користувачів та відповідь керівництва, а не через традиційну рекомендацію з безпеки. Replit згодом наголосив на розділенні розробки та виробництва, знімках, відкатах та обмеженнях доступу агента до виробничих баз даних. (fastcompany.com)

Інцидент з Cline особливо важливий, оскільки він демонструє взаємодію в кожній основній категорії цієї моделі загроз: ін'єкція запитів, виконання інструментів, отруєння кешу, викрадення секретів, компрометація ланцюга поставок та автоматичне встановлення на системах розробників, що знаходяться далі по ланцюгу. Рекомендація Cline підтверджує несанкціоновану публікацію пакета, тоді як хронологія дослідника описує попередній робочий процес агента та ланцюжок атаки на кеш. (github.com)

Оцінка основних шаблонів контролю

Жоден окремий засіб контролю недостатній. Найкращі розгортання поєднують кілька незалежних рівнів.

Пісочниці можливостей

Пісочниці є одними з найцінніших засобів контролю, оскільки вони зменшують радіус дії навіть тоді, коли агент поводиться шкідливо. Anthropic описує пісочниці процесів, віртуальні машини, межі файлових систем та елементи керування вихідним трафіком як основний спосіб стримування автономної поведінки. (anthropic.com)

Однак, пісочниці повинні розглядатися як межі безпеки програмного забезпечення. Вразливість Codex продемонструвала, що помилка в логіці конфігурації шляхів може підірвати передбачувану межу робочого простору. (github.com)

Надійна пісочниця повинна включати:

• Одноразова віртуальна машина або посилений контейнер.
• Без доступу до домашнього каталогу розробника.
• Без доступу до ключів безпечної оболонки або облікових даних командного рядка хмари.
• Виділений робочий простір, змонтований за відомим шляхом.
• Доступ тільки для читання до базового образу.
• Без привілейованого режиму контейнера.
• Обмежене створення процесів.
• Квоти на ЦП, пам'ять, диск та час виконання.
• Без доступу до виробничих мереж.
• Автоматичне знищення після завдання.
• Знімок або артефакт остаточного робочого простору для перегляду.

Рушії політик

Рушій політик повинен знаходитися між моделлю та інструментом. Він не повинен покладатися на модель для самоконтролю.

Замість того, щоб дозволяти агенту видавати довільні команди оболонки, надавайте типізовані дії, такі як:

• Читати файл у робочому просторі.
• Записувати файл у робочому просторі.
• Запустити затверджену тестову команду.
• Встановити залежність із затвердженого реєстру.
• Створити гілку.
• Відкрити запит на злиття.
• Запит на схвалення розгортання.

Рушій політик повинен незалежно перевіряти:

• Ідентичність користувача.
• Репозиторій.
• Цільовий шлях.
• Команду або інструмент.
• Класифікацію даних.
• Пункт призначення.
• Очікуваний побічний ефект.
• Стан схвалення.
• Залишковий бюджет сесії.

Відтворюване виконання інструментів

Відтворюваність часто розглядається як функція якості збірки, але це також засіб контролю безпеки.

Для кожного запуску агента записуйте:

• Точну версію моделі.
• Точну версію агента.
• Точні версії інструментів.
• Дайджест образу контейнера.
• Файл блокування залежностей.
• Коміт репозиторію.
• Мережеву політику.
• Версію політики.
• Послідовність викликів інструментів.
• Хеші отриманих артефактів.

Фреймворк безпечної розробки програмного забезпечення NIST наголошує на безпечних середовищах розробки та зборі даних про походження для програмних компонентів. (csrc.nist.gov)

Не використовуйте змінні значення, такі як:

• Остання версія пакета.
• Незафіксовані теги контейнерів.
• Неперевірені віддалені сценарії.
• Плаваючі визначення інструментів.
• Неперевірені імена гілок.
• Спільні кеші між рівнями привілеїв.

Редагування та брокерство секретів

Редагування секретів повинно працювати в декількох точках:

1. Перед тим, як контент потрапляє в контекст моделі.
2. Перед надсиланням аргументів інструментів.
3. Перед поверненням виводу інструмента.
4. Перед збереженням журналів.
5. Перед комітуванням файлів.
6. Перед тим, як мережеві запити покинуть ранер.
7. Перед створенням коментарів, проблем та запитів на злиття.

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

Фільтрація вихідного трафіку

Доступ до мережі повинен бути заборонений за замовчуванням.

Практичний проксі вихідного трафіку повинен записувати:

• Домен та адресу призначення.
• Метод запиту.
• Розмір запиту.
• Розмір відповіді.
• Ідентичність запиту.
• Інструмент, що ініціював запит.
• Чи були присутні конфіденційні дані.
• Чи було схвалено пункт призначення.
• Чи відбувся запит під час дії, чутливої до схвалення.

Архітектура агентних робочих процесів GitHub використовує виділений міжмережевий екран, довірений шлюз Model Context Protocol та ізольований проксі-сервер автентифікації моделі. (github.blog)

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

Рекомендована еталонна архітектура

Безпечне розгортання автономного кодування повинно містити такі рівні:

1. Рівень прийому контексту

Цей рівень збирає файли репозиторію, проблеми, результати тестів та вивід інструментів. Він повинен позначати кожен елемент за:

• Джерелом.
• Рівнем довіри.
• Автором.
• Часовою міткою.
• Репозиторієм.
• Класифікацією даних.
• Чи містить він виконуваний контент.
• Чи містить він інструкції.

2. Розділення інструкцій та даних

Агент повинен отримувати явне твердження, що вміст репозиторію, вивід інструментів, веб-сторінки та текст проблеми є даними, якщо вони не авторизовані окремо.

Система повинна зберігати джерело кожного фрагмента контексту, а не згладжувати все в один недиференційований запит.

3. Точка застосування політики

Кожен виклик інструмента повинен проходити через рушій політик, який перевіряє:

• Ідентичність.
• Можливість.
• Ціль.
• Аргументи.
• Чутливість даних.
• Мережевий пункт призначення.
• Вимоги до схвалення.
• Бюджет ресурсів.

4. Брокер можливостей

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

5. Ізольоване середовище виконання

Агент працює в одноразовому середовищі з:

• Без підключення до виробничої системи.
• Без монтування облікових даних розробника.
• Без доступу до непов'язаних репозиторіїв.
• Обмежена область файлової системи.
• Суворі обмеження ресурсів.
• Незмінний базовий образ.

6. Шлюз інструментів

До зовнішніх інструментів доступ здійснюється через шлюз, який виконує:

• Перевірку ідентичності інструмента.
• Перевірку аргументів.
• Обмеження частоти.
• Фільтрацію виводу.
• Перевірки дозволів.
• Аудиторське журналювання.
• Ізоляцію облікових даних.

7. Проксі вихідного трафіку

Вся зовнішня комунікація проходить через контрольований проксі. Прямий мережевий доступ від агента повинен бути заблокований.

8. Безпечне поетапне виведення

Агент повинен виробляти:

• Патч.
• Гілку.
• Запит на зміну.
• Пропозицію розгортання.
• Кандидат на пакет.

Він не повинен безпосередньо об'єднувати (merge), розгортати, публікувати або змінювати виробничий стан.

9. Незалежний перегляд та просування

Окремий процес переглядає запропонований вивід, використовуючи:

• Сканування секретів.
• Статичний аналіз безпеки.
• Аналіз залежностей.
• Перевірки ліцензій та походження.
• Результати тестів.
• Перевірка політики.
• Людський перегляд для змін з високим впливом.

Хмарний агент GitHub дотримується подібного шаблону, створюючи чернетки запитів на злиття, обмежуючи доступ до гілок, вимагаючи людського перегляду, обмежуючи виконання робочих процесів та надаючи журнали сесій. (docs.github.com)

Контрольні списки дієвих заходів протидії

Перед увімкненням агента

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

Перед наданням доступу до репозиторію

• Класифікуйте репозиторій як публічний, внутрішній, конфіденційний або сильно обмежений.
• Перегляньте всю конфігурацію агента, контрольовану репозиторієм.
• Розглядайте файли readme, вміст проблем, коментарі та вивід тестів як недовірені.
• Вимкніть автоматичне виконання хуків та команд робочого простору.
• Скануйте залежності та сценарії встановлення.
• Використовуйте чистий, ізольований робочий простір.
• Запобігайте доступу до непов'язаних репозиторіїв.
• Переконайтеся, що в робочому просторі або журналах збірки немає секретів.
• Протестуйте зі шкідливим текстом проблеми та отруєною документацією.
• Запишіть коміт репозиторію та хеш конфігурації агента.

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

• Замініть довільний доступ до оболонки типізованими операціями, де це можливо.
• Використовуйте дозволений список для інструментів та пунктів призначення.
• Перевіряйте шляхи після канонізації.
• Відхиляйте вихід за межі за допомогою символьних посилань.
• Запобігайте модифікації інструментами власних файлів політик.
• Запобігайте зміні агентом власного режиму схвалення.
• Вимагайте підтвердження перед мережевим доступом, що включає конфіденційні дані.
• Записуйте кожен виклик інструмента та його результат.
• Встановіть обмеження на розмір файлу, час команди, обсяг мережі та використання токенів.
• Перегляньте описи та дозволи сервера Model Context Protocol.
• Відхиляйте непідписані або неперевірені визначення інструментів.

Перед дозволом публікації коду або розгортання

• Вимагайте окрему ідентичність для агента та ініціатора-людини.
• Вимагайте людського перегляду перед злиттям (merge).
• Вимагайте незалежного схвалення перед розгортанням.
• Використовуйте короткоживучі облікові дані для публікації.
• Використовуйте довірену публікацію або ідентичність робочого навантаження замість довгоживучих токенів.
• Вимагайте підписи артефактів та інформацію про походження.
• Скануйте на наявність секретів та шкідливих залежностей.
• Збирайте з чистого середовища без спільних змінних кешів.
• Перевірте, що артефакт відповідає переглянутому вихідному коду.
• Підтримуйте швидкий процес відкату пакетів або розширень.
• Тестуйте відновлення резервних копій та знімків.

Під час реагування на інциденти

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

Пропоновані угоди про рівень обслуговування з безпеки

Це пропоновані цілі розгортання, а не універсальні галузеві стандарти. Організації повинні адаптувати їх до своєї толерантності до ризику.

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

Аудиторські артефакти, які повинно створювати кожне розгортання

Зріле розгортання повинно бути здатним відповісти, після факту:

• Хто запустив агента?
• Які користувачі та ідентичності сервісів були залучені?
• Який репозиторій та коміт були використані?
• Яка модель та версія агента працювали?
• Які інструкції були активні?
• Який зовнішній контент потрапив у контекст?
• Які інструменти були доступні?
• Які інструменти були фактично викликані?
• Які аргументи були надіслані?
• Які файли були прочитані або змінені?
• З якими мережевими пунктами призначення зв'язувалися?
• Які облікові дані були запитані?
• Які політики дозволили або відмовили в кожній дії?
• Які людські схвалення були отримані?
• Який артефакт був вироблений?
• Який артефакт був опублікований?
• Яке було остаточне рішення?

Зберігайте щонайменше такі артефакти:

1. Запис інвентаризації агента
2. Модель загроз та діаграма потоку даних
3. Маніфест можливостей та дозволів
4. Інвентаризація інструментів та конекторів
5. Запис версії моделі, запиту та політики
6. Образ контейнера та перелік залежностей (bill of materials)
7. Мережева політика та журнал вихідного трафіку
8. Звіт про виявлення та приховування секретів
9. Трасування сесій та викликів інструментів
10. Запис людського схвалення
11. Оцінка безпеки та звіт червоної команди
12. Походження випуску та підпис артефакту
13. Походження пам'яті та запис відкату
14. Реагування на інциденти та тест відновлення
15. Рекомендації з безпеки постачальника та запис патчів

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

OpenAI описує внутрішній моніторинг, що переглядає взаємодії агента кодування, виклики інструментів та потенційно підозрілу поведінку, тоді як GitHub наголошує на журналах сесій, підписаних комітах, атрибуції та аудиторських записах. Ці шаблони підтримують ширший принцип: поведінка агента повинна бути спостережуваною незалежно від власного пояснення агента про те, що він зробив. (openai.com)

Перший практичний крок

Найкращий перший крок – не розгортати агента проти виробничого репозиторію.

Натомість:

1. Створіть одноразовий тестовий репозиторій.
2. Дайте агенту завдання лише для читання.
3. Запустіть його всередині свіжої пісочниці.
4. Вимкніть доступ до облікових даних розробника.
5. Заблокуйте весь мережевий трафік, крім постачальника моделі.
6. Додайте навмисно шкідливу проблему, інструкцію readme, опис інструмента та файл конфігурації.
7. Запишіть кожну спробу доступу до файлу, виклику інструмента, команди та мережевого запиту.
8. Використайте результати для створення свого першого маніфесту дозволів та угоди про рівень обслуговування з безпеки.

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

Висновок

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

Вирішальне питання безпеки не є таким:

“Чи буде модель дотримуватися правильних інструкцій?”

Воно таке:

“Що станеться, якщо модель дотримуватиметься неправильної інструкції, маючи реальні дозволи?”

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

Інциденти 2025 та 2026 років показують, що найефективнішими засобами контролю є архітектурні:

• Тримайте агентів подалі від секретів.
• Використовуйте одноразові пісочниці можливостей.
• Застосовуйте політики поза моделлю.
• Розділяйте розробку від виробництва.
• Розглядайте конфігурацію та пам'ять як виконувані поверхні атаки.
• Використовуйте контрольований вихідний трафік.
• Видаліть спільні кеші з привілейованих робочих процесів випуску.
• Закріплюйте та перевіряйте кожен інструмент та артефакт.
• Поетапно виконуйте всі записи.
• Вимагайте незалежного схвалення для незворотних дій.
• Зберігайте детальні, захищені від несанкціонованого втручання аудиторські записи.

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