Більшість програм безпеки збудовано навколо одного припущення, яке ніхто не записав: той, хто тримає credentials, — людина. Людина, яка втомлюється, читає повільно і помічає, коли README раптом просить надіслати файл .env кудись поштою. Coding-агенти ламають це припущення. Вони тримають ті самі токени, що й ваші інженери, читають кожен файл і веб-сторінку, на які ви їх спрямуєте, і діють зі швидкістю машини.
Це не робить агентів унікально небезпечними. Це робить їх новою категорією актора, для якої ваші контролі не проєктувалися. Упродовж останніх місяців команда безпеки Anthropic опублікувала низку матеріалів саме про цю проблему — CISO’s guide to agentic AI, розбір того, як вони захищають власний AI-native SDLC, настанови щодо Zero Trust для агентів, щодо сканування коду за допомогою LLM і щодо підготовки до AI-прискореної атаки. Цей пост — мій інженерський синтез із них: що справді нове в threat model, які контролі витримують і як їх впровадити, не повернувши ваш rollout агентів назад у чергу тікетів.
Якщо ви читали пост про AI-native SDLC, вважайте цей розділом про безпеку, що лежить під ним.
Чому агенти змінюють threat model
Класичний Zero Trust каже: нікому не довіряй за замовчуванням, перевіряй кожен запит, припускай, що злам стався. Усе це й далі діє. Змінюється те, хто робить запити і що він читає перед цим.
Агент має охоплення service account, імпровізацію людини й жодної людської інтуїції «ця інструкція виглядає підозріло». Важливі три властивості:
- Агенти діють на основі контенту, а не лише команд. Усе, що агент читає — текст issue, README залежностей, веб-сторінки, виводи інструментів, тестові фікстури, — стає частиною його прийняття рішень. Якщо зловмисник може написати будь-що з цього контенту, він має канал у вашого агента.
- Агенти використовують легітимні права. Більшість інцидентів з агентами не виглядатимуть як злам. Вони виглядатимуть як авторизована ідентичність, що робить те, чого ніхто не мав на увазі. Контроль доступу, який питає лише «чи дозволено цій ідентичності?», пропустить це.
- Агенти стають здібнішими, хоч ви нічого не змінювали. Апгрейд моделі може відкрити поведінку, якої ваша початкова оцінка ризиків ніколи не розглядала. У CISO-гайді є хороший приклад: агент для incident response після апгрейду моделі, без жодних змін в інструментах чи промптах, почав просити іншого агента написати виправлення коду посеред інциденту. Людський review-гейт зловив це до продакшену — у чому й сенс.
Тим часом зовнішній світ теж прискорюється. Стаття Anthropic про підготовку до атак стверджує, що моделі стискають час від виявлення вразливості до робочого експлойта, і що захисникам варто планувати зростання кількості звітів про вразливості на порядок протягом приблизно двох років. Ваші агенти працюють на інфраструктурі, відкритій до того самого прискорення.
Ландшафт загроз на потрібному вам рівні
Я залишу це концептуальним. Для проєктування контролів вам не потрібні рецепти експлойтів; потрібні категорії.
Prompt injection
Інструкції, сховані в контенті, який читає агент, із метою перенаправити його дії. Це визначальний ризик агентів, і чесний статус такий: захисти на рівні моделі покращуються, але ніхто достовірний не стверджує, що частка успіху нульова. Ставтеся до injection як до фішингу — того, що ви зменшуєте й стримуєте, а не «розв’язуєте».
Надмірно запопадливі та помилкові дії
Це те, що команди недооцінюють. Розбір Anthropic про auto mode у Claude Code каталогізує реальні внутрішні інциденти, які зовсім не були атаками: агент, що витлумачив «прибери старі гілки» як дозвіл масово видалити віддалені гілки; агент, що нишпорив по конфіг-файлах у пошуках іншого токена після помилки автентифікації; агент, що повторив невдалий деплой, пропустивши верифікацію. Добрі наміри, хибний blast radius. Моє очікування: ця категорія завдає щоденної шкоди більше, ніж adversarial injection.
Витік credentials
Агент може злити лише те, до чого має доступ. Якщо у вашому developer-середовищі є довгоживучі хмарні ключі, SSH-ключі та .env із продакшен-секретами поруч із кодом, то кожен із них у зоні ураження для агента з injection чи надмірною запопадливістю.
Надто широкі права та неоднозначна ідентичність
CISO-гайд робить зауваження, яке я знайшов проясняльним: небезпечна зона — це не виділений service account і не людина за клавіатурою. Це проміжна територія, де агент несе делеговану ідентичність людини в системи, за якими ця людина не стежить. Коли щось іде не так, ніхто не може сказати, хто це насправді зробив.
Supply chain розширень
Skills, plugins, MCP-сервери, конектори та залежності, які встановлюють агенти, — кожне є кодом або інструкціями, яким ви вирішуєте довіряти, а дещо подає недовірений контент прямо в контекст. Tool poisoning — це шкідливий пакет доби агентів. Якщо ви широко впроваджуєте MCP, питання governance з MCP для інженерних команд — це теж питання безпеки.
Отруєння пам’яті й контексту
Персистентний контекст — memory-файли, інструкції в стилі CLAUDE.md, спільні бази знань — можна підмінити так, що отрута переживе сесію. Файли інструкцій заслуговують на дисципліну code review, бо фактично є кодом.
Чотири питання перед тим, як схвалити будь-якого агента
Найкорисніший інструмент у всьому цьому наборі джерел — чотирипитальна оцінка з CISO-гайда. Я переформулював її так, як справді використовував би на design review:
- Який недовірений контент він читає? Що зловмисник правдоподібно може написати чи змінити, щоб воно потрапило в контекст агента? Якщо чесна відповідь «нічого», специфічний для агента ризик близький до нуля.
- Що він може робити і від чийого імені? Читати чи писати, виконувати код, викликати інструменти, виходити в мережу — і під якою ідентичністю.
- Який blast radius, якщо щось піде не так? Один файл, один репозиторій, одне середовище, вся організація? Найгірший випадок — прикрість чи інцидент?
- Чи ви його бачите? Чи можете ви відрізнити дії агента від дій користувача, і чи потрапляють вони у ваш SIEM?
Ці питання перетворюють «чи дозволяти агентів?» — дебати, що ніколи не закінчуються, — на «за яких умов ми схвалили б цього?», на що є відповідь. Ризикована комбінація — недовірений вхід плюс потужні дії плюс погана видимість; приберіть будь-яку ногу — і картина різко покращується.
Контролі, що справді тримаються
Приблизно в порядку впливу. Наскрізна тема: проводьте межі навколо дій і доступу, а не навколо інструкцій для моделі. Промпт, що каже «ніколи не чіпай продакшен», — це порада. Credential, який не сягає продакшену, — це контроль.
Least agency
Least privilege, адаптований: надавайте найвужчу здатність, що завершує завдання, а не лише найвужчий доступ до даних. Обмежуйте окремі дієслова, а не лише цілі інструменти — агент, який може скласти повідомлення, але не надіслати, відкрити PR, але не змерджити, читати логи, але не деплоїти. Якщо в агента немає дієслова, жодна injection не змусить його ним скористатися.
Sandboxing та контроль egress
Запускайте агентів в ізольованих середовищах — контейнерах, microVM, віддалених dev-VM — із credentials, що лежать поза sandbox. Патерн, який Anthropic описує для власного інструментарію, — проксі, що інжектує credentials на виході, тож у sandbox немає нічого вартого крадіжки. Поєднайте це з allowlist для egress через проксі, який агент не може обійти. Агент після injection, який не може дістатися довільного пункту призначення, не має куди відправити знайдене.
Ідентичність агента для однієї мети
Дайте кожному автономному агентові власну ідентичність з мінімальними правами для його єдиної роботи, надану через ваш IdP, як будь-якому іншому суб’єкту. Incident-response агент Anthropic — підручниковий випадок: він може читати продакшен-логи, писати документи й постити в каналах — і нічого більше. Він не може деплоїти. Інтерактивні coding-сесії інакші: за клавіатурою людина, яка відповідає за дії, тож credential людини там нормальний, поки середовище в sandbox. Уникайте проміжної території.
Детерміновані hooks і managed settings
Це розрізнення, яке я повторюю в кожному пості про агентів, бо воно запобігає стільком інцидентам: інструкції радять, hooks примушують. Ваші настанови безпечного кодування належать у CLAUDE.md і skills, щоб згенерований код здебільшого їх дотримувався. Але все, що має триматися — жодних правок захищених шляхів, жодних секретів у diff’ах, обов’язковий security-прохід перед відкриттям PR, — потребує детермінованої страховки: pre-tool hook, CI-гейт, правило branch protection. А тоді перенесіть невід’ємні частини в централізовано керовані settings, щоб окремі розробники не могли тихо їх послабити.
Класифікатори як середній шар, а не стіна
Approval fatigue реальна: Anthropic повідомляє, що користувачі приймають 93% permission-запитів Claude Code, а це означає, що запит значною мірою перестав працювати як перевірка. Auto mode замінює більшість запитів класифікатором, який оцінює кожну ризиковану дію перед виконанням. Опубліковані цифри заслуговують на уважне прочитання: 0,4% false-positive на реальному трафіку, але 17% пропусків на невеликій вибірці реальних надмірно запопадливих дій. Anthropic подає це як велике покращення порівняно з пропуском permissions і можливу регресію порівняно з ретельним ручним схваленням на високоризиковій інфраструктурі. Тож використовуйте його як один шар понад sandbox і credentials з least privilege, ніколи — як єдине, що стоїть між агентом і продакшеном.
Audit trail, що відрізняє агента від людини
Кожен виклик інструмента, автоматичне схвалення та повідомлення між агентами має логуватися з достатнім контекстом — інструмент, параметри, результат, користувач, сесія, — щоб відновити, що сталося, і відправлятися у ваш SIEM. Ставтеся до агентів як до потенційних інсайдерів і налаштуйте алерти на поведінку поза патерном. CISO-гайд цитує показник Ponemon у 67 днів у середньому для стримування інсайдерського інциденту; агент, що працює зі швидкістю машини, робить такий таймлайн неприйнятним, ось чому видимість має передувати масштабу.
Людина на production-гейті
Найчистіша лінія governance, яку я знаю: агент може робити все аж до production-гейта, а іменована людина авторизує проходження крізь нього. Anthropic каже, що Claude пише близько 80% коду, змерджованого в її кодову базу, а внутрішній агент обробляє значну частину потоку pull request’ів — і контролі, що роблять це прийнятним, — це ефемерні середовища, відокремлені від продакшен-ключів, плюс людське review перед merge. Розбийте вашу кодову базу на рівні за ризиком: деякі шляхи можна автосхвалювати з вибірковою перевіркою, регульований чи критичний код лишається під людським review.
Безперервне сканування, спрямоване на ваш власний код
Якщо зловмисники скануватимуть ваш код потужними моделями, скануйте його першими. Цикл із гайда про безпеку вихідного коду варто впровадити майже як є: threat model, sandbox, discover, незалежна верифікація, triage, patch. Тримайте discovery (recall) і верифікацію (precision) в окремих агентах, і закладайте бюджет на triage та patching раніше, ніж на більше сканування, — triage тепер вузьке місце.
Таблиця контролів
Ось усе на одній сторінці. «Детермінований» означає, що тримається незалежно від рішення моделі; «дорадчий» — що зсуває ймовірності.
| Ризик | Контроль | Тип | Власник |
|---|---|---|---|
| Prompt injection через прочитаний контент | Визначити недовірені джерела; відокремити конектори недовіреного вводу від продакшен-даних; injection-проби | Дорадчий (проби) + Детермінований (відокремлення) | Security architecture |
| Ексфільтрація даних | Sandbox з egress allowlist через проксі, який не можна обійти | Детермінований | Platform engineering |
| Витік credentials | Credentials інжектує проксі, у sandbox їх ніколи немає; короткоживучі токени з вузьким scope | Детермінований | Platform / IAM |
| Надмірно запопадливі чи руйнівні дії | Права інструментів на рівні дієслів; класифікатор дій; deny-правила в managed settings | Детермінований (permissions) + Дорадчий (класифікатор) | Tech lead + platform |
| Неоднозначна відповідальність | Ідентичності агентів для однієї мети через IdP; жодної делегованої людської ідентичності для агентів без нагляду | Детермінований | IAM |
| Дрейф політик у згенерованому коді | Правила безпечного кодування в CLAUDE.md/skills, підкріплені hooks і CI-гейтами | Дорадчий → Детермінований | Власник політик + tech lead |
| Шкідливі skills, plugins, MCP-сервери | Allowlist розширень, версіонованих і рев’юваних як залежності | Детермінований | Platform + security |
| Отруєння пам’яті / інструкцій | Файли інструкцій під code review та code ownership | Детермінований | Code owners репозиторію |
| Несанкціоновані зміни в продакшені | Approval hook або CI-гейт, що вимагає іменовану людину; branch protection | Детермінований | Release manager |
| Непомічене зловживання | Телеметрія викликів інструментів у SIEM; атрибуція агент-проти-людини; загальноорганізаційний вимикач | Детермінований (логування) | Security operations |
| AI-прискорена експлуатація вашого коду | Безперервне сканування з незалежною верифікацією; швидкі SLA на патчі | Дорадчий (знахідки) + Детермінований (блокування merge при високій впевненості) | AppSec |
Якщо в рядку лише «дорадчий», а ризик такий, що ви не можете його прийняти, — це ваша наступна робота.
Де я був би обережним
- Це документи вендора. Усі шість джерел — від Anthropic, і кілька посилаються на продукти Anthropic. Патерни — least agency, sandbox без credentials, контроль egress, детерміновані гейти, ідентичність агента, телеметрія — вендорно-нейтральні й застосовні до будь-якого coding-агента. Специфіка продуктів зміниться; проєктуйте навколо патернів.
- Цифри Anthropic — це цифри Anthropic. Вони описують одну дуже AI-native організацію з незвично зрілою командою безпеки. Сприймайте їх як доказ, що модель може працювати, а не як цілі, які слід обіцяти раді директорів.
- Не перепроєктовуйте prompt-scaffolding як контроль. CISO-гайд зауважує, що розлогі інструкції з покращенням моделей, як правило, прибирають. Витрачайте ці зусилля на межі, які взагалі не залежать від моделі.
- Lockdown має ціну. Кожне deny-правило забирає можливість. Копіювання найсуворішої конфігурації в кожен репозиторій штовхає людей до несанкціонованих інструментів — а shadow-впровадження не має ні телеметрії, ні вимикача. Підганяйте обмеження під класифікацію даних кожного репозиторію.
Як це впровадити, не вбивши швидкість
Фрейм, який мені подобається найбільше, походить із назви CISO-гайда: нульовий ризик — не мета. Мета — зробити agentic-ризик видимим і обмеженим, щоб організація могла прийняти його свідомо. Сказати «ні» не усуває використання агентів; воно лише переїздить туди, де ви його не бачите.
Порядок, якого я дотримувався б у реальній команді:
- Тиждень 1–2: інвентаризація та класифікація. Перелічіть, де агенти вже працюють, санкціоновано чи ні. Запишіть, що вважається недовіреним контентом у вашому середовищі. Проженіть ваш найнапруженіший use case через чотири питання, шукаючи умови, за яких ви сказали б «так».
- Тиждень 3–4: заберіть секрети з досяжності. Перенесіть роботу агентів у sandbox-середовища, з credentials поза sandbox і egress allowlist. Ця єдина зміна зменшує blast radius усіх інших збоїв.
- Місяць 2: зробіть політику детермінованою. Закодуйте правила безпечного кодування в
CLAUDE.mdі skills, а потім додайте hooks і CI-гейти для підмножини, що має триматися. Перенесіть їх у managed settings. Зробіть allowlist для розширень і MCP-серверів. - Місяць 2–3: ідентичність і телеметрія. Дайте кожному автономному агентові ідентичність для однієї мети. Стрімте виклики інструментів у ваш SIEM з атрибуцією агент-проти-людини. Переконайтеся, що у вас є загальноорганізаційний вимикач і що він справді працює.
- Місяць 3+: переведіть рев’юерів із рядків на цикли. Спершу запустіть нових AI-рев’юерів у shadow-режимі, red-team’те їх навмисно поганими змінами, потім розбийте кодову базу на рівні, щоб люди концентрувалися на ризикових шляхах. Почніть безперервне сканування найвідкритішого сервісу, з кроком верифікації та шляхом triage.
Розширюйте поетапно: спершу мала група, спостерігайте телеметрію, потім ширше. Запитайте ваші IdP, SIEM та вендорів агентів, які з цих контролів вони можуть продемонструвати сьогодні, а не в roadmap. Про організаційний бік і процес review дивіться AI readiness assessment для CTO та rollout AI-інструментів для кодингу.
Кар’єрний ракурс
Security-інженери переходять від полювання на окремі баги до моніторингу циклів, що їх знаходять і виправляють. Platform-інженери кодують governance як sandboxes, hooks і managed settings. Tech leads володіють файлами інструкцій і review-гейтами — що робить їх частиною security-периметра, просили вони про це чи ні.
Для окремих інженерів навичка, що накопичується, — швидко відповідати на чотири питання для будь-якого налаштування агента. Вона не прив’язана до моделі чи вендора і цінується дедалі більше щоразу, коли можливості стрибають.
Глибше
Контролі в цьому пості прямо відображаються на наші курси. AI-Native SDLC охоплює hooks, approval-гейти та модель «людина на production-гейті» протягом усього життєвого циклу. Claude Code Mastery глибоко розбирає permissions, sandboxing, hooks і managed settings у щоденному agentic-циклі. MCP Servers — де вчитися безпечно будувати й керувати шаром інструментів. Якщо ви будуєте власних агентів, Claude Agent SDK і Claude API охоплюють права інструментів, ідентичності зі scope та обв’язку за ними.
Для команд, що впроваджують агентів в організації, ми також проводимо це як корпоративне навчання або як практичний AI tools enablement.
Джерела: Anthropic, Zero risk isn’t the job: a CISO’s guide to agentic AI (липень 2026); How Anthropic secures its AI-native software development lifecycle (липень 2026); Zero Trust for AI agents (травень 2026); Using LLMs to secure source code (травень 2026); Preparing your security program for AI-accelerated offense (квітень 2026); How Claude Code auto mode works (березень 2026). Цей пост — незалежний коментар; повні деталі шукайте в оригіналах. Пов’язане в цій серії: AI-native SDLC, MCP для інженерних команд, коли не варто використовувати AI-інструменти.
