Більшість команд відкриває для себе один і той самий незручний факт в однаковому порядку. Спершу вони усвідомлюють, що AI-агенти вже працюють по всій їхній інфраструктурі, викликають моделі, відкривають MCP-сервери, тягнуться до баз даних та об’єктних сховищ. Потім вони намагаються інвентаризувати їх і виявляють, що жодного списку немає. Незалежні галузеві дослідження (CSA/Token, n=418) дають цифри щодо цього розриву: приблизно 82% організацій мають запущені агенти, про які вони не знають, і лише близько 21% ведуть інвентаризацію в реальному часі. Перш ніж керувати чимось із цього, вам потрібно це побачити. Питання в тому, як отримати таку видимість, не погіршуючи ситуацію.
Існує дві чесні відповіді, і вони перебувають на протилежних кінцях спектра ризику.
Два способи побачити агента
Перший — це вбудований проксі. Ви спрямовуєте трафік агента через компонент, який контролюєте, і оскільки кожен запит та відповідь проходять через нього, ви можете бачити, формувати й блокувати в реальному часі. Це легітимний, потужний дизайн. Саме так сьогодні забезпечується чимало вихідної фільтрації, брокерингу секретів та політик на рівні запитів.
Другий — це пасивне виявлення. Замість того, щоб стояти в потоці, ви спостерігаєте за ним збоку: OpenTelemetry, яку агент уже видає, рідні журнали аудиту систем, до яких він звертається (PostgreSQL pgAudit, хмарні журнали аудиту на кшталт AWS CloudTrail, аудит Kubernetes), та сигнали рівня ядра через eBPF як підстраховку з достовірними даними. Ви ніколи не термінуєте з’єднання. Ви спостерігаєте за тим, що сталося, і реконструюєте, хто до чого звертався.
Різниця, яка має значення, полягає не в тому, скільки кожен підхід може побачити в найкращому випадку. Вона полягає в тому, що відбувається, коли сам шар видимості виходить з ладу.
Радіус ураження — це справжня вісь
Вбудований проксі за своєю конструкцією перебуває в шляху даних. Це дає контроль у реальному часі, і це коштує вам спільного режиму відмови. Якщо проксі повільний, ваші агенти повільні. Якщо він падає, безпечним замовчуванням зазвичай є fail closed, що означає, що ваші агенти зупиняються, або fail open, що означає, що ваш контроль тихо зникає в найгірший момент. У будь-якому разі компонент видимості тепер поділяє радіус ураження з продакшеном. Він також додає крок затримки до кожного виклику та поверхню розгортання, яку хтось має експлуатувати, масштабувати й патчити на критичному шляху.
Пасивне виявлення має протилежний профіль. Колектор перебуває поза основним каналом і працює за принципом «спочатку читання»: він читає телеметрію, журнали аудиту та події ядра; він не пересилає й не переписує трафік агента. Якщо він деградує чи помирає, ніщо в шляху запиту не змінюється. Ви втрачаєте свіжу видимість до його відновлення, а не пропускну здатність, не доступність. Ось що означає на практиці «спочатку читання, низький асиметричний ризик»: немає висхідного ризику для продакшену з боку того, чия єдина робота — спостерігати.
| Вбудований проксі | Пасивне виявлення | |
|---|---|---|
| Позиція | У шляху даних | Поза основним каналом, поруч |
| Блокування в реальному часі | Рідне | Потребує забезпечення на точці доступу |
| Додана затримка | Так, на кожен виклик | Жодної |
| Якщо виходить з ладу | Агенти зупиняються або контроль зникає | Видимість застаріває; агенти не зачеплені |
| Покриття безшумних шляхів | Високе (він термінує потік) | Залежить від видаваних сигналів + підстраховки eBPF |
Саме тому позиція продукту — жодного обов’язкового проксі, а не «проксі марні». Існують шляхи, де вбудований компонент є правильним рішенням, і вони компонуються. Але виявлення — частина, якій ніколи не можна дозволяти вивести з ладу те, що вона інвентаризує, — це неправильна робота, щоб начіпляти її на критичний шлях.
Компроміс, викладений чесно
Пасивне виявлення має справжню слабкість, і вдавати інакше було б тим різновидом солом’яного опудала, через який дизайн починають тихо не довіряти. Проксі, що термінує потік, бачить кожен його байт. Пасивний колектор бачить лише те, що агент, його середовище виконання чи ресурс вирішили видати. На повністю некооперативному шляху, який мало журналює й не видає корисної телеметрії, виявлення на рівні застосунку рідшає. Ви можете зробити висновок, що щось сталося, але атрибуція стає складнішою.
Дві речі тримають це чесним, а не фатальним.
Перша — це підстраховка ядра на eBPF. Журнали застосунків можуть бути неповними, затриманими або, у ворожому випадку, навмисно придушеними. Ядро не можна ввічливо попросити забути системний виклик. Агент, що відкриває сокет до бази даних або записує файл, залишає слід на межі системного виклику незалежно від того, що його журналювання вирішило зафіксувати. Це робить eBPF достовірними даними проти ухиляння: коли сигнали вищого рівня розходяться чи замовкають, представлення з ядра є шаром підтвердження. Це також причина, чому анотації MCP-інструментів на кшталт readOnlyHint і destructiveHint, корисні як підказки, трактуються як недовірені згідно зі специфікацією MCP. Інструмент, який заявляє, що працює лише на читання, а спостерігається, що він записує, — це саме та розбіжність, яку варто винести на поверхню, і ви вловлюєте її лише тоді, коли підтверджуєте заяву проти того, що сталося насправді.
Друга — це чесні рівні достовірності. Не кожне спостереження заслуговує на однакову вагу, тож карта доступу не вдає, що це так. Ребро, підкріплене сигналом ядра й відповідним записом аудиту, позначається як атрибутоване; ребро, виведене з часткової телеметрії, позначається як приблизне. Продукт ніколи не відмиває здогад до факту. Рецензент має бути здатним з одного погляду побачити, наскільки довіряти кожному рядку.
Від спостереження до різниці, що має значення
Виявлення — це лише вхідні дані. Вихідними даними є порівняння між PERMITTED, тим, що дозволяє політика, і OBSERVED, тим, що колектор насправді побачив. Ця різниця є дрейфом від принципу найменших привілеїв, і ключовим випадком є спостережений запис, який політика ніколи не надавала й ніхто не переглядав.
Кілька рядків зі стрічки доступу роблять це конкретним. Читання — рутина; позначений запис — ось у чому суть:
agent action resource outcome confidence
data-export-job READ s3://billing-exports allowed attributed
data-export-job READ prod-postgres allowed attributed
data-export-job WRITE prod-postgres flagged attributed
support-rag READ internal-wiki-mcp allowed approximateЗавдання експорту, що читає продакшн-базу даних, не викликає запитань. Те саме завдання, що записує до неї, коли політика будь-коли надавала лише читання, — це той різновид ребра, яке ніколи не повинне проходити без перегляду. Оскільки запис підтверджується на межі ядра, він позначається як attributed, а не як припущення.
Побачити дрейф — це половина роботи; закрити його — інша половина. Забезпечення належить точці доступу, виражене як policy-as-code, тож правило є переглядовним, а порушення опрацьовується, а не просто журналюється:
policy "data-export-readonly" {
agent = "data-export-job"
resource = "prod-postgres"
allow = ["read"]
deny = ["write"]
on_violation = "block + alert"
}Пасивне виявлення знаходить недозволений запис; політика повертає агента назад до найменших привілеїв і блокує наступний. Видимість і контроль залишаються окремими завданнями, що саме й є причиною, чому шар виявлення може дозволити собі працювати за принципом «спочатку читання».
Висновок
Видимість AI-агентів — це рішення щодо ризику ще до того, як воно стає рішенням щодо функціональності. Вбудований проксі дає вам контроль у реальному часі ціною поділу радіуса ураження з продакшеном. Пасивне виявлення поступається певним охопленням на безшумних шляхах в обмін на нездатність будь-коли вивести продакшн з ладу, а потім закриває більшу частину цього охоплення підстраховкою з достовірними даними на eBPF та рівнями достовірності, що залишаються чесними щодо того, що було побачено насправді. Для інвентаризації — шару, чия вся робота полягає в спостереженні, — ця асиметрія є правильним замовчуванням.
Якщо ви хочете повну картину того, як колектори, карта доступу та реєстр аудиту поєднуються між собою, огляд архітектури проходить через це від початку до кінця.