Штучний інтелект дедалі глибше інтегрується в корпоративні процеси, а агентні системи, здатні самостійно планувати дії й викликати інструменти, стають новим стандартом. Але саме на стику цих «розумних» агентів із реальними, часто застарілими корпоративними системами виникає критична прогалина безпеки. IBM Technology у своєму роз’ясненні показує, як так званий «agentic last mile identity problem» фактично руйнує Zero Trust і чому без додаткових механізмів контролю підприємства відкриваються для атак.
Що таке «остання миля» для AI-агентів
Поняття «останньої милі» прийшло з телеком-індустрії: провайдери будували надшвидкі магістральні лінії, але не могли просто так «протиснути» гігабітний інтернет у старі будинки з давньою проводкою. Високошвидкісний «трак» є, а підключення до конкретної квартири — вузьке місце.
З агентними AI-системами відбувається щось подібне:
- На «фронті» є користувач, який працює через чат чи додаток.
- Далі — агент (A1) з LLM, що планує дії, викликає інструменти, звертається до MCP-сервера.
- За MCP — реальні бізнес-процеси й дані: CRM, білінг, ERP, внутрішні API, бази даних.
Саме підключення агентної системи до цих бекенд-сервісів і є «останньою милею». Більшість таких систем створювалися задовго до появи агентів: вони розраховані на взаємодію з класичними застосунками, а не з автономними AI-компонентами. У результаті виникає розрив між «розумною» частиною архітектури та старими механізмами доступу.
Як втрачаються ідентичність, контекст і делегування
На перший погляд, усе виглядає безпечно: користувач логіниться, система знає, хто він, які в нього права, а агент працює від його імені. Проблема починається там, де агент звертається до бекенду.
1. Зникає ідентичність користувача
У багатьох корпоративних системах взаємодія на «останній милі» побудована на:
- статичних API-ключах;
- спільних облікових даних між застосунками;
- сервісних акаунтах без прив’язки до конкретної людини.
На цьому рівні бекенд «бачить» лише застосунок або сервіс, але не кінцевого користувача. Інформація про те, хто ініціював дію в чаті, губиться. Отже:
- неможливо коректно застосувати політики доступу, прив’язані до користувача;
- ускладнюється аудит: важко відстежити, хто насправді змінив дані.
2. Втрачається намір (intent)
Агент працює з чітким наміром користувача: змінити пароль, оновити запис, запустити процес. Але коли запит доходить до бекенду через API-ключ, цей намір не передається як окремий, перевірюваний параметр.
Для бекенд-системи це просто черговий технічний виклик. Вона не «знає», що це, наприклад, «зміна пароля користувача X за його запитом», а не масове оновлення даних.
3. Зникає контекст
Контекст агентної системи — це:
- у якому середовищі працює агент;
- які інші сервіси залучені;
- які обмеження діють у поточній сесії.
На рівні старих систем цей контекст зазвичай не передається й не перевіряється. Бекенд не розуміє, у якому сценарії виконується операція, і не може адаптувати політики доступу до ситуації.
4. Немає явного делегування
У сучасній агентній архітектурі агент діє «від імені» користувача — це делегування повноважень. Але бекенд, що працює зі статичними ключами, не бачить:
- що дія виконується агентом;
- кому саме делеговано повноваження;
- у яких межах це делегування.
Усе це означає, що на «останній милі» руйнуються ключові принципи Zero Trust: система більше не перевіряє «хто», «що саме» і «в якому контексті» намагається зробити.
Чому це створює новий клас ризиків
Якщо залишити «останню милю» у традиційному вигляді, виникає кілька критичних наслідків.
Порушення Zero Trust
Zero Trust передбачає постійну перевірку:
- ідентичності;
- контексту;
- прав доступу для кожної операції.
Коли бекенд працює лише з технічними ключами, він фактично довіряє усьому, що приходить від «свого» застосунку або MCP. Це суперечить самій ідеї Zero Trust і відкриває шлях до зловживань.
Ланцюжки інструментів без контролю
Якщо агент може вільно викликати різні інструменти й API, а бекенд не бачить контексту й наміру, з’являється можливість:
- будувати довгі ланцюжки викликів між сервісами;
- комбінувати інструменти у спосіб, який не передбачався розробниками;
- обходити логіку доступу, розраховану на «ручні» сценарії.
Без чіткої перевірки на кожному кроці агент може стати «суперконектором», який зшиває системи в небезпечні конфігурації.
Новий вектор атак через «шкідливих агентів»
Сценарій, який особливо турбує безпекові команди:
- у систему потрапляє зловмисний або скомпрометований агент;
- він звертається до MCP чи іншого оркестратора, «представляючись» легітимним;
- далі просить підключити його до бекенд-процесів і даних, використовуючи наявні механізми доступу.
Якщо «остання миля» не перевіряє ідентичність, контекст і делегування, такий агент може отримати доступ до критичних систем, не будучи повноцінно автентифікованим і авторизованим.
Як закрити прогалину: політики, vault і телеметрія
Щоб зберегти Zero Trust у світі агентних систем, недостатньо просто «прикрутити» AI до існуючих API. Потрібна проміжна ланка, яка повертає в гру ідентичність, контекст і делегування.
Політики доступу: ABAC і PBAC
Перший крок — зробити доступ до бекенд-систем політично керованим:
- ABAC (Attribute-Based Access Control) — контроль доступу на основі атрибутів:
- користувача (роль, відділ, рівень доступу);
- середовища (час, місце, тип клієнта);
- ресурсу (тип даних, чутливість).
- PBAC (Policy-Based Access Control) — ширший підхід, коли рішення про доступ приймаються на основі формалізованих політик, що враховують набір атрибутів і умов.
Такі політики мають застосовуватися саме на рівні «останньої милі», щоб бекенд не просто «довіряв ключу», а оцінював:
- хто реальний суб’єкт операції;
- у якому контексті вона виконується;
- чи відповідає це дозволеним сценаріям.
Vault як шлюз між агентами й бекендом
Ключовий елемент запропонованого підходу — додати між агентною системою та інструментами vault:
- Агент більше не звертається безпосередньо до бекенд-інструментів.
- Натомість він звертається до vault, який:
- приймає інформацію про користувача, аудиторію, claims;
- перевіряє ідентичність, контекст і делегування;
- застосовує політики ABAC/PBAC;
- керує обліковими даними для бекенду.
Vault стає «мостом» між новим агентним світом і старими корпоративними системами, не змушуючи останні радикально змінюватися.
Короткострокові облікові дані замість статичних ключів
Одна з найважливіших функцій vault — керування обліковими даними:
- Замість довгоживучих API-ключів і спільних паролів використовуються:
- короткострокові креденшіали;
- ротація доступів;
- динамічна видача прав під конкретний запит.
- Сценарій роботи:
- Користувач формулює запит.
- Агент визначає намір і потрібні дії.
- Vault перевіряє ідентичність, контекст, делегування й політики.
- Vault видає короткостроковий доступ до потрібного бекенд-ресурсу.
- Після виконання операції доступ автоматично «старіє» і стає непридатним.
Це дозволяє зменшити площу атаки: навіть якщо облікові дані будуть скомпрометовані, їхня цінність обмежена в часі й обсязі прав.
Телеметрія як зворотний зв’язок для політик
Останній елемент — телеметрія:
- збір даних про те, як користувачі й агенти реально взаємодіють із системою;
- фіксація викликів, послідовностей інструментів, аномальних сценаріїв.
Ця телеметрія:
- повертається в систему політик;
- дозволяє:
- звужувати права доступу;
- відмовляти в підозрілих запитах;
- адаптувати правила до реальних патернів використання.
Таким чином, архітектура стає самокоригувальною: чим більше агентна система працює, тим точнішими стають політики доступу.
Висновок
Агентні AI-системи вже сьогодні інтегруються з реальними бізнес-процесами, але саме «остання миля» — підключення до старих корпоративних систем — перетворюється на слабку ланку. Втрата ідентичності користувача, наміру, контексту й делегування на цьому етапі фактично ламає Zero Trust і створює новий клас ризиків: від неконтрольованих ланцюжків інструментів до атак через «шкідливих агентів».
Щоб уникнути цього, підприємствам доводиться переосмислювати архітектуру доступу: впроваджувати ABAC/PBAC, додавати vault як проміжний рівень керування обліковими даними й будувати замкнутий цикл телеметрії та політик. Лише так агентні системи зможуть безпечно співіснувати з багаторічними корпоративними платформами, не перетворюючи їх на мішень для атак.
Джерело
Why AI Agents Break Zero Trust at the Last Mile — IBM Technology