Перевірка викликів інструментів має встановлювати більше, ніж суму рахунку API. Перевірте, чи кожен запит даних пов'язаний із завданням агента та входить до схваленого обсягу доступу.
Для перевірки контрактів пов'яжіть запит реєстру з відповідною справою та задокументованою метою. Успішна відповідь API не доводить, що запит був авторизований.
Зберігайте рішення про дозвіл разом із записом виконання, щоб перевіряючий міг оцінити тодішні повноваження. Відновлення мети згодом саме по собі не доводить існування попередньої авторизації.
Коротко про головне
- Неконтрольовані виклики інструментів AI-агентів створюють три категорії прихованих витрат: фінансові, комплаєнс-пов’язані та відповідальність
- Витрати на розслідування й перевірку відрізняються від рахунку API та залежать від інциденту й наявних записів
- Безпека викликів інструментів вимагає шлюзів авторизації, а не просто обмежень швидкості
- Кожен виклик інструменту агентом повинен відповідати на питання: чи було це дозволено, ким, з якою метою?
- Для систем високого ризику стаття 12 вимагає журналювання важливих подій із простежуваністю відповідно до призначення
Три категорії прихованих витрат
Категорія 1: Фінансові (видимі витрати)
Більшість команд виявляють неконтрольовані виклики інструментів через рахунки. Агент з доступом до пошукових API, сервісів збагачення даних або зовнішніх баз даних може генерувати несподівано великі рахунки API, коли вирішує, що великий контекст корисний.
Це видимі витрати — вони з’являються в рахунках. Команди зазвичай вирішують це обмеженнями швидкості. Обмеження допомагають. Вони не вирішують основну проблему.
Категорія 2: Комплаєнс (невидимі витрати)
Рахунок API вимірює використання, а перевірка відповідності з'ясовує, які дані отримано, з якою метою та за чиїм дозволом. Плануйте операційний моніторинг і роботу з перевірки сумнівного доступу.
Правила обробки даних залежать від юрисдикції, ролі організації та конкретного доступу. Для HIPAA спершу встановіть статус covered entity або business associate; наявність медичної інформації сама по собі не визначає застосовність.
Категорія 3: Відповідальність (відкладені витрати)
Відповідальність матеріалізується, коли виклики інструментів агента сприяли рішенню, що завдало шкоди, а доказовий ланцюжок відсутній.
Що насправді означає безпека викликів інструментів
Обмеження швидкості та ліміти витрат вирішують фінансові ризики. Вони не вирішують безпеку AI agent tool call у значимому сенсі.
Безпека викликів інструментів AI-агентів має чотири виміри:
| Вимір | Питання | Поширена прогалина |
|---|---|---|
| Авторизація | Чи був цей виклик дозволений політикою? | У більшості команд немає формальної політики |
| Обсяг | Чи входить цей виклик у заявлені повноваження агента? | Доступ до інструментів часто ширший за необхідний |
| Докази | Чи є захищений від фальсифікації запис виклику з вхідними даними? | Журнали фіксують результати, не авторизацію |
| Мінімізація | Чи був це мінімальний необхідний доступ до даних? | Агенти тяжіють до максимального контексту |
Чому агенти надмірно викликають інструменти
AI-агенти навчені збирати контекст перед дією. Більше контексту зазвичай дає кращі результати. Без обмежень агент, що оптимізує якість завдання, буде шукати стільки контексту, скільки дозволяють доступні інструменти.
Це не дефект моделі — це раціональна оптимізація за відсутності обмежень управління. Обмеження — звертатись лише до даних за активними справами з задокументованою метою — повинно бути нав’язано ззовні.
Шлюзи авторизації правильно вирішують це. Обмеження швидкості уповільнює проблему. Шлюз авторизації зупиняє несанкціонований доступ до його вчинення.
Практична архітектура контролю
Мінімально необхідний набір контролів для безпеки викликів інструментів:
- Інвентаризація доступу до інструментів — Знайте, до яких інструментів має доступ кожен агент.
- Правила авторизації за кожним інструментом — Кожен інструмент повинен мати явні правила: за яких умов він дозволений?
- Оцінка до виклику — До кожного виклику інструменту шар управління оцінює виклик за правилами авторизації. PERMIT, DENY або ESCALATE — синхронно.
- Підписані записи викликів інструментів — Кожен дозволений виклик повинен виробляти підписаний запис доказів.
- Базова лінія аномалій — Знайте, як виглядає нормальний обсяг викликів інструментів для кожного агента.
Часті запитання
П: Чи охоплює стаття 12 EU AI Act виклики інструментів?
Події інструментів можуть бути важливими для простежуваності системи високого ризику за статтею 12. Обирайте контекст, потрібний для моніторингу ризиків і роботи; стаття не вимагає універсально зберігати кожен результат інструмента або повний вміст входів. Спеціальні мінімальні поля вхідних даних стосуються категорії віддаленої біометричної ідентифікації Додатку III.
П: Ми використовуємо managed agent platform. Хіба вона не обробляє журналювання викликів інструментів?
Managed-платформи зазвичай журналюють, що виклики інструментів відбулися. Вони не журналюють контекст авторизації, контекст мети або докази мінімізації даних. Це вимагає вашого шару управління.
П: Як обробляти виклики інструментів, чутливі до часу?
Вимірюйте затримку авторизації у реальному процесі. Попередня авторизація може зменшити повторні перевірки, але дозвіл має бути обмежений завданням, обсягом і строком дії та переглядатися за зміни контексту або політики.
Микола Ковтун, засновник Infracortex AI Studio. Cortex додає попередню оцінку авторизації та підписані записи доказів до викликів інструментів AI-агентів. Забронюйте дзвінок.
Дивіться також: Що таке шар підзвітності AI-агентів? | EU AI Act Стаття 12: вимоги до журналювання