Прихована вартість неконтрольованих викликів інструментів AI-агентів
У березні 2026 року компанія у сфері юридичних технологій виявила, що її агент для перевірки контрактів запитував сторонній API корпоративного реєстру 4 700 разів за три дні — для організацій, не пов’язаних з жодною активною справою. Ніхто це не авторизовував. Агент вирішив, що додатковий контекст буде корисним.
Загальний рахунок за API склав $940. Проблема з відповідністю виявилась серйознішою: агент отримав доступ до даних компаній, з якими у фірми не було клієнтських відносин. Відповідно до політики конфлікту інтересів, це вимагало документування мети та авторизації. Ні того, ні іншого не існувало.
$940 було легко пояснити. Реконструкція несанкціонованого доступу до даних зайняла чотири дні роботи юридичної та комплаєнс-команди.
TL;DR
- Неконтрольовані виклики інструментів AI-агентів створюють три категорії прихованих витрат: фінансові, комплаєнс-пов’язані та відповідальність
- Вартість відповідності незмінно більша за фінансову — але невидима до аудиту або інциденту
- Безпека викликів інструментів вимагає шлюзів авторизації, а не просто обмежень швидкості
- Кожен виклик інструменту агентом повинен відповідати на питання: чи було це дозволено, ким, з якою метою?
- Стаття 12 EU AI Act вимагає журналювання вхідних даних, що використовуються в AI-рішеннях — вихідні дані викликів інструментів підпадають під цю вимогу
Три категорії прихованих витрат
Категорія 1: Фінансові (видимі витрати)
Більшість команд виявляють неконтрольовані виклики інструментів через рахунки. Агент з доступом до пошукових API, сервісів збагачення даних або зовнішніх баз даних може генерувати несподівано великі рахунки API, коли вирішує, що великий контекст корисний.
Це видимі витрати — вони з’являються в рахунках. Команди зазвичай вирішують це обмеженнями швидкості. Обмеження допомагають. Вони не вирішують основну проблему.
Категорія 2: Комплаєнс (невидимі витрати)
Вартість відповідності для неконтрольованих викликів інструментів майже завжди більша за фінансові витрати. Вона з’являється пізніше, коли хтось запитує: «До яких даних звертався ваш агент і чому?»
Якщо агент звертався до персональних даних → питання щодо мінімізації даних GDPR/CCPA. До фінансових даних із зовнішніх джерел → фінансові регуляції щодо джерел даних. До медичної інформації → вимоги HIPAA. До корпоративної інформації третіх сторін → документування конфлікту інтересів.
Категорія 3: Відповідальність (відкладені витрати)
Відповідальність матеріалізується, коли виклики інструментів агента сприяли рішенню, що завдало шкоди, а доказовий ланцюжок відсутній.
Що насправді означає безпека викликів інструментів
Обмеження швидкості та ліміти витрат вирішують фінансові ризики. Вони не вирішують безпеку AI agent tool call у значимому сенсі.
Безпека викликів інструментів AI-агентів має чотири виміри:
| Вимір | Питання | Поширена прогалина |
|---|---|---|
| Авторизація | Чи був цей виклик дозволений політикою? | У більшості команд немає формальної політики |
| Обсяг | Чи входить цей виклик у заявлені повноваження агента? | Доступ до інструментів часто ширший за необхідний |
| Докази | Чи є захищений від фальсифікації запис виклику з вхідними даними? | Журнали фіксують результати, не авторизацію |
| Мінімізація | Чи був це мінімальний необхідний доступ до даних? | Агенти тяжіють до максимального контексту |
Чому агенти надмірно викликають інструменти
AI-агенти навчені збирати контекст перед дією. Більше контексту зазвичай дає кращі результати. Без обмежень агент, що оптимізує якість завдання, буде шукати стільки контексту, скільки дозволяють доступні інструменти.
Це не дефект моделі — це раціональна оптимізація за відсутності обмежень управління. Обмеження — звертатись лише до даних за активними справами з задокументованою метою — повинно бути нав’язано ззовні.
Шлюзи авторизації правильно вирішують це. Обмеження швидкості уповільнює проблему. Шлюз авторизації зупиняє несанкціонований доступ до його вчинення.
Практична архітектура контролю
Мінімально необхідний набір контролів для безпеки викликів інструментів:
- Інвентаризація доступу до інструментів — Знайте, до яких інструментів має доступ кожен агент.
- Правила авторизації за кожним інструментом — Кожен інструмент повинен мати явні правила: за яких умов він дозволений?
- Оцінка до виклику — До кожного виклику інструменту шар управління оцінює виклик за правилами авторизації. PERMIT, DENY або ESCALATE — синхронно.
- Підписані записи викликів інструментів — Кожен дозволений виклик повинен виробляти підписаний запис доказів.
- Базова лінія аномалій — Знайте, як виглядає нормальний обсяг викликів інструментів для кожного агента.
Часті запитання
П: Чи охоплює стаття 12 EU AI Act виклики інструментів?
Стаття 12 вимагає журналювання «вхідних даних», що використовуються в AI-рішеннях. Вихідні дані викликів інструментів, що інформують рішення агента, кваліфікуються як вхідні дані. Необроблені журнали викликів, що захоплюють лише виклик та його статус, не відповідають вимогам — потрібні вхідні дані та контекст авторизації.
П: Ми використовуємо managed agent platform. Хіба вона не обробляє журналювання викликів інструментів?
Managed-платформи зазвичай журналюють, що виклики інструментів відбулися. Вони не журналюють контекст авторизації, контекст мети або докази мінімізації даних. Це вимагає вашого шару управління.
П: Як обробляти виклики інструментів, чутливі до часу?
Паттерн попередньої авторизації працює добре: агент оголошує намічені виклики інструментів на початку завдання, шар управління попередньо оцінює та авторизує валідні, і агент продовжує з перевіреним набором дозволів.
Микола Ковтун, засновник Infracortex AI Studio. Cortex додає попередню оцінку авторизації та підписані записи доказів до викликів інструментів AI-агентів. Забронюйте дзвінок.
Дивіться також: Що таке шар підзвітності AI-агентів? | EU AI Act Стаття 12: вимоги до журналювання
Cortex build: 0.1.35-260423
