Дозволи AI-агентів потребують детермінованого забезпечення

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

Аудиторія: досвідчені фахівці, які створюють агентів із використанням інструментів, coding agents або MCP servers.

Ця відповідь важлива, тому що підказка на кшталт «попроси перед видаленням» є рекомендацією, а не межею контролю доступу. Модель може неправильно її зрозуміти, ін’єктована інструкція може конкурувати з нею, а інструмент може поводитися інакше, ніж описано. Авторизація має витримувати всі три типи відмов.

Що мають контролювати дозволи AI-агента

Система дозволів агента визначає, чи може конкретний викликач виконати конкретну дію над конкретним ресурсом за поточних умов. «Агент може використовувати GitHub» — надто широко. Корисне рішення має містити щонайменше:

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

Розділення цих ролей також допомагає чесно забезпечити ізоляцію секретів. Брокер облікових даних може приховати API key від моделі, водночас відкривши всі операції, які дозволяє цей ключ. Брокер захищає секрет; політика, прив’язана до дії, захищає ресурс.

Що вимірювало найновіше дослідження дозволів

У препринті за липень 2026 року *How Agents Ask for Permission* розглянуто 21 систему дозволів агентів і пропозицію, опубліковані або випущені з 2024 до 2026 року. Автори також протестували п’ять комерційних агентів в ізольованих середовищах наприкінці травня та на початку червня.

Їхня таксономія виявляє інженерний компроміс між трьома цілями:

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

Комерційні інструменти вже частково відображають цей поділ. Claude Code documents описують правила allow, ask і deny, тоді як його sandbox documentation описує межі файлової системи та мережі на рівні ОС. Настанови OpenAI щодо Codex security так само розглядають sandbox як технічну межу, а політику погоджень — як місце, де користувача можуть попросити про рішення. Це специфічні для продуктів засоби контролю, а не доказ того, що кожне розгортання налаштоване безпечно.

Втома від погоджень — це проблема маршрутизації

Запити на погодження корисні, коли користувач має ухвалити справжнє рішення. Вони не працюють, коли кожна рутинна команда виглядає однаково терміновою.

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

Маршрутизуйте дії до одного з чотирьох результатів:

Ризик слід обчислювати на основі дії та радіуса її впливу, а не впевненості моделі. Висока впевненість не робить незворотну дію безпечнішою.

П’ятишарова архітектура дозволів

Найменша достовірна архітектура має п’ять окремих шарів. Їх об’єднання ускладнює аудит і створює шляхи з режимом fail-open.

*Модель пропонує дію. Політика, забезпечення, виконання та докази залишаються окремими.*

1. Нормалізуйте запропоновану дію

Перетворюйте виклик інструмента, згенерований моделлю, на типізований запит до авторизації:

{ "actor": "agent-run-7f3", "on_behalf_of": "user-42", "action": "blog.publish", "resource": "post:ai-agent-permissions", "constraints": { "environment": "production", "language": "en" } }

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

2. Оцінюйте політику поза межами моделі

Повертайте детерміноване рішення: `allow`, `ask` або `deny`. Додавайте правило політики та термін дії. Модель може допомогти класифікувати новий запит, але сама ця класифікація не повинна надавати доступ. Невідомі дії мають завершуватися за принципом fail closed.

3. Забезпечуйте виконання рішення під час виконання

Обробник інструмента або downstream service має повторно перевірити рішення. Не покладайтеся на те, що агент дотримається відмови. Прив’язуйте можливість до точної дії, ресурсу, викликачa та короткого часового вікна, щоб її не можна було повторно використати для іншої цілі.

Специфікація авторизації MCP застосовує той самий принцип до access tokens: servers must validate that a token was issued for the intended audience. У security guidance MCP прямо заборонено token passthrough, оскільки він може зруйнувати цю межу.

4. Виконуйте дії через вузькі інструменти

Надавайте перевагу `publish_draft(post_id)` замість `run_sql(query)` і `send_invoice(invoice_id)` замість `http_request(url, body)`. Вузькі інструменти роблять політику зрозумілою та зменшують простір ненавмисних дій.

Той самий аргумент щодо шару контролю наведено в MCP Developer Workflows: The Real Control Layer: форма інструментів, шлюзи погодження та дії, які можна відтворити, визначають, що агент може безпечно робити.

5. Записуйте квитанцію та підтримуйте відкликання

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

Квитанція має розрізняти «інструмент повернув результат» і «очікуваний стан існує». HTTP 200, успішний виклик SDK або впевнене фінальне повідомлення не є постумовою.

Розглядайте записи в пам’ять як привілейовані дії

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

У липневій статті 2026 року MemGhost paper представлено WhisperBench — benchmark зі 108 випадків прихованої ін’єкції пам’яті через email workflows. Автори повідомляють про 87,5% end-to-end успішних атак на відкладеній вибірці проти однієї конфігурації OpenClaw і 71,4% проти однієї конфігурації Claude Code SDK. Також вони повідомляють про перенесення атак на інші системи пам’яті.

Ці показники не встановлюють універсальний рівень компрометації. Експерименти охоплюють конкретні моделі, архітектури агентів і workflow, орієнтований на email; у кількох оцінюваннях використовуються LLM judges, а стаття не тестує багатотижневе згасання пам’яті. Практичний висновок залишається чинним: недовірений вміст не повинен ставати довготривалою пам’яттю агента без provenance, валідації схеми, ізоляції tenant і явної політики запису.

Запис пам’яті має містити:

Дозволи мають витримувати відмови інструментів

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

ToolBench-X оцінює агентів за умов drift специфікації, помилок виклику, помилок виконання, drift вихідних даних і конфлікту між джерелами. У статті повідомляється, що агенти, які добре працюють із чистими інструментами, погіршують результати під дією цих загроз, тоді як цільові підказки для відновлення допомагають більше, ніж просте збільшення test-time compute. Це результат benchmark, а не частота інцидентів у production.

AgentTether досліджує невдалі траєкторії та контрольоване втручання під час виконання. На 261 завданні tau-bench автори повідомляють про виправлення 69,11% початково невдалих запусків Qwen — на 26,02 відсоткового пункта більше, ніж blind retry. Результати відрізняються залежно від домену, додаткові оцінювання спираються на іншу модель, а tau-bench не може відтворити кожен production toolchain.

Ці статті підтримують два засоби контролю:

Retry — це нове рішення щодо виконання, а не доказ того, що попередня дія була безпечною.

Відтворюваний workflow тестування дозволів

Виконайте ці тести перед увімкненням автономних записів:

Детерміновані метрики для агентів починають з’являтися в інструментах open-source оцінювання. У релізі DeepEval 4.1.3 від 12 липня 2026 року додано детерміновані `ToolPermissionMetric` і `AgentLoopDetectionMetric`. Цей реліз є сигналом упровадження, а не доказом того, що метрики охоплюють кожен сценарій зловживання.

Незалежна перевірка важлива не лише для безпеки. У цьому гібридному циклі AI code review як докази використовуються окремий reviewer і реальна збірка. Ширший системний висновок знову з’являється в Code Agents After 21.54 Billion Tokens: якість моделі не може замінити верифікацію та операційні межі.

Чекліст для production

AI Agent Security Cheat Sheet від OWASP доходить подібного операційного висновку: застосовуйте принцип найменших привілеїв, розділяйте ухвалення рішень і незворотне виконання, перевіряйте зовнішні вхідні дані, встановлюйте ліміти циклів і ведіть структуровані логи дій.

Чого ці докази не доводять

Наведені статті — це нещодавні препринти, а не усталені стандарти. Їхні вибірки, моделі, інструменти та benchmarks обмежують кожен числовий результат. Комерційна документація описує доступні засоби контролю, але не те, чи правильно їх використовує конкретне розгортання. Релізи GitHub та issue reports свідчать про активний інженерний тиск, а не про рівні відмов у всій екосистемі.

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

Перевірка тверджень

Джерела