Проверимо безопасно използване на инструменти от LLM агенти: STPA среща MCP

От известно време чета литературата за защитни механизми (guardrails) — GuardAgent, ShieldAgent, AGrail — и всички те подобряват нивата на откриване, като същевременно тихомълком признават, че не могат реално да гарантират нищо. Тази статия от ICSE NIER 2026 на Doshi и др. от CMU и NC State подхожда от различен ъгъл: вместо да питат как да откриват по-надеждно лошо поведение на агенти, те питат как да направят небезопасното поведение формално невъзможно. Това е документ с позиция (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) — метод за инженерна безопасност от авиацията и ядрените системи — за идентифициране на опасностите на ниво агент, извеждане на изисквания за безопасност и формализирането им като спецификации за потоците от данни и последователността от инструменти. Второ, те представят разширена с възможности рамка Model Context Protocol (MCP), където всеки инструмент трябва да декларира структурирани метаданни: ниво на възможностите (само за четене, само за запис, четене и запис, изпълнение), класификация на поверителността и ниво на доверие. Прилагането е структурирано в четири нива: автоматичен черен списък (blocklist) за доказуемо небезопасни потоци, списък със задължителни действия (mustlist) за изисквани последователности, бял списък (allowlist) за предварително одобрени операции и ескалация за потвърждение при двусмислени случаи.

Стъпката на формална верификация използва Alloy, инструмент за релационна логика от първи ред, за моделиране на пространството на изпълнение и изчерпателна проверка, че при заявените политики не могат да възникнат нарушения на безопасността, докато безопасните следи (traces) остават достижими. Това е основният „резултат“ на статията — няма числа за точност на бенчмаркове, което е очаквано за кратък доклад тип NIER.

Ключови идеи

• STPA преформулира безопасността на агентите като проблем на системното инженерство: идентифициране на загубите, проследяване на опасните взаимодействия, извеждане на изисквания — преди написването на какъвто и да е код за прилагане.
• Спецификациите се разделят на два вида: ограничения на информационния поток („имейлите за събития не трябва да включват лични данни, които не принадлежат на получателя“) и ограничения на времевата логика („всяко update_event трябва да бъде последвано от send_email до всеки участник“).
• Четиристепенното прилагане (черен списък / списък със задължителни действия / бял списък / потвърждение) е проектирано да намали умората от сигурността — повечето безопасни потоци са предварително одобрени, така че агентът не иска постоянно разрешение.
• Изчерпателният анализ на следите с Alloy потвърди липсата на небезопасни потоци в казуса с календара, като същевременно запази функционалността на задачата.
• Целият подход е изрично ограничен до специфични за дадена задача агенти, а не за асистенти с общо предназначение — авторите признават, че тесните агенти са по- лесни за обезопасяване.

Какво издържа проверката — и какво не

Интелектуалният ход е солиден: заемането на STPA от критичното за безопасността инженерство е правилният инстинкт. За разлика от вероятностните защитни механизми, този подход превръща изискванията в предикати над системните следи, които могат да бъдат верифицирани, а не оценени. Четиристепенната йерархия на прилагане е внимателно проектирана — разликата между черния списък и потвърждението е особено важна, тъй като постоянните подкани за потвърждение ерозират доверието на потребителя и биват игнорирани.

Въпреки това, ограниченията на статията са значителни и до голяма степен остават без отговор. Проблемът с доверието в метаданните е признат, но не е решен: цялата рамка зависи от това разработчиците на инструменти да ги етикетират точно. В отворен пазар за MCP, където инструментите на трети страни са често срещани, няма механизъм за принудително спазване на коректността на етикетите. Формалната верификация също е извършена върху ръчно изработен игрален модел в Alloy — тя демонстрира осъществимостта на подхода, а не че подходът може да се приложи към реални системи в голям мащаб.

Също така не виждам убедителен аргумент защо STPA е правилният метод за анализ на опасностите в сравнение с, да речем, моделиране на заплахи или HAZOP. Казусът с календара е илюстративен, но тривиално малък. И липсва дискусия за злонамерени доставчици на инструменти, които нарочно поставят грешни етикети на възможностите — което е реална повърхност за атака, изследвана подробно в свързаната литература за сигурността на MCP (arXiv:2601.17549).

Честното рамкиране е, че това е проектно предложение с доказателство за концепцията чрез формален модел. Тежката инженерна работа — изграждането на двигателя за политики, тестването на обхвата на етикетите в различни инструменти, емпиричното измерване на компромиса между автономия и безопасност — е обявена за бъдеща работа.

Защо това е важно за AI във финансите

Агентите за записване (write-back) в 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 към AI системите в широк смисъл, полезно за разбиране на мащабирането на техниката.