Overiteľne bezpečné používanie nástrojov pre LLM agentov: STPA sa stretáva s MCP

Už nejaký čas sledujem literatúru o bezpečnostných poistkách (guardrails) — GuardAgent, ShieldAgent, AGrail — a všetky síce zlepšujú mieru detekcie, ale potichu priznávajú, že v skutočnosti nemôžu nič zaručiť. Tento článok z ICSE NIER 2026 od Doshiho a kol. z CMU a NC State na to ide z iného uhla: namiesto otázky, ako spoľahlivejšie detegovať zlé správanie agenta, sa pýtajú, ako urobiť nebezpečné správanie formálne nemožným. Ide o teoretický príspevok (position paper), nie o empirickú štúdiu, ale jeho rámcovanie je dostatočne presné na to, aby stálo za pozorné prečítanie.

O článku

Článok "Smerom k overiteľne bezpečnému používaniu nástrojov pre LLM agentov" (arXiv:2601.08012) od autorov Aarya Doshi, Yining Hong, Congying Xu, Eunsuk Kang, Alexandros Kapravelos a Christian Kästner navrhuje metodológiu na odvodenie a vynucovanie bezpečnostných špecifikácií nad používaním nástrojov LLM agentmi. Kľúčovým pozorovaním je, že riziká v agentových systémoch vznikajú primárne z kompozície nástrojov — nie zlyhaním jednotlivých nástrojov — takže ochranné prvky na úrovni komponentov ich nemôžu zachytiť. Agent riešiaci konflikt v kalendári môže správne vyhľadať súkromný zdravotný záznam a správne odoslať e-mail, a pritom stále urobiť niečo katastrofálne: uniknúť obsah tohto záznamu kolegom pacienta.

Navrhované riešenie má dve časti. Po prvé, autori aplikujú systémovo-teoretickú analýzu procesov (STPA), metódu bezpečnostného inžinierstva z oblasti letectva a jadrových systémov, na identifikáciu hazardov na úrovni agenta, odvodenie bezpečnostných požiadaviek a ich formalizáciu ako špecifikácií dátových tokov a sekvencií nástrojov. Po druhé, zavádzajú rámec Model Context Protocol (MCP) rozšírený o oprávnenia, kde každý nástroj musí deklarovať štruktúrované metadáta: úroveň oprávnení (iba na čítanie, iba na zápis, čítanie-zápis, vykonávanie), klasifikáciu dôvernosti a úroveň dôvery. Vynucovanie je potom štruktúrované do štyroch úrovní: automatický blacklist pre preukázateľne nebezpečné toky, mustlist pre povinné sekvencie, allowlist pre vopred schválené operácie a eskallácia na potvrdenie pre nejednoznačné prípady.

Krok formálnej verifikácie využíva Alloy, nástroj relačnej logiky prvého poriadku, na modelovanie execution space a vyčerpávajúcu kontrolu, či pri stanovených politikách nemôže dôjsť k porušeniu bezpečnosti, zatiaľ čo bezpečné stopy zostávajú dosiahnuteľné. Toto je primárny "výsledok" článku — neuvádza žiadne čísla presnosti benchmarkov, čo sa pri krátkom NIER príspevku očakáva.

Kľúčové myšlienky

• STPA preformulováva bezpečnosť agentov na problém systémového inžinierstva: identifikovať straty, vystopovať ich späť cez nebezpečné interakcie, odvodiť požiadavky — a to všetko ešte pred napísaním akéhokoľvek kódu na vynucovanie.
• Špecifikácie sa delia na dva druhy: obmedzenia toku informácií („e-maily k udalostiam nesmú obsahovať súkromné údaje nepatriace príjemcovi“) a obmedzenia temporálnej logiky („po každom update_event musí nasledovať send_email každému účastníkovi“).
• Štvorúrovňové vynucovanie (blacklist / mustlist / allowlist / potvrdenie) je navrhnuté tak, aby znižovalo únavu z bezpečnostných upozornení — väčšina bezpečných tokov je vopred schválená, takže agent neustále nežiada o povolenie.
• Vyčerpávajúca analýza stôp v Alloy potvrdila absenciu nebezpečných tokov v prípadovej štúdii kalendára pri zachovaní funkčnosti úloh.
• Celý prístup je explicitne zameraný na úlohových agentov, nie na všeobecných asistentov — autori uznávajú, že úzko zameraných agentov je jednoduchšie zabezpečiť.

Čo obstojí — a čo nie

Tento intelektuálny posun je správny: vypožičanie STPA z kritického bezpečnostného inžinierstva je správny inštinkt. Na rozdiel od pravdepodobnostných mantinelov (guardrails) tento prístup premieňa požiadavky na predikáty nad systémovými stopami, ktoré sa dajú verifikovať, nie iba odhadovať. Štvorúrovňová hierarchia vynucovania je premyslene navrhnutá — najmä rozdiel medzi blacklistom a potvrdením je dôležitý, pretože neustále výzvy na potvrdenie podkopávajú dôveru používateľa a ten ich začne ignorovať.

Napriek tomu sú obmedzenia článku významné a väčšinou neriešené. Problém dôvery v metadáta je priznaný, ale nevyriešený: celý rámec závisí od toho, či vývojári nástrojov presne označia svoje nástroje. V otvorenom trhovisku MCP, kde sú bežné nástroje tretích strán, neexistuje žiadny mechanizmus na vynútenie správnosti označení. Formálna verifikácia sa tiež vykonáva na ručne vytvorenom hračkárskom modeli v Alloy — demonštruje uskutočniteľnosť prístupu, nie to, že prístup sa dá aplikovať na reálne systémy vo veľkom meradle.

Taktiež nevidím presvedčivý argument, prečo je STPA tým správnym spôsobom analýzy hazardov v porovnaní napríklad s modelovaním hrozieb alebo HAZOP. Prípadová štúdia kalendára je ilustratívna, ale triviálne malá. A chýba diskusia o nepriateľských poskytovateľoch nástrojov, ktorí úmyselne nesprávne označia oprávnenia — čo je reálny útočný povrch, ktorý podrobne skúma súvisiaca literatúra o bezpečnosti MCP (arXiv:2601.17549).

Úprimné zhodnotenie je, že ide o návrh dizajnu s proof-of-concept formálnym modelom. Ťažká inžinierska práca — budovanie enginu politík, testovanie pokrytia označení v rámci rôznych nástrojov, empirické meranie kompromisu medzi autonómiou a bezpečnosťou — je odsunutá na budúcu prácu.

Prečo je to dôležité pre finančnú AI

Agenti so spätným zápisom (write-back) v Beancount čelia presne tomu vzorcu hazardov, na ktorý je tento článok navrhnutý: kompozícia nástrojov vytvárajúca emergentné riziká. Agent, ktorý načíta citlivý záznam v účte a potom odošle súhrn do zdieľanej hlavnej knihy, môže v každom jednotlivom kroku robiť niečo úplne rozumné, pričom porušuje obmedzenie dôvernosti, ktoré je viditeľné len na úrovni systému. Prístup STPA, začínajúci od strát zainteresovaných strán a ich inverzia do požiadaviek, sa čisto mapuje na finančnú doménu, kde stratami sú regulačné porušenia, neoprávnené zverejnenia a nezvratné mutácie v účtovnom denníku.

Rozšírenie MCP je priamo relevantné, pretože nástroje Beancount sa čoraz častejšie obaľujú ako MCP servery. Ak by tieto nástroje mohli deklarovať svoju úroveň oprávnení a triedu dôvernosti štruktúrovaným, strojom čitateľným spôsobom, bolo by možné vynucovať politiky dátových tokov na hranici protokolu, namiesto spoliehania sa na to, že sa agent bude kontrolovať sám. Obmedzenia temporálnej logiky — vyžadujúce, aby každému post_transaction predchádzala úspešná balance_check — sú presne tým druhom invariantu, ktorý musí finančný agent zaručiť pred potvrdením zápisov.

Chýbajúcim článkom zatiaľ zostáva, že nič z toho nebolo v praxi postavené a otestované. Ale ako dizajnový slovník pre premýšľanie o bezpečnosti agentov nad účtovnými knihami je STPA + IFC tým najzásadovejším rámcom, aký som v tejto literatúre videl.

Čo si prečítať ďalej

• "Securing AI Agents with Information-Flow Control" — arXiv:2505.23643, Microsoft Research; implementuje konkrétny IFC systém (Fides) so sledovaním taints, vyhodnotený na AgentDojo; empirický doplnok k tomuto článku.
• "Breaking the Protocol: Security Analysis of the Model Context Protocol Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents" — arXiv:2601.17549; priamo analyzuje útočný povrch MCP, ktorý má rámec z tohto článku brániť.
• "Systematic Hazard Analysis for Frontier AI using STPA" — arXiv:2506.01782; novšia aplikácia metodológie STPA na AI systémy vo všeobecnosti, užitočná pre pochopenie škálovania tejto techniky.