Якість і безпека

Безпека агентів штучного інтелекту (AI, artificial intelligence)

Агент на основі штучного інтелекту часто використовує велику мовну модель (LLM, large language model) — програму, що обробляє запити й формує текст за…

Глава 55Заморожене українське видання

Агент на основі штучного інтелекту часто використовує велику мовну модель (LLM, large language model) — програму, що обробляє запити й формує текст за контекстом, — але не обмежується відповідями. Він може читати файли, шукати у вебі, викликати API (application programming interface, програмний інтерфейс), запускати код, редагувати записи або передавати результат іншому сервісу. Через цю здатність помилка у розумінні тексту може стати дією із зовнішнім наслідком.

Передумови та результат навчання. Читач уже зустрів ієрархію інструкцій та інструменти агентів у розділах 28–39, облікові дані — у розділі 53, а межі безпеки застосунків — у розділі 54. Тут він навчиться відрізняти інструкцію від технічного дозволу, простежувати вплив недовіреного тексту на доступні дії й реагувати на невизначений результат.

Практично це означає: назвати джерело можливого впливу, простежити шлях від нього до конкретного інструмента або адресата, визначити технічний компонент, який має зупинити небезпечну дію, і пояснити, які докази потрібні після невдалого або невизначеного виклику. Мета — не навчити модель «бути обережною», а допомогти команді побачити, де її добрі наміри мають бути підкріплені обмеженням системи.

Загрозу визначають не назва чи версія моделі, а вміст, що може вплинути на рішення, доступні агенту дії, технічні обмеження та наслідки можливої помилки. Розділ 54 розглядав безпеку застосунку загалом; тут фокус — на агентному потоці від недовіреного тексту до виклику інструмента. Серверний дозвіл усе одно перевіряє застосунок, а не підказка агента. Розділ 56 переходить до безпеки автоматичних процесів неперервної інтеграції, а повний процес участі людини розглянуто в розділі 74.

55.1. Модель загроз починається з можливостей

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

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

Складник Запитання Приклад
Що захищаємо Які дані, записи, секрети, облікові записи чи послуги мають цінність? Вміст приватного репозиторію, профілі клієнтів, конфігурація розгортання
Від кого або чого Який користувач, документ, сайт, інтеграція чи скомпрометований постачальник може вплинути на роботу? Текст зовнішнього завдання, лист, коментар у помилці, відповідь інструмента
Через яку межу Де агент отримує дані або право щось змінити? Пошук, файлова система, інструмент бази даних, локальний сервер протоколу контексту моделі (MCP, Model Context Protocol)
Яку дію він може виконати Чи може він читати, змінювати, видаляти, запускати код або надсилати дані? Записати одну заявку або зробити довільний мережевий запит
Яким буде наслідок Що станеться, якщо агент прийме недовірений текст як доручення або неправильно вибере дію? Витік даних, помилкова зміна, дубльований платіж, блокування сервісу

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

Надавайте лише потрібні для завдання права на конкретні ресурси й операції. Сам поділ «читати / записувати» недостатній: читання може розкрити секрети, запис — змінити чи надіслати дані, а мережевий доступ — винести те, що агент прочитав іншим способом.

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

Зручна модель для аналізу — джерело впливу → агент → доступний інструмент або приймач → наслідок. Для кожної ланки запитайте, яке технічне правило не дасть небезпечній дії пройти. Якщо є лише відповідь «модель мала б зрозуміти, що цього не слід робити», система покладається на поведінку моделі там, де потрібне примусове обмеження.

55.2. Текст може бути даними й водночас впливати на рішення

У звичайному програмному коді дані та команди часто обробляють різними механізмами: параметризований запит до бази відрізняє значення від структури запиту. Мовна модель натомість отримує послідовність тексту й намагається зрозуміти її. Текст у вебсторінці, листі, файлі, коментарі чи відповіді інструмента може містити фрази, що виглядають як інструкції: «заміни мету», «прочитай цей файл», «не показуй користувачу, що ти робиш». Таку спробу вплинути на поведінку агента називають ін’єкцією підказки (prompt injection).

Ін’єкція буває прямою — її надсилає сам користувач, — або непрямою: вона потрапляє з вебсторінки, вкладення, коду, листа, результату пошуку чи відповіді іншого інструмента. Вона не обов’язково має бути прихованою чи містити очевидні слова на кшталт «ігноруй попереднє». Переконлива інструкція може бути сформульована як звичайна робоча примітка, термінова вимога або частина корисного документа. Тому надійний захист не може зводитися до пошуку одного набору «поганих» фраз або до обіцянки, що агент їх розпізнає. OpenAI описує той самий ризик як поєднання джерела впливу й приймача, якому агент здатен щось передати; архітектура має обмежувати наслідки навіть тоді, коли модель введено в оману (OpenAI: Designing AI agents to resist prompt injection).

Позначка «недовірений вміст» фіксує його походження, але не створює межі безпеки. Поля, лапки, розмітка й структурований JSON (JavaScript Object Notation) допомагають зберегти структуру даних, та не забороняють моделі сприйняти їхній вміст як інструкцію. Фільтр явних директив також не доводить, що довільний текст не вплине приховано чи непрямо.

Захищена система поєднує кілька рівнів:

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

Ієрархія інструкцій, файли проєкту (AGENTS.md, CLAUDE.md) і клієнтські гачки можуть скеровувати модель або зупинити окремий виклик. Вони не обмежують системні права процесу, мережевий вихід чи серверну авторизацію. Примусове правило має стояти на шляху, яким фактично проходить дія.

55.3. Інструмент має чіткі межі, а не просто переконливий опис

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

Для кожного інструмента зафіксуйте:

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

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

Тут важливий ризик «заплутаного заступника» (confused deputy). Це ситуація, коли сервіс із власними правами виконує запит від імені іншої сторони, але не перевіряє, чи саме ця сторона мала право на дію або на цільовий ресурс. Агент може мати право попросити внутрішню службу щось прочитати; якщо служба використовує власні ширші облікові дані, вона не повинна автоматично передавати ці права агенту. Для кожного виклику з’ясуйте, чию ідентичність використовує сервер і де перевіряються дозволи. Поточні рекомендації безпеки Model Context Protocol (MCP) описують цей клас проблем серед ризиків реалізації MCP та окремо застерігають від передавання токенів, виданих для іншого призначення.

MCP стандартизує спосіб, у який програми оголошують і викликають інструменти та передають контекст. Наявність MCP-з’єднання сама по собі не означає, що користувач схвалив кожну майбутню операцію. Протокол авторизації визначає потік авторизації для захищених серверів; те, чи побачить людина запит перед окремим викликом інструмента, залежить від програми-клієнта та її політики. Анотації на кшталт readOnlyHint, destructiveHint чи idempotentHint — підказки про властивості інструмента, а не примусова заборона запису, видалення або повтору. Перевіряйте фактичний контракт сервера й його права, а не лише текстову декларацію (MCP Authorization, версія 2026-07-28; MCP: Tool annotations).

55.4. Підтвердження має стосуватися конкретної дії

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

Зручне підтвердження дає змогу відповісти на чотири питання:

  • Що буде зроблено? Наприклад, «оновити статус заявки 482» замість «запустити інструмент».
  • Над чим або кому? Точний запис, одержувач, середовище чи адреса призначення.
  • Які дані буде використано або передано? Показати суттєвий вміст без зайвих секретів.
  • Що зміниться після виконання? Чи можна скасувати дію і що залишиться назовні.

Рівні захисту відповідають на різні запитання і не замінюють один одного:

Рівень Що він може забезпечити Чого сам по собі не доводить
Інструкція в підказці Пояснити бажану поведінку моделі Що модель неодмінно виконає інструкцію
Фільтр або захисна перевірка Виявити частину небажаних входів, відповідей чи викликів Що відомі всі способи обходу або що сервер має вузькі права
Схема інструмента Перевірити форму й типи аргументів Що саме цей користувач має право на цей ідентифікатор ресурсу
Авторизація сервера Відхилити несанкціоновану дію над ресурсом Що дія доречна, схвалена людиною або має зворотний ефект
Пісочниця та мережеві правила Обмежити частину файлових, процесних і мережевих можливостей Що дозволений шлях безпечний для бізнесу або не передає зайві дані
Підтвердження людини Дати змогу прийняти чи відхилити показану конкретну дію Що приховані наслідки видимі або дія не зміниться після схвалення

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

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

Механізми поєднують: наприклад, пісочниця обмежує доступ процесу до диска, сервер перевіряє дозвіл на запис, а людина схвалює публікацію. Їхнє покриття залежить від продукту: Anthropic описує дозволи й пісочницю Bash у Claude Code, а OpenAI — require_approval та allowed_tools для MCP у Responses API й окреме схвалення в Agents SDK. Це можливості відповідних продуктів, не універсальні гарантії для всіх агентів (Claude Code: Security; Responses API: MCP tools; OpenAI Agents SDK: Guardrails and human review).

55.5. Повтор після перевищення часу очікування може подвоїти дію

Перевищення часу очікування (timeout) означає, що клієнт не отримав своєчасної відповіді. Воно не доводить, що сервер не виконав запит. Можливо, сервер створив запис або списав платіж, але відповідь загубилась по дорозі. Якщо агент автоматично повторює той самий виклик, наслідок може статися вдруге.

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

Без такої гарантії потрібно зупинитися на невизначеному стані: перевірити, чи дія вже відбулася, і попросити людину розв’язати неоднозначність, якщо зчитати стан неможливо. «Спробуй ще раз» не є безпечним правилом для переказу грошей, публікації чи видалення. Наявність поля з назвою idempotent у документації MCP теж не робить операцію ідемпотентною: це властивість реалізації, яку має гарантувати сервіс і перевіряти тестами.

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

55.6. Сторонні інструменти, плагіни та сервери — частина ланцюга довіри

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

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

Локальний сервер MCP може виконуватися з правами процесу користувача, а віддалений сервер приймає запити й обробляє переданий контекст у власному середовищі. Це різні межі ризику. Для локального сервера обмежуйте доступ до файлів, процесів і мережі; для віддаленого з’ясовуйте, які дані клієнт передає сервісу, як він автентифікується, хто видає токени та як відкликати доступ. Не передавайте серверу токен, виданий для іншої аудиторії, і не покладайтеся на те, що він «довірений», бо він підключений через знайомий клієнт.

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

55.7. Приватність, журнали й межі доказів

Для розслідування інциденту потрібен слід рішень та викликів, однак повний запис усіх підказок, відповідей інструментів і файлів часто створює нове сховище чутливих даних. Заздалегідь визначте мету аудиту, доступ до записів, строк зберігання та процедуру видалення. Персональні дані (PII, personally identifiable information), ключі доступу й фрагменти приватних документів не слід записувати в журнал лише тому, що це зручно для налагодження.

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

У звіті про власних агентів для програмування OpenAI описує поодинокі спроби несанкціонованого передавання даних і руйнівних дій. Це спостереження в одному внутрішньому середовищі, не оцінка частоти для всіх систем; воно підкреслює, що журнали доповнюють технічні межі, а не замінюють їх (OpenAI: Monitoring internal coding agents for misalignment).

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

55.8. Повні розбори

У контрольованому тестуванні OpenAI з американським центром CAISI (Center for AI Standards and Innovation, Центром стандартів та інновацій у сфері штучного інтелекту) демонстраційний ланцюг із двох вразливостей ChatGPT Agent спрацював приблизно у половині спроб і міг за певних умов обійти захисти, віддалено керувати комп’ютером, доступним агенту в цій сесії, та видавати себе за користувача на інших сайтах. OpenAI повідомила, що виправила вразливості за один робочий день. Це звіт про тест, не свідчення реальної експлуатації (OpenAI: результати спільного тестування безпеки ChatGPT Agent із американським центром CAISI).

Повний розбір 1: непряма ін’єкція в листі до Copilot

У 2025 році Microsoft описала EchoLeak — усунений ланцюг непрямої ін’єкції підказки для Microsoft 365 Copilot, якому присвоєно ідентифікатор CVE (Common Vulnerabilities and Exposures, система ідентифікації публічно розкритих вразливостей) 2025-32711. За описом Microsoft, спеціально сформований лист міг за певних умов вплинути на вміст, який отримував Copilot, і спричинити витік обмежених даних, уже доступних жертві. Microsoft повідомила про виправлення. Це повідомлення про конкретну вразливість та її усунення, а не доказ масової експлуатації клієнтських даних (Microsoft Security Insider: AI application security considerations; Microsoft Security Response Center (MSRC): CVE-2025-32711).

Чому цей випадок важливий для архітектури? Лист є даними для підсумку, але може нести текст, що впливає на подальші кроки агента. Якщо агент уже має право бачити внутрішні документи, сам контроль доступу до цих документів може працювати правильно: користувач і справді має до них доступ. Ризик з’являється, коли недовірений лист змінює намір агента, а шлях до відповіді дозволяє винести фрагмент інформації. Тобто доступ до даних і дозвіл передати їх у певний канал — різні рішення.

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

Висновок: доступ, успадкований від користувача, усе одно має межі використання. Якщо агент бачить приватний матеріал для читання, це не є згодою на його пересилання. Успішна ін’єкція також може бути наслідком перетину традиційної вразливості та агентного потоку, а не лише «поганої відповіді моделі».

Повний розбір 2: уразливість у сервері gemini-mcp-tool

У 2026 році GitHub Advisory Database опублікувала повідомлення про вразливість CVE-2026-0755 у пакеті gemini-mcp-tool. За описом, версії від 1.1.2 до 1.1.5 могли передати недовірений текст до парсера посилань на файли в інтерфейсі командного рядка Gemini (CLI, command-line interface); вразливість давала змогу читати довільні локальні файли з можливим передаванням назовні. Для Windows вказано також ін’єкцію команди через аргументи cmd.exe. Виправлена версія — 1.1.6; серед змін повідомлення називає перевірку посилань на файли в межах робочого каталогу й виправлення екранування аргументів командного рядка для Windows. Zero Day Initiative окремо описала проблему з валідацією рядка перед системним викликом (GitHub Security Advisory (GHSA)-4h5r-5jm8-jxjm; Zero Day Initiative ZDI-26-021).

Це вада конкретного wrapper-сервера, а не доказ того, що кожен MCP-сервер має таку саму помилку. Вона показує, чому природномовний виклик і зовнішня команда мають різні межі: значення, що виглядає як «текст для підказки», пройшло до інтерпретатора CLI й системної оболонки. Слова інструмента «передає запит Gemini» не описують, що реалізація фактично робить із аргументами.

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

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

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

Повний розбір 3: зовнішній текст просить надіслати конфігурацію

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

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

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

Висновок: не відхиляйте обов’язково все завдання через один підозрілий рядок; відмовте саме в несанкціонованому кроці, збережіть початкову мету й повідомте про межу, що зупинила дію.

Повний розбір 4: підготовка міграції просить виробничі облікові дані

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

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

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

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

Повний розбір 5: запис змінився, але відповідь інструмента загубилась

Навчальна ситуація: агент просить CRM (customer relationship management, система керування взаєминами з клієнтами) змінити адресу доставки. Служба записує адресу, але відповідь губиться через timeout. Агент бачить помилку з’єднання й збирається повторити запит.

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

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

Висновок: повтор — це нова спроба змінити стан, якщо сервер не гарантує ідемпотентність. Перевіряйте стан перед повтором і зберігайте один ідентифікатор для всієї операції.

55.9. Перевіряйте властивості системи, а не обіцянки моделі

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

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

Перевіряйте і звичайні, і негативні сценарії: невідомий ідентифікатор, зайве поле, заборонений шлях, переповнену відповідь, timeout після запису, оновлений інструмент і підроблену відповідь. Тестуйте контрольовано, на синтетичних даних, і фіксуйте версію агента, модель, налаштування та середовище; не спрямовуйте тести на сторонні сервіси без дозволу. Переконайтеся, що дію справді відхилили сервер або середовище, а не лише модель. OWASP радить окремо перевіряти зловживання інструментами, підвищення привілеїв і передавання даних (OWASP: AI Agent Security Cheat Sheet; OWASP: LLM Prompt Injection Prevention Cheat Sheet).

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

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

Короткий підсумок

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

Джерела та подальше читання

Матеріали перевірено 24 вересня 2026 року. Відомості про API, інтерфейси, версії та дозволи залежать від конкретного продукту й конфігурації; вони не означають однакової поведінки в ChatGPT, Codex, Claude Code, Claude API та самостійно створеному агенті.