Ваш MCP-сервер захищений. А система обліку за ним — ні.

У нещодавній статті тут, на Unite.AI, Гіл Файг виклав шість найкращих практик зі створення захищеного MCP-сервера. Вони слушні, і кожен, хто випускає MCP-сервер, має їх дотримуватися. Його порада надати кожній інтеграції «власну роль із чітко визначеними правами, обмеженими лише необхідними дозволами» — цілком правильна. Водночас вона передбачає, що система на іншому кінці має ролі з чітко визначеними правами. Це вказує на ширше припущення, про яке рідко говорять уголос: системи за сервером можна захистити за таким самим стандартом.

У бізнес-програмному забезпеченні це часто неможливо. Я керую інженерною командою, яка розробляє інтеграційний рівень для підключення до 32 бухгалтерських систем і систем ERP, поверх якого за бажанням можна розгорнути MCP-сервер. Ми регулярно бачимо, як агенти з належною автентифікацією, чітко визначеними правами й повним журналюванням на нашому боці записують дані в системи, які взагалі не можуть визначити, що до цього був залучений агент.

У цій статті йдеться про другу половину проблеми: які можливості насправді пропонують зовнішні системи, що можна контролювати на рівні інтеграції та де цей контроль закінчується.

Де специфікація MCP передає відповідальність далі

Ця специфікація авторизації MCP чітко визначає межі власної сфери дії. Сервер MCP є сервером ресурсів OAuth для своїх клієнтів. Викликаючи API системи вищого рівня, він діє як окремий клієнт OAuth і використовує окремий токен, виданий цією системою. Передавати далі токен клієнта прямо заборонено.

Це правильний підхід. Водночас це означає, що все, що стосується виклику зовнішньої системи, зокрема хто має право що робити і як це фіксується, повністю залежить від цієї системи. Специфікація не може виправити те, чого зовнішня система не передбачає.

Те саме стосується рекомендацій OWASP щодо надмірних повноважень агентів. У них радять обмежувати дозволи, які розширення агента мають в інших системах, до необхідного мінімуму, а також виконувати дії від імені користувача, якого вони представляють. Обидві поради слушні. І обидві передбачають, що інша система має спосіб задавати мінімальні дозволи й контекст користувача.

Які можливості насправді пропонують зовнішні системи

Ось як виглядають 32 бухгалтерські системи й системи ERP, до яких ми підключаємося, з погляду інтегратора.

Третина взагалі не підтримує OAuth

21 із 32 систем використовують OAuth. Інші 11 покладаються на статичні облікові дані: ключі API, ім’я користувача й пароль або пару токенів. Деякі з цих ключів ніколи не втрачають чинності. В документації однієї широко використовуваної системи зазначено, що її токени API діють необмежений час, поки існує користувач.

Тривалий строк дії, мало можливостей для відкликання

Від OAuth користі менше, ніж можна було б сподіватися. Один постачальник видає токени оновлення зі строком дії приблизно 20 років. Ці облікові дані розраховані на те, щоб пережити агента, який ними користується, платформу, на якій цього агента створили, і цілком можливо — людину, яка натиснула «дозволити». В іншій системі навіть токени доступу не мають строку дії.

А коли облікові дані вже видано, виникає питання: хто може їх відкликати? Стандарт для цього — відкликання токенів OAuth (RFC 7009) — існує з 2013 року. І все ж приблизно чотири з десяти систем не надають інтегратору технічної можливості відкликати облікові дані. До цієї групи належать усі системи з ключами API. Єдиний доступний варіант — попросити клієнта вручну видалити доступ.

Обмежені права доступу, жодної ідентифікації агента

Більшість статичних ключів просто успадковують усі права користувача, який їх створив; лише в кількох системах можна обмежити ключ доступом до окремих кінцевих точок. У багатьох системах OAuth є дозволи, але зазвичай вони досить загальні — на кшталт «бухгалтерський облік: читання й запис». І в жодній із 32 систем ми не знайшли способу зафіксувати через API в межах однієї транзакції ідентичність агента та людини, від імені якої він діє. Зовнішні агенти відображаються або як користувач, який їх підключив, або як звичайний системний користувач. Показово, що постачальник, який вбудував агентів у власний продукт, як-от Microsoft у Business Central, створив для них окремі облікові записи користувачів. Це та сама модель, яку я рекомендую нижче, але наразі її застосовують лише до власних агентів постачальника.

Що може забезпечити інтеграційний рівень

Усе це не означає, що треба здаватися. Між агентом і бухгалтерською системою ви контролюєте майже все:

• окремі облікові дані для кожного агента на вашому рівні
• власні дозволи, наприклад доступ до рахунків лише для читання
• журнал аудиту кожного виклику агента із зазначенням людини, від імені якої він діяв
• ключі ідемпотентності, щоб агент під час повторної спроби не зареєстрував той самий рахунок двічі
• обмеження частоти запитів для кожного агента
• етапи погодження перед будь-яким записом

Жоден із цих заходів не залежить від того, які можливості підтримує цільова система. Повноцінний рівень контролю доступу на рівні інтеграції можна створити вже сьогодні, і якщо ви підпускаєте агентів до фінансових даних, його слід розробити.

Де проходить межа

Ви не можете поширити цей рівень за межі системи. Там усе ламається з трьох причин.

Атрибуція

В обліковій системі запис, зроблений агентом, відображається як запис того, хто авторизував підключення, або як запис технічного користувача. Під час аудиту системи видно, що проводку зробив цей користувач. Неможливо визначити, чи це була людина, чи агент. Для облікового реєстру агент, який проводить 400 рахунків-фактур о 3:00 ночі, нічим не відрізняється від дуже сумлінного фінансового менеджера. Щоб відновити перебіг подій, потрібні журнали інтегратора, а це вже інший ланцюжок довіри, ніж той, який забезпечує система обліку. Для розслідування чи аудиту це слабка позиція.

Більшість організацій теж не випереджають події. В опитуванні Cloud Security Alliance лише 28% респондентів відповіли, що можуть надійно відстежувати дії агентів до конкретної людини або системи в усіх середовищах, а 44% уже використовують або планують використовувати для своїх агентів статичні ключі API.

Найменші привілеї

Ви можете налаштувати агента так, щоб він лише читав рахунки-фактури. Але якщо цільова система не підтримує дозволи з визначеними областями дії, облікові дані за вашим рівнем доступу й далі надаватимуть повний доступ. Той, хто їх здобуде, повністю обійде ваш рівень захисту й усі налаштовані на ньому правила.

Відкликання доступу

Ви можете миттєво заблокувати власного агента. Але це не допоможе, якщо скомпрометовано облікові дані безпосередньо цільової системи. А для чотирьох із десяти систем, у яких немає кінцевої точки для відкликання доступу, аварійне вимкнення зводиться до надсилання електронного листа клієнту.

Практичне рішення: окремий обліковий запис агента

Найкорисніше, що можна зробити вже сьогодні, — це щось непоказне. Створіть для агента окремий обліковий запис у цільовій системі й підключайте агента лише через нього.

Це працює в кожній системі, де можна створювати облікові записи, і дає три переваги, яких не може забезпечити рівень інтеграції:

• Атрибуція в системі обліку. Проводки відображатимуться від імені «Агента з обліку кредиторської заборгованості», а не фінансового менеджера, який натиснув «Підключити» шість місяців тому.
• Можливість відкликати доступ, навіть без API для цього. Клієнт може вимкнути обліковий запис у самому інтерфейсі — це працює і в системах без кінцевої точки для відкликання доступу.
• Часткове дотримання принципу найменших привілеїв. Якщо в системі взагалі передбачено ролі, обліковий запис агента часто можна обмежити модулями, які йому справді потрібні.

Витрати цілком реальні. Під час початкового налаштування хтось має вручну створити обліковий запис, що додає зайвих клопотів саме тоді, коли це найменш доречно. Близько половини систем стягують плату за кожного додаткового користувача — від кількох євро на місяць у сервісах для малого бізнесу до понад ста євро в повноцінній ERP-системі. У кількох інших системах кількість користувачів обмежена тарифним планом, тож ще один обліковий запис може змусити всю компанію перейти на дорожчий план. А службовий обліковий запис, за який ніхто не відповідає, сам стає джерелом ризику — частиною розростання кількості нелюдських ідентичностей, про яке Unite.AI вже писало. Як і будь-який інший обліковий запис, він потребує відповідального власника й дати перевірки.

Це також не вирішує проблему з дозволами в системах, де їх не передбачено. Але завдяки цьому атрибуція та відкликання доступу повертаються до системи, якою насправді користуються аудитори.

Структурне рішення: делегована ідентичність

Правильне рішення вже існує на папері. Обмін токенами OAuth 2.0 (RFC 8693) розрізняє імітацію користувача та делегування. За делегування агент зберігає власну ідентичність, а в токені зазначено, що він діє від імені людини, за допомогою твердження «act».

У бухгалтерському обліку це означало б, що:

• в обліковому реєстрі зазначено, що цю проводку зробив цей агент від імені цієї людини
• дозволи надаються для кожного делегування, а не для кожного користувача
• окреме делегування можна відкликати, не зачіпаючи обліковий запис людини

Наскільки мені вдалося з’ясувати, жодна з 32 систем не підтримує нічого подібного. Тож поки що це лише напрям розвитку, а не доступна опція. Отже, звертатися з таким запитом потрібно до постачальників бухгалтерського та ERP-ПЗ, а не до інтеграторів: агенти вже вносять записи до ваших облікових реєстрів, і ваші API мають уміти це відображати.

Що зробити, перш ніж агент отримає доступ до облікового реєстру

Якщо ви підключаєте агентів до бухгалтерських систем або ERP-систем, скористайтеся коротким контрольним списком:

1. З’ясуйте, як у кожній цільовій системі працюють облікові дані. Це OAuth чи статичний ключ? Як довго діють облікові дані? Чи передбачено для них дозволи з визначеними областями дії та чи можна їх відкликати?
2. У будь-якому разі створіть власний рівень керування доступом. Ідентичність для кожного агента, дозволи з визначеними областями дії, ідемпотентність і погодження мають бути на вашому боці — незалежно від можливостей цільової системи.
3. Використовуйте окремий обліковий запис агента всюди, де це дозволяє система. Розглядайте зусилля з початкового налаштування та вартість ліцензії як плату за можливість відстежувати, хто виконав дію.
4. Забезпечте захист власного журналу аудиту від непомітних змін. Для багатьох систем це буде єдиний запис, який свідчитиме про участь агента.
5. Зафіксуйте залишковий ризик. Якщо система не має областей дії та механізмів відкликання, повідомте про це клієнта й зазначте це у власному реєстрі ризиків.

Межа — це головне

Захистити сервер MCP необхідно, але цього недостатньо. Безпека агента, який записує дані до реєстру, визначається на межі між вашим рівнем і системою обліку, і сьогодні цю межу встановлюють системи, а не ви.

Добра новина: цей розрив чітко окреслений. Стандарти існують. Бракує лише підтримки цих стандартів у системах, де ведеться облік.