AI-агент з операційного погляду — це процес, який тримає облікові дані. Хтось надає йому службовий обліковий запис, ключ API чи роль IAM, щоб він міг виконувати свою роботу, і з цього моменту він може дотягнутися до всього, до чого дотягуються ці облікові дані. В описі завдання було сказано «щоночі експортувати білінгові дані». Облікові дані казали «читати та записувати у виробничу базу даних, і в об’єктне сховище, і в чергу». Ніхто не узгодив ці два. Через місяці ніхто в команді не може відповісти на питання, яке мало б бути тривіальним: до чого насправді може дотягнутися цей агент і чого він насправді торкається?
Цей розрив — не гіпотеза. Незалежні галузеві дослідження (CSA/Token) виявили, що приблизно 82% організацій мають запущені AI-агенти, про які вони не знають, тоді як лише близько 21% ведуть їхній інвентар у реальному часі. Ви не можете керувати тим, чого не бачите, а зараз більшість інфраструктур взагалі не бачать своїх агентів — не кажучи вже про ребра, що з’єднують кожного агента з ресурсами, до яких він може дотягнутися.
Три різні питання, які регулярно змішують
Причина, чому «до чого може дотягнутися цей агент» так складно відповісти, у тому, що воно зводить три окремі питання в одне. Тримати їх роздільно — у цьому вся суть.
- Held (тримає) — облікові дані, якими володіє агент. Токен, ключ, прив’язка ролі. Це факт ідентичності: до яких дверей агент має ключі.
- Permitted (дозволено) — те, що цим обліковим даним дозволено робити згідно з політикою: надані права IAM, ролі бази даних, мережеві правила. Це факт політики, і він майже завжди ширший, ніж хтось пам’ятає, бо надані права накопичуються, а ніхто їх не відкликає.
- Observed (спостережено) — те, що агента справді бачили за виконанням: до яких ресурсів він дотягувався і чи був кожен доступ читанням, чи записом. Це факт поведінки, і доки ви його не зберете, він просто ніде не існує.
Більшість засобів безпеки зупиняється на permitted. Вони читають ваш IAM і повідомляють, що агент міг би записувати у бакет білінгових експортів. Це необхідно, але недостатньо, бо «міг би» — це набір з тисяч прихованих можливостей, а людина не може розсортувати тисячі «можливо». Розмову змінює те, що ви ставите observed поруч із permitted і дивитеся на різницю.
Карта доступу
Карта доступу — це граф цих ребер: для кожного виявленого агента ребро до кожного ресурсу, до якого він може дотягнутися, з анотацією про те, що насправді спостерігалося на цьому ребрі. Одиниця, яка має значення, — це ребро, а найважливіша анотація на ребрі — це відмінність read/write.
R (read) означає, що агент отримав дані, не змінюючи їх: SELECT, GET, читання файлу. RW (read/write) означає, що він змінив стан: INSERT/UPDATE/DELETE, PUT в об’єктне сховище, міграцію схеми. Радіус ураження цих двох незіставний. Ребро на читання чутливої таблиці — це питання експозиції. Ребро на запис — особливо ненавмисне — це питання цілісності та інциденту. Ставлення до них як до однакового «доступу» — це те, як команди пропускають знахідку, яка мала значення.
Ось як виглядає рядок одного агента, коли карту вже побудовано:
| Агент | Ресурс | Permitted | Observed | Достовірність |
|---|---|---|---|---|
| data-export-job | prod-postgres | RW | RW | attributed |
| data-export-job | s3://billing-exports | RW | R | attributed |
| data-export-job | internal-metrics-api | R | — | approximate |
Подивіться на перший рядок. Завдання експорту було призначене читати з prod-postgres і записувати результат у s3://billing-exports. Читання з джерела, запис у призначення. Але облікові дані, які йому видали, надають RW на базі даних, і збирач спостерігав, як воно записує у prod-postgres — зміну у виробничій системі обліку, яку ніхто не переглядав, не мав на меті й наразі не може пояснити. Колонка permitted увесь час тихо казала, що це дозволено. Це зародок інциденту, що лежить на видноті, і без колонки observed немає нічого, що можна було б позначити.
Permitted мінус observed дорівнює дрейфу
Сигнатурний результат — це diff. Дрейф least-privilege — це те, що ви отримуєте, коли віднімаєте одну колонку від іншої, і він діє в обидва боки:
- Дозволено, але ніколи не спостерігалося — агент може дотягнутися до
internal-metrics-api, але за все вікно спостереження жодного разу цього не зробив. Це мертвий обсяг прав: надане право, яке ви можете безпечно запропонувати відкликати, скорочуючи поверхню атаки без зміни поведінки. - Спостерігалося понад те, що переглядали — запис у
prod-postgres, який ніхто не затверджував. Це показова знахідка: дія, яку, якби когось запитали під час надання прав, він не схвалив би.
Друга категорія — це головний ризик, і чесна версія продукту ніколи його не вигадує. Кожне спостережуване ребро несе рівень достовірності — attributed, коли дію прив’язано до конкретної ідентичності агента з підтверджувальним сигналом, approximate, коли докази слабші. Ви показуєте різницю замість того, щоб видавати здогад за впевненість. Знахідка, за яку ви не можете поручитися, гірша за відсутність знахідки.
Виявлено пасивно, атрибутовано на кожного агента
Два проєктні рішення роблять це гідним довіри, а не просто черговою панеллю.
По-перше, виявлення є пасивним. Збирач спостерігає — журнали, трасування OpenTelemetry, потоки аудиту бази даних на кшталт pgAudit від PostgreSQL та eBPF на рівні ядра як підстраховку з ground truth — і він не перебуває на шляху даних агента. Немає обов’язкового проксі. Якщо збирач відмовляє, агент продовжує працювати; деградує спостережуваність, а не виробниче середовище. Для системи, чия вся суть — керування критичною інфраструктурою, ця асиметрія і є проєктним рішенням: мінімальні ризики, сильний сигнал.
По-друге, кожну дію атрибутовано на конкретну ідентичність агента, а не на спільний службовий обліковий запис. Це різниця між журналом аудиту, який каже «роль експорту записала у prod-postgres о 02:14», і тим, який каже, який саме агент це зробив, під чиєю відповідальністю, у межах якого призначеного обсягу. Ідентичність на кожного агента — це передумова для того, щоб least-privilege узагалі щось означав: без неї дію можна побачити, але ніколи не простежити до відповідального власника.
Ребра та факти read/write — єдине, що зберігається. Карта записує відношення — агент до ресурсу, R чи RW — а не корисне навантаження, не рядки, які було прочитано, не секрети. Вхідні дані, що можуть містити секрети чи PII, редагуються та скануються на секрети, перш ніж щось буде записано. Граф є чутливим саме тому, що це карта доступу, тож його побудовано так, щоб тримати мінімум, який уможливлює керування, і нічого більше.
Сигнали з власної екосистеми агента допомагають, але самі по собі їм не довіряють. MCP-сервер може повідомляти, що інструмент доступний лише на читання, через анотації на кшталт readOnlyHint; згідно зі специфікацією MCP такі підказки є недовіреними і мають підтверджуватися, а не сприйматися сліпо. Саме погляд на рівні ядра ловить інструмент, який заявив, що доступний лише на читання, а записав попри це.
Щойно карта існує, наступний крок — застосування: закріплення завдання експорту на read-only у базі даних, відмова в записі та сповіщення замість простого журналювання — політика, застосована в момент доступу, а не реконструйована після інциденту.
agent "data-export-job" {
resource "prod-postgres" {
access = "read" # intended scope: read source only
deny = ["write", "ddl"]
}
resource "s3://billing-exports" {
access = "read-write" # intended scope: write destination
}
on_violation {
action = "block"
alert = "secops"
}
}Карта каже вам ту політику, яку ви мали б написати, бо вона показує вам той єдиний доступ, який агент насправді потребував, і десяток тих, якими він ніколи не скористався. Це різниця між тим, щоб здогадуватися про least-privilege, і тим, щоб виводити його з ground truth.
Якщо це і є те питання, на яке ваша інфраструктура сьогодні не може відповісти — до чого може дотягнутися кожен агент і чого він насправді торкається — то це саме те, для чого існує карта доступу. Огляд продукту проводить вас через виявлення та diff permitted-проти-observed; архітектура пояснює, як пасивний збір, ідентичність на кожного агента та журнал аудиту поєднуються між собою, ніколи не перебуваючи на шляху даних ваших агентів.