Багатоагентні системи штучного інтелекту вже працюють з чутливими даними — від медичних записів до фінансових історій. Але разом з гнучкістю з’являється новий клас загроз: «розгублений заступник» (confused deputy), коли цілком легітимний агент несвідомо стає каналом витоку даних. Канал IBM Technology на прикладі проєкту Kagenti показує, як закривати цю діру за допомогою відкритої інфраструктури безпеки.
Проблема «розгубленого заступника» в агентних системах
«Розгублений заступник» — це ситуація, коли суб’єкт із законними правами доступу використовується для запиту, який не повинен мати таких повноважень. У контексті агентних AI‑систем це проявляється особливо небезпечно.
Уявімо лікарню з агентною системою для виставлення рахунків пацієнтам. Оркеструючому агенту видають bearer‑токен, що дозволяє читати медичні записи. Щоб виконати задачу, цей агент залучає кількох субагентів. Один з них — агент, який має лише перевірити, чи є у пацієнта страховка.
Через те, що токен «їде» разом із контекстом запиту ланцюжком між агентами, агент перевірки страховки раптово отримує доступ до повних медичних записів — хоча за задумом ніколи не мав бачити ці дані. Формально все виглядає як «нормальна» авторизована активність, і журнали аудиту не підсвічують інцидент.
У традиційних мікросервісах таку проблему зменшує статична топологія: є чіткий граф викликів, мережеві сегментації та наперед прописані дозволи між сервісами. Агентні системи працюють інакше: цінність агента саме в тому, що він сам вирішує, що робити далі. Наперед описати всі можливі шляхи запитів практично неможливо — отже, обв’язати безпеку навколо «шляху» не виходить.
Висновок: замість спроб контролювати топологію потрібно змістити фокус на контроль ідентичності й делегації.
Kagenti: безпека навколо агента, а не коду
Kagenti пропонує інфраструктурний підхід: ви «приносите» власних агентів, незалежно від фреймворку, а платформа накладає на них шар безпеки. Агент може бути доставлений із GitHub‑репозиторію чи контейнерного образу — сам код чіпати не потрібно.
Платформа спирається на чотири стовпи:
- життєвий цикл та оркестрація;
- мережа;
- безпека;
- спостережуваність (observability).
Ключове для боротьби з «розгубленим заступником» — саме безпековий блок, який реалізується через два сайдкари, що автоматично розгортаються поруч із кожним агентом.
SPIFFE: криптографічна ідентичність замість статичних ключів
Перший сайдкар — реалізація SPIFFE (Secure Production Identity Framework for Everyone). Він видає агенту криптографічну ідентичність у вигляді X.509‑сертифіката — SPIFFE Verifiable Identity Document.
Це:
- не ім’я користувача та пароль;
- не статичний API‑ключ, який легко скопіювати й роками зловживати;
- короткоживучий сертифікат, прив’язаний до конкретного робочого навантаження, простору імен і сервісного акаунта.
Агент доводить, хто він такий, так само як банк у браузері — через TLS‑сертифікат, а не через секрет у середовищі.
OAuth2 через Keycloak: контрольований доступ до інструментів
Другий сайдкар — клієнтська реєстрація Kagenti. Він реєструє агента як OAuth2‑клієнта в Keycloak — відкритій системі керування ідентичностями та доступом. Це дає змогу запитувати обмежені токени для конкретних інструментів, а не роздавати широкі «мастер‑ключі».
Обидва компоненти працюють «під капотом»: розробнику не потрібно вручну вбудовувати складну авторизацію в агентний код.
AuthBridge і делегаційні ланцюги: як блокується «зайвий» доступ
Ключова новація Kagenti — компонент AuthBridge, який фактично «прикручує» до кожного запиту повний ланцюг делегації.
Що відбувається при виклику інструмента агентом:
- AuthBridge автоматично додає заголовок до кожного вихідного запиту.
- У цьому заголовку зафіксовано:
- хто саме викликає (наприклад, агент D),
- ким він був викликаний (агент A),
- від імені якого користувача працює система,
- повний ланцюг делегації, криптографічно підписаний.
Коли запит доходить до, скажімо, сервісу доступу до медичних записів або до шлюзу перед ним, політика доступу перевіряє не лише поточного агента, а всю делегаційну історію:
- чи має право агент A працювати з цим ресурсом?
- чи має право агент D взагалі торкатися пацієнтських даних?
- чи дозволено таку операцію конкретному користувачу?
Якщо служба політик визначає, що агент D не повинен бачити медичні записи, запит блокується — навіть якщо агент D фактично тримає в руках «валідний» токен, який просто протік у контексті.
Це принципово відрізняється від класичного RBAC (role‑based access control), де права задаються статично і очікується відомий наперед граф викликів. У динамічному агентному середовищі це не працює, тоді як підхід із делегаційними ланцюгами спирається на те, що ідентичність подорожує разом із запитом.
Інфраструктура навколо: MCP‑шлюз, Istio, OpenTelemetry
Kagenti поєднує кілька відкритих технологій, щоб зробити цей підхід практичним у продакшені.
AuthBridge на етапі деплою забезпечує:
- отримання й ротацію SPIFFE‑сертифікатів;
- реєстрацію OAuth2‑клієнта в Keycloak;
- запуск Envoy‑проксі, яке перевіряє вхідні токени ще до того, як запит потрапить до контейнера з агентом. Код агента при цьому залишаєтсья незмінним.
На боці інструментів працює MCP‑шлюз, який сидить перед такими сервісами, як, наприклад, інструмент доступу до медичних записів. Він:
- маршрутизує виклики до потрібних інструментів;
- обмежує частоту запитів (rate limiting);
- централізовано перевіряє токени.
Заміна інструмента перетворюється фактично на зміну одного URL.
Мережеву взаємодію забезпечує Istio в ambient‑режимі. Усі з’єднання між агентами й інструментами:
- шифруються;
- проходять взаємну аутентифікацію;
- працюють поверх стандартного HTTP, без ручного налаштування для кожного pod.
Оскільки трафік стандартизований, OpenTelemetry може автоматично інструментувати його, призначаючи єдиний trace ID, який проходить крізь увесь шлях запиту. Kagenti постачає:
- Phoenix — для наскрізного трейсингу агентів;
- MLflow — для трекінгу експериментів з AI‑моделями.
Це дає змогу не лише зупиняти небажані запити, а й відстежувати, що саме сталося і хто санкціонував кожен крок.
Важливий акцент — усі компоненти стеку є відкритими й ліцензовані за Apache, а Kagenti виступає «клеєм», який зв’язує їх у цілісну платформу для безпеки багатoагентних систем.
Джерело
YouTube: Kagenti’s Approach to Multi-Agent Security for AI Agents