Безпечне відкриття інструментів для корпоративних AI-агентів: реєстр, шлюз та політики.
Дизайн для агентів фінансових послуг: реєстр інструментів, фільтроване відкриття, детерміністичний шлюз інструментів, авторизація на рівні наміру та стійкі побічні ефекти.
Джерела: From Chatbots to Action-Bots: Designing Safe Tool Discovery and Authorization for Agentic AI
Питання, що стоїть за інструментами агента
Якщо надати агенту кілька API та дозволити моделі вибрати, які з них використати, то доступ до інструментів здається вирішеним питанням. Однак ситуація змінюється у корпоративних середовищах, де каталог містить сотні чи тисячі інструментів. Деякі з них — це безневинні інструменти лише для читання, інші можуть змінювати дані клієнтів чи конфіденційну інформацію, а ще менша кількість — розпочинати фінансові транзакції, переконфігурувати рахунки чи виконувати адміністративні операції. «Як агент знаходить правильний інструмент?» — це просте питання. Складніше — як гарантувати, що агент бачитиме та використовуватиме лише ті інструменти, які йому дозволено для виконання конкретного запиту користувача.
Саме це досліджується тут у рамках дизайн-дослідження. Це обґрунтована архітектура для сфери фінансових послуг, і її не слід сприймати як звіт про вже впроваджену систему оплат.
Утримувати модель поза межами системи безпеки
Промислова машинне навчання дає важливий урок: критично важливі для бізнесу процеси не знаходяться всередині моделі. Модель може прогнозувати, рекомендувати чи класифікувати, тоді як безпека, перевірка, бізнес-правила, авторизація та обробка транзакцій належать до детерміністичного програмного забезпечення, що знаходиться поза нею. Агенти роблять ці правила суворішими, а не більш послабленими, оскільки вони можуть вживати дій. Штучний інтелект високого рівня може бути сильним аналітиком, проте все одно залишатися поганим вибором для забезпечення безпеки корпоративної системи.
Проста фінансова ситуація пояснює це. Клієнт просить агента переглянути нещодавню транзакцію та сказати, чи було здійснено повернення грошей. Агент має зрозуміти запит та використати інструменти пошуку клієнтів та транзакцій, що є звичайною практикою.
Тепер змініть запит: якщо повернення коштів ще не відбулося, здійсніть його. Агент більше не просто збирає інформацію, адже це може мати фінансові наслідки. Ця невелика зміна підкреслює принцип, на якому ґрунтується все інше:
Агент може обміркувати дію та запропонувати її. Чи буде ця дія справді виконана, вирішує детерміністична платформа.
Розділення між обмірковуванням та виконанням дозволяє системі використовувати те, у чому сильні ШІ, не покладаючись на них у завданнях, які вони не можуть виконувати надійно.
Реєстр інструментів замість величезного списку
Як агенту дізнатися, які інструменти існують? Одним із варіантів є надання моделі дуже довгого списку визначень інструментів та дозволення їй самостійно визначати їхню релевантність. Це може підійти для прототипу, але не спрацює у масштабах корпорації. Тисячі описів створюють додаткові витрати на обробку контексту та затримки, а необмежене пошукове функціонування підвищує ризики з точки зору безпеки без жодної користі.
Кращим рішенням є Реєстр інструментів — корпоративний каталог можливостей. Він містить не лише назви API та їхні схеми. Кожен запис містить метадані, які платформа може використовувати для пошуку, керування та прийняття рішень щодо політик:
- бізнес-домен, власник та версія
- чи є інструмент тільки для читання чи дозволяє записувати дані
- класифікація ризиків та необхідні функції
- класифікація даних
- схеми вхідних та вихідних даних
- характеристики ідемпотентності
- вимоги до аудиту
Метадані мають найвище значення під час розрізнення типів операцій. Пошук транзакції — це операція читання з досить низьким ризиком, повернення грошей — це операція запису з високим впливом на фінанси, а адміністративна операція може нести ще більший ризик. Ці відмінності не можуть залишатися лише в документації. Вони мають існувати в самій платформі, щоб детермінована інфраструктура могла на них діяти.
Виявлення — це не авторизація
Це, можливо, найкорисніше розрізнення в усій конструкції: виявлення інструменту та наявність дозволу на його використання — це різні речі.
Виявлення відповідає на питання, які інструменти мають бути доступні цьому агенту для виконання цього завдання. Авторизація відповідає на питання, чи дозволено зараз здійснити цей конкретний запит.
Отже, метадані реєстру забезпечують фільтрацію, яка відбувається ще до того, як ШІ оцінить свої варіанти. Спочатку платформа визначає, хто є користувачем, який агент діє, який є тенантом, який є контекстом та що саме намагається досягти запит. Потім вона складає список інструментів, які відповідають цій меті, а далі скорочує цей список, враховуючи можливості агента, дозволи користувача, обмеження тенанта, регіон та політики щодо ризиків. Модель бачить лише те, що залишилося.
Проте цей фільтр все одно не може бути останнім рівнем захисту. Модель може зробити виклик, якого ніхто не очікував, неправильно зрозуміти намір користувача або бути під впливом вставки запитів. Тому кожен виклик проходить через контрольований Tool Gateway на шляху до базового API підприємства.
У своїй суті шлюз обробляє набір фактів разом (хто є користувачем, який агент здійснює виклик, що саме запитується, на якому ресурсі, з якими параметрами, у якому контексті) та застосовує відповідну політику.
Авторизуйте намір, а не лише інструмент
Приклад повернення грошей показує ще один момент: авторизація не може залежати лише від того, який інструмент використовується. Вона має враховувати намір та дію, яка в результаті відбувається.
Перевірка статусу повернення коштів та ініціювання повернення — це не однакові функції: одна є операцією зчитування інформації, а інша — фінансовим наслідком. Платформа повинна чітко моделювати їх. Запит, класифікований як запит про статус повернення коштів, може потрапити до інструментів пошуку клієнтів та транзакцій, але ця класифікація не автоматично надає дозволу на виконання операції повернення коштів. Навіть якщо модель помилково вирішить, що повернення коштів має бути здійснене, шар авторизації може порівняти фактично запитану дію з дозволеним наміром та відхилити її.
Тут підхід до безпеки змінюється з питання про те, чи має агент доступ до API для повернення коштів, на питання про те, чи дозволені цей користувач, агент, намір, ресурс та дія в цьому контексті.
Коли половина робочого процесу зазнає невдачі
Як тільки дія стає дозволеною, виникає ще одна проблема: що робити, якщо одна частина робочого процесу виконується успішно, а інша — ні? Припустимо, повернення грошей відбувається, а лист із підтвердженням — ні. Перезапуск усього робочого процесу агента може призвести до подвійного повернення коштів.
Безпечніший підхід полягає у тому, щоб зробити цей побічний ефект окремим кроком у стабільному робочому процесі. Авторизація схвалює повернення грошей, API для цього виконується, а результат успіху зберігається. Цей збережений результат генерує подію RefundCompleted, яка ініціює нотифікації. У разі невдачі з листом відбувається повторна спроба надіслати лише нотифікацію, а фінансова операція не повторюється.
Наявність ШІ у системі не означає відмови від класичних інструментів корпоративного використання. Механізми повторних спроб та усунення дублікатів, захисні пристрої та компенсаційні дії, ідемпотентні операції, стійкий стан та обробка на основі подій залишаються актуальними. Агенти можуть допомогти у прийнятті рішень щодо того, що має відбутися, тоді як детерміністична інфраструктура контролює критичні зміни стану.
Схвалення належать до політики
LLM також не повинен вирішувати, коли людина мусить схвалити щось. Це питання політики. Організація може дозволити автоматичні повернення коштів нижче певного порогу та вимагати підтвердження для сум вище цього порогу, завжди вимагати схвалення для адміністративних операцій та додавати контролі для транзакцій з незвичайними адресатами чи підвищеним ризиком. Модель може попередити про необхідність вжиття певних дій. Система політик вирішує, чи потрібне схвалення, а Tool Gateway забезпечує виконання цього рішення. Це також покращує управління, оскільки правила є чіткими, підлягають перевірці, мають версії та підлягають аудиту, і не приховані всередині запиту.
Площина керування та площина виконання
Після розгляду цих сценаріїв дизайн виглядає значно менш схожим на просту схему «Користувач → LLM → Інструменти» та більш схожим на платформу корпоративного управління. Він природним чином ділиться на дві області.
Площина керування — це місце, де організація встановлює свої правила. Вона включає каталог агентів, реєстр інструментів, визначення можливостей, класи ризиків, політики авторизації та схвалення, а також загальні налаштування управління.
Площина виконання — це те, що працює в реальному часі. Вона містить шлюзи для API та агентів, самі агенти, вже відфільтровані дані про виявлення об’єктів, застосування правил, обмін обліковими даними, інструменти, які виконуються, стан робочого процесу та потік подій аудиту. Правила можна керувати централізовано, тоді як їх застосування відбувається безпосередньо там, де виконуються робочі завдання.
Це розділення має велике значення у масштабних системах. Коли є сотні чи тисячі агентів та величезна кількість інструментів, ніхто не хоче, щоб кожна перевірка авторизації чекала на одну центральну службу. Політики керуються в одному місці, тоді як точки їх застосування є розподіленими, а дані політик зберігаються у кеші чи реплікуються там, де це доцільно.
Оцінка дій, а не лише відповідей
Цей дизайн гармонійно поєднується з корпоративними ML-рішеннями, водночас додаючи новий клас проблем. Традиційні ML-системи зосереджуються на точності, якості даних, їх змінах, затримках, безпеці, моніторингу та надійності функціонування. Агенти зберігають усе це та додають оцінку дій.
Правильна кінцева відповідь ще не є вирішенням. Рецензентам також потрібно знати, чи обрав агент правильний інструмент та передав правильні параметри, чи дотримувався меж авторизації, чи уникав дій, які йому не було дозволено виконувати, чи дотримувався запланованої схеми роботи, чи звертався за схваленням до людини, коли це було необхідно, та чи спричинив очікувані побічні ефекти. Оцінка переходить від оцінки відповідей до оцінки дій.
Основний принцип
Один принцип постійно повторюється: ставитися до LLM як до ненадійного елемента прийняття рішень, а ніколи не як до межі безпеки. Агент може міркувати, виявляти відповідні можливості та пропонувати дії. Детерміністична корпоративна інфраструктура визначає, що може робити агент, до яких ресурсів він може мати доступ, які параметри є прийнятними, чи потрібне схвалення людини, як безпечно функціонуватимуть побічні ефекти та як буде проводитися аудит усього процесу.
Це справжня архітектурна проблема агентського ШІ. Зробити агента достатньо розумним, щоб він міг використовувати інструменти, — це проста частина. Справжня складність полягає у створенні платформи, на якій тисячі агентів працюють для мільйонів користувачів, при цьому ідентичність, авторизація, бізнес-правила та оперативна надійність залишаються під контролем.
Пов’язані матеріали
- Медичний агент, який здійснює пошук між базами даних SQLite та вебом — створення агента LangChain, який вирішує, чи потрібен для медичного запиту SQL-запит до трьох наборів даних чи живий пошук в інтернеті, а також дві проблеми, які змінили дизайн.