Аналітики VentureBeat AI стверджують, що звичне управління доступом (identity and access management, IAM), побудоване під людей і статичні сервісні акаунти, не витримує зіткнення з автономними AI-агентами — і пропонують перенести контроль на інший рівень: не стежити за тим, що робить агент, а обмежувати те, до яких даних він взагалі може дотягнутися. За даними VentureBeat AI, це не косметичне уточнення термінології, а інша архітектура безпеки — governance переїжджає із шару застосунку в шар даних.
Логіка стає зрозумілою, якщо подивитися, як агент насправді працює. Співробітник заходить у CRM під своїм логіном, і IAM-система щоразу звіряє, чи має саме ця людина право бачити саме цей запис. AI-агент діє інакше: він отримує завдання, самостійно вирішує, які API викликати, комбінує дані з кількох джерел за один прохід і ухвалює проміжні рішення, яких ніхто наперед не прописував покроково. Описати правилами кожну можливу послідовність дій такого агента — це перегони, які правила завжди програють, тому що варіантів поведінки більше, ніж хтось встигне занести в політику доступу.
Тому пропозиція VentureBeat AI зводиться до зміни самої одиниці контролю: не «що агенту дозволено робити», а «що агент бачить, коли дивиться на дані» — незалежно від того, яким шляхом він до них дістався.
Чому контроль дій агента не встигає за його автономністю?
Традиційний IAM розрахований на передбачувані сценарії доступу: людина або сервіс виконує обмежений, наперед відомий набір операцій, і правила легко звести до списку дозволених дій. Агент цю модель ламає — він викликає інструменти в комбінаціях, які розробник системи міг і не передбачити, і кожна нова інтеграція (новий API, нова база, новий MCP-сервер) розширює простір можливих дій швидше, ніж команда встигає його переглянути й затвердити.
У результаті політики доступу, написані під конкретні дії, застарівають ще до того, як їх встигають розгорнути в продакшн. Агент або впирається в надто жорсткі обмеження й перестає виконувати корисну роботу, або — що небезпечніше — отримує надлишкові права «про запас», щоб не блокувати легітимні сценарії.
Як виглядає governance, вбудований у шар даних?
Governance на рівні даних означає, що правило доступу прив'язане не до ендпоінта чи функції, а до самого запису, поля або документа — і діє однаково незалежно від того, хто чи що до нього звертається: людина через дашборд, бекенд-сервіс чи AI-агент через ланцюжок викликів інструментів. Замість «агенту дозволено викликати цей API» система перевіряє «чи має ця сутність право бачити ці конкретні дані прямо зараз».
- Обмеження живе разом із даними (row-level, column-level, field-level політики), а не в окремому шарі бізнес-логіки застосунку.
- Агент не може обійти governance, знайшовши інший маршрут до тих самих даних — це знімає ризик «якщо не через один API, то через інший».
- Аудит спрощується: видно, до яких даних агент фактично мав доступ у момент дії, а не лише які функції теоретично були йому дозволені.
Що це означає для команд, які будують agentic-системи вже сьогодні?
Практичний висновок для тих, хто підключає AI-агентів до внутрішніх систем: замість того щоб писати політики під кожну можливу дію агента, варто спершу відповісти на простіше питання — до яких саме даних цій ролі агента взагалі потрібен доступ, і обмежити саме це. Це той самий принцип найменших привілеїв, який давно застосовують до людей, але поширений тепер на нелюдських акторів, чия поведінка непередбачувана за визначенням.
Це особливо актуально там, де агент уже отримав широкий доступ до внутрішніх систем компанії — ризики такого підходу ми розбирали в матеріалі про те, чому AI-агенти для коду стали ризиком для корпоративних мереж. Той самий принцип «менше доступу — менше блок-радіус» працює й у зворотному напрямку: коли зловмисник компрометує сам агент чи інструмент, яким він користується, як це сталося з компаніями, зламаними через код від Cursor AI, обмежений на рівні даних доступ визначає, наскільки далеко зможе зайти атака, навіть якщо сам агент повністю скомпрометований.
Висновок AiiN: що це змінює для тих, хто вже підключив агентів до бізнес-даних
Наша теза проста: якщо ваша команда досі описує безпеку агента списком дозволених дій, ви будуєте систему, яка гарантовано відстає від власної автономності агента. Дії можна комбінувати нескінченно, а от набір даних, до яких у ролі агента є легітимна потреба, — величина скінченна й перевірювана. Governance, прив'язаний до даних, а не до функцій, — це єдиний спосіб зробити безпеку агентної системи такою ж масштабованою, як і саму систему.
Що таке governance на рівні даних простими словами?
Це підхід до безпеки, за якого правило доступу прикріплюється безпосередньо до даних (запису, поля, документа), а не до конкретної функції чи API-ендпоінта. Незалежно від того, яким шляхом сутність — людина, сервіс чи AI-агент — намагається дістатися даних, перевіряється те саме правило.
Чи означає це, що традиційний IAM більше не потрібен?
Ні, IAM і далі відповідає за автентифікацію та базову ідентифікацію — хто або що взагалі звертається до системи. Governance на рівні даних доповнює його там, де IAM бракує гнучкості: коли контролювати треба не факт доступу, а те, що саме сутність бачить і робить із конкретними даними.