Перевірено безпечне використання інструментів для агентів LLM: STPA зустрічає MCP

Я вже деякий час читаю літературу про захисні механізми (guardrails) — GuardAgent, ShieldAgent, AGrail — і всі вони покращують рівень виявлення, при цьому тихо визнаючи, що насправді не можуть нічого гарантувати. Ця стаття ICSE NIER 2026 від Доші та співавт. з CMU та Університету штату Північна Кароліна розглядає проблему під іншим кутом: замість того, щоб питати, як надійніше виявляти погану поведінку агентів, вони запитують, як зробити небезпечну поведінку формально неможливою. Це програмна стаття (position paper), а не емпіричне дослідження, але формулювання достатньо гостре, щоб варто було прочитати її уважно.

Про статтю

"Towards Verifiably Safe Tool Use for LLM Agents" (arXiv:2601.08012) від Аар'ї Доші, Інін Хонг, Цун'їн Сюй, Инсук Канг, Александроса Каправелоса та Крістіана Кестнера пропонує методологію виведення та забезпечення виконання специфікацій безпеки при використанні інструментів агентами LLM. Основне спостереження полягає в тому, що ризики в агентних системах виникають переважно через композицію інструментів — а не через збої окремих інструментів — тому захисні механізми на рівні компонентів не можуть їх вловити. Агент, що вирішує конфлікт у календарі, може правильно запитати приватну медичну картку та правильно надіслати електронний лист, але при цьому вчинити катастрофу: витік вмісту цієї картки колегам пацієнта.

Запропоноване рішення складається з двох частин. По-перше, автори застосовують системно-теоретичний аналіз процесів (STPA), метод інженерії безпеки з авіаційних та ядерних систем, щоб ідентифікувати небезпеки на рівні агента, вивести вимоги безпеки та формалізувати їх як специфікації потоків даних та послідовностей інструментів. По-друге, вони представляють фреймворк Model Context Protocol (MCP) з розширеними можливостями, де кожен інструмент повинен декларувати структуровані метадані: рівень можливостей (лише читання, лише запис, читання-запис, виконання), класифікацію конфіденційності та рівень довіри. Забезпечення виконання потім структурується за чотирма рівнями: автоматичний блок-лист для доведено небезпечних потоків, must-list для обов'язкових послідовностей, allow-list для попередньо схвалених операцій та ескалація підтвердження для неоднозначних випадків.

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

Ключові ідеї

• STPA переосмислює безпеку агентів як проблему системної інженерії: ідентифікація втрат, відстеження через небезпечні взаємодії, виведення вимог — перед написанням будь-якого коду для забезпечення виконання.
• Специфікації поділяються на два види: обмеження потоку інформації («електронні листи про події не повинні містити приватних даних, що не належать одержувачу») та обмеження темпоральної логіки («кожному update_event має слідувати send_email кожному учаснику»).
• Чотирирівневе забезпечення виконання (блок-лист / must-list / allow-list / підтвердження) розроблено для зменшення втоми від безпеки — більшість безпечних потоків попередньо схвалені, тому агент не запитує дозвіл постійно.
• Вичерпний аналіз слідів Alloy підтвердив відсутність небезпечних потоків у тематичному дослідженні календаря при збереженні функціональності завдання.
• Весь підхід явно орієнтований на спеціалізовані агенти, а не на помічників загального призначення — автори визнають, що вузькоспрямовані агенти легше захистити.

Що витримує критику, а що ні

Інтелектуальний хід правильний: запозичення STPA з інженерії критично важливих систем — це правильний інстинкт. На відміну від імовірнісних захисних механізмів, цей підхід перетворює вимоги на предикати над системними слідами, які можна верифікувати, а не оцінювати. Чотирирівнева ієрархія забезпечення виконання продумана — розрізнення між блок-листом і підтвердженням особливо важливе, оскільки постійні запити на підтвердження підривають довіру користувача і починають ігноруватися.

З іншого боку, обмеження статті значні та здебільшого залишаються невирішеними. Проблема довіри до метаданих визнається, але не вирішується: вся структура залежить від того, чи правильно розробники маркують свої інструменти. На відкритому ринку MCP, де поширені сторонні інструменти, немає механізму забезпечення коректності маркувань. Формальна верифікація також виконана на створеній вручну іграшковій моделі Alloy — це демонструє можливість реалізації підходу, але не те, що його можна застосувати до реальних систем у масштабі.

Я також не бачу переконливого аргументу, чому саме STPA є правильним методом аналізу небезпек порівняно з, скажімо, моделюванням загроз або HAZOP. Тематичне дослідження календаря є ілюстративним, але тривіально малим. Також немає обговорення зловмисних постачальників інструментів, які навмисно неправильно маркують можливості — а це реальна поверхня атаки, яку детально вивчає відповідна література з безпеки MCP (arXiv:2601.17549).

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

Чому це важливо для фінансового ШІ

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

Розширення MCP безпосередньо релевантне, оскільки інструментарій Beancount все частіше обгортається як MCP-сервери. Якщо ці інструменти можуть декларувати свій рівень можливостей та клас конфіденційності у структурованому, машиночитаному вигляді, стає можливим забезпечувати виконання політик потоку даних на межі протоколу, а не сподіватися, що агент буде контролювати себе сам. Обмеження темпоральної логіки — вимога, щоб кожному post_transaction передувала успішна balance_check — це саме той тип інваріанта, який фінансовий агент повинен гарантувати перед фіксацією записів.

Відсутня ланка на даний момент — це те, що нічого з цього ще не було побудовано та протестовано. Але як концептуальний словник для роздумів про безпеку агентів у бухгалтерії, STPA + IFC (контроль інформаційних потоків) є найбільш принциповим фреймворком, який я бачив у цій літературі.

Що почитати далі

• "Securing AI Agents with Information-Flow Control" — arXiv:2505.23643, Microsoft Research; реалізує конкретну систему IFC (Fides) з відстеженням міток (taint tracking), оцінену на AgentDojo; емпіричне доповнення до цієї статті.
• "Breaking the Protocol: Security Analysis of the Model Context Protocol Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents" — arXiv:2601.17549; безпосередньо аналізує поверхню атаки MCP, яку покликаний захистити фреймворк цієї статті.
• "Systematic Hazard Analysis for Frontier AI using STPA" — arXiv:2506.01782; більш свіже застосування методології STPA до систем ШІ в цілому, корисне для розуміння того, як ця техніка масштабується.