Як захистити ШІ-агентів без довіри «за замовчуванням»
Якщо ШІ-агент отримує зовнішні дані через MCP-сервери й сам викликає робочі інструменти, звичайного захисту «по периметру» вже недостатньо. Для такого сценарію потрібен контроль кожної дії агента, адже його поведінка не завжди передбачувана.
Попросіть ІТ-команду перевірити три речі: чи очищуються вхідні та вихідні дані; чи має агент доступ лише до конкретних об’єктів, а не до всієї системи; чи автентифікується кожен виклик інструмента за допомогою криптографічної ідентичності. Окремо варто сканувати код та інфраструктурні конфігурації на вбудовані API-ключі й уразливі залежності.
Це потрібно агентам, які працюють із договорами, поштою, звітами або зовнішніми сервісами. Для звичайного чат-бота без доступу до корпоративних інструментів такий рівень контролю може бути зайвим.
Що таке BOLA і чому агент не повинен бачити все
Класифікація OWASP API1:2023 називає найпоширенішою вразливістю API broken object-level authorization (BOLA) — систему перевіряють, чи авторизований користувач узагалі, але не перевіряють, до якого саме об'єкта він звертається. Для ШІ-агента це працює так: якщо агенту дали право працювати з документами, він за замовчуванням може дотягнутися до будь-якого документа в системі, а не лише до того, який йому доручили в конкретному завданні.
Мітигація складається з двох частин: пайплайн очищення вхідних і вихідних даних (агент отримує лише те, що потрібно для завдання, і повертає лише дозволене) та сувора авторизація на рівні об'єкта — перевірка при кожному зверненні, а не одноразово на вході в систему. ІТ-команді варто поставити конкретне запитання:
Чи перевіряються права доступу при кожному виклику інструмента, чи лише один раз на старті сесії агента?Чи може агент дотягнутися до об'єкта — файлу, запису, листа, — який йому прямо не передали в завданні?
Криптографічна ідентичність замість довіри мережі
Другий рівень — автентифікація кожного виклику інструмента через криптографічну ідентичність, побудовану на стандарті SPIFFE. Агент у такій схемі не просто «знаходиться всередині корпоративної мережі» — традиційна довіра за периметром тут не діє, — а пред'являє криптографічний підпис на кожному окремому кроці.
Технічно це подвійна прив'язка mTLS і DPoP: mTLS підтверджує, що з'єднання встановив саме той сервіс, за який він себе видає, а DPoP прив'язує токен доступу до конкретного запиту, тому вкрадений токен не можна повторно використати з іншого місця. Для керівника, який не читає код, важливий результат, а не механізм: навіть якщо зловмисник перехопить трафік або вкраде токен агента, скористатися ним як легітимним викликом він не зможе.
Сканування від коду до хмари
Третій блок захисту — пошук вбудованих API-ключів і вразливих залежностей у самому коді та в інфраструктурних конфігураціях (IaC). Підхід описують як «code-to-cloud»: перевірка починається на рівні вихідного коду й продовжується аж до налаштувань хмарної інфраструктури, куди агент розгортається. Для такого сканування згадують інструмент Wiz ASPM.
Це закриває типову помилку впровадження: розробник лишає ключ доступу прямо в коді «для тесту», і цей ключ їде в продакшн разом з агентом, який уже має доступ до реальних договорів чи листування. Пайплайн сканування ловить такі ключі й уразливі залежності до того, як агент отримає бойовий доступ.
Коли цей рівень контролю зайвий
Усі три механізми виправдані, коли агент непередбачувано обробляє зовнішні, ненадійні дані через MCP-сервери — тобто отримує вхід ззовні системи й сам вирішує, який інструмент викликати далі. Це агенти, що читають вхідну пошту, зовнішні файли чи відповіді інших сервісів і на основі цього діють.
Якщо агент відповідає на запитання в межах заданого контексту й не викликає жодних робочих інструментів, повний набір цих трьох рівнів — зайва інженерна вартість: авторизацію на рівні об'єкта й криптографічну ідентичність варто впроваджувати саме там, де агент діє, а не там, де він тільки відповідає.