Верифицируемо безопасное использование инструментов LLM-агентами: STPA встречает MCP

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

О статье

Работа "Towards Verifiably Safe Tool Use for LLM Agents" (arXiv:2601.08012) авторов Aarya Doshi, Yining Hong, Congying Xu, Eunsuk Kang, Alexandros Kapravelos и Christian Kästner предлагает методологию вывода и обеспечения соблюдения спецификаций безопасности при использовании инструментов LLM-агентами. Ключевое наблюдение заключается в том, что риски в агентных системах возникают в первую очередь из-за композиции инструментов, а не из-за сбоев отдельных инструментов, поэтому меры безопасности на уровне компонентов не могут их отловить. Агент, разрешающий конфликт в календаре, может корректно запросить частную медицинскую запись и корректно отправить электронное письмо, но при этом совершить нечто катастрофическое: раскрыть содержимое этой записи коллегам пациента.

Предложенное решение состоит из двух частей. Во-первых, авторы применяют системно-теоретический анализ процессов (STPA) — метод проектирования безопасности из авиации и атомной энергетики — для выявления опасностей на уровне агента, вывода требований безопасности и их формализации в виде спецификаций потоков данных и последовательностей инструментов. Во-вторых, они вводят расширенную возможностями (capabilities) среду Model Context Protocol (MCP), где каждый инструмент должен декларировать структурированные метаданные: уровень полномочий (только чтение, только запись, чтение-запись, исполнение), классификацию конфиденциальности и уровень доверия. Обеспечение соблюдения (enforcement) затем структурируется по четырем уровням: автоматический «черный список» для доказуемо небезопасных потоков, «обязательный список» (mustlist) для необходимых последовательностей, «белый список» для предварительно одобренных операций и эскалация для подтверждения в неоднозначных случаях.

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

Основные идеи

• STPA переосмысливает безопасность агентов как проблему системного проектирования: выявление потерь, отслеживание опасных взаимодействий, вывод требований — еще до написания кода обеспечения безопасности.
• Спецификации делятся на два типа: ограничения информационных потоков («письма о событиях не должны включать личные данные, не принадлежащие получателю») и ограничения темпоральной логики («за каждым update_event должно следовать send_email каждому участнику»).
• Четырехуровневое обеспечение соблюдения (черный список / обязательный список / белый список / подтверждение) разработано для снижения «усталости от безопасности» — большинство безопасных потоков одобряются заранее, поэтому агент не запрашивает разрешение постоянно.
• Исчерпывающий анализ траекторий 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 к ИИ-системам в целом, полезно для понимания масштабируемости техники.