Největší problém agentů nebude v tom, že umějí zavolat nástroj. Bude v tom, že si mezi sebou začnou předávat pravomoc a na konci řetězce už nikdo přesně neví, co vlastně schválil člověk na začátku. Čerstvý projekt Aroha Protocol zkouší tento problém obejít podepsaným řetězcem mandátů: každý další agent smí původní oprávnění pouze zúžit, nikdy rozšířit.
Je to zajímavější nápad než další dashboard s barevnými kolečky a počtem běžících agentů. Pokud má jeden agent vyhledat nabídky, druhý porovnat podmínky a třetí provést nákup, nestačí vědět, že všichni prošli nějakým přihlášením. Systém musí umět prokázat, kdo koho pověřil, co bylo povoleno, co se po cestě zúžilo a zda šlo pravomoc ještě odvolat.
Když se z delegování stane tichá změna zadání
Představme si člověka, který pověří osobního agenta, aby našel letenku do pěti set dolarů. Tento agent si vezme pomocníka na vyhledávání, dalšího na kontrolu termínů a třetího na samotnou rezervaci. Každý krok může vypadat rozumně. Jenže pokud každý nový účastník dostane vlastní token a vlastní výklad úkolu, původní limit se po několika předáních snadno rozpadne na neurčité „dokonči to“.
Právě tady začíná skutečné delegování oprávnění. Nejde jen o identitu agenta ani o to, zda má přístup k API. Jde o zachování původního záměru v situaci, kdy práci vykonává někdo jiný, v jiném procesu a možná pod jiným provozovatelem.
Aroha v repozitáři na GitHubu popisuje model, v němž člověk vystaví první mandát s povolenými akcemi, limitem útraty a časovou platností. První agent pak vytvoří užší mandát pro dalšího účastníka. Pokud původní limit dovoluje utratit 500 dolarů, další článek může dostat 300 dolarů a pouze konkrétní typ nákupu. Nemůže si připsat právo poslat peníze jinam nebo prodloužit platnost oprávnění.
Kryptografie hlídá hranice, ne smysl úkolu
Tohle je důležitá hranice, kterou marketing agentických systémů často schovává. Podepsaný řetězec může ověřit, že žádný článek nebyl podvržený, že podpis odpovídá předchozímu delegujícímu agentovi a že se rozsah oprávnění nezvětšil. Neumí ale rozhodnout, jestli člověk zadal rozumný úkol, jestli je cena férová nebo jestli má agent vůbec sahat na konkrétní databázi.
Aroha proto není náhrada za politiku přístupu. Je to důkazní a vynucovací vrstva mezi záměrem a konkrétní akcí. Vývojář stále musí určit, co znamená „hledat“, co znamená „objednat“ a kdy je nutné zastavit se u člověka. Kryptografie jen ztíží cestu k tomu, aby si agent během delegování přepsal pravidla ve svůj prospěch.
To je podobné jako u sandboxingu. Izolované prostředí může zabránit procesu v přístupu k části systému, ale samo neví, zda je konkrétní požadavek legitimní. V dřívějším článku o izolaci MCP serverů jsme řešili stejnou hranici z jiné strany: kontejner oddělí proces, ne jeho úmysl. Aroha se snaží doplnit právě to, co kontejner neumí — zachovat původ oprávnění mezi několika službami.
Řetěz musí umět říct nejen ano, ale i ne
Na návrhu je sympatické, že nepočítá pouze s úspěšnou akcí. Dokumentace Arohy mluví také o odvolání mandátu a o podepsaných potvrzeních povolených i odmítnutých akcí. V praxi je to podstatnější než další log s větou „tool call completed“. Po incidentu potřebujete vědět nejen to, co agent udělal, ale také jaké oprávnění předložil a proč mu systém dovolil pokračovat.
Znamená to také, že záznam nesmí končit u posledního agenta. Pokud člověk pověřil asistenta, asistent orchestrátora a orchestrátor vyhledávací službu, musí být možné vrátit se po řetězci až ke kořenu. Jinak dostaneme známý provozní výsledek: systém sice něco provedl, ale nikdo nedokáže vysvětlit, kdo to schválil.
Tady se Aroha potkává s problémem, který jsme rozebírali u agenta, který narazil na placený přístup. Technická dostupnost není totéž co legitimní oprávnění. Agent může mít cestu k tokenu, účtu nebo nástroji, ale z toho ještě neplyne, že smí utratit peníze, obejít podmínku služby nebo spojit data z dalšího zdroje.
MCP a A2A nejsou odpověď na pravomoc
Aroha se nesnaží nahradit protokoly, přes které spolu agenti komunikují. Repozitář uvádí adaptéry pro MCP, A2A, LangChain a funkce OpenAI. To dává smysl: problém není v tom, že by MCP nebo A2A neuměly přenést zprávu. Problém je, že přenos zprávy sám o sobě neříká, jak široký mandát smí příjemce použít.
Rozdíl je podobný jako mezi poštou a plnou mocí. Pošta doručí obálku, ale neověří, zda adresát smí prodat dům. Identita řekne, kdo obálku poslal, ale ne vždy vysvětlí, co přesně smí příjemce udělat. Aroha chce do tohoto řetězce vložit další, kryptograficky ověřitelnou odpověď: tento konkrétní agent dostal od tohoto konkrétního předchůdce právě tento zúžený rozsah.
Pro firemní nasazení je to důležité hlavně ve chvíli, kdy se agenti skládají z komponent od různých dodavatelů. Vlastní pravidlo uvnitř jednoho frameworku nemusí přežít přechod do cizí služby. Podepsaný mandát může být přenositelnější, ale jen pokud se na jeho formátu, ověřování a významu skutečně shodnou všechny strany.
Aroha zatím není standard ani hotová bezpečnostní vrstva
Tady je nutné ubrat marketingový tón. Samotný návrh specifikace Aroha uvádí, že jde o draft, který nebyl předložen žádné standardizační organizaci, a že metoda did:aroha není registrovaná v registru W3C. To neznamená, že návrh je špatný. Znamená to, že jeho pravidla zatím nejsou veřejně přijatým standardem, o který se dá opřít bez dalšího ověřování.
Stav repozitáře je navíc čerstvý. GitHub uvádí vznik projektu 25. října 2026 a poslední změny 27. října 2026. Ve veřejném repozitáři nejsou tagy ani GitHub Releases; část balíčků byla podle dokumentace vydána z privátního vývojového repozitáře. Kód je pod licencí Apache-2.0, ale licence sama o sobě není důkazem bezpečnosti, adopce ani provozní zralosti.
Ještě důležitější je rozdíl mezi SDK a běžícím produktem. Vlastní stavová dokumentace projektu odděluje kontroly, které odmítne knihovna, od toho, co skutečně vynucuje runtime. Některé verifikace jsou v SDK testované, ale runtime je zatím nepoužívá. Projekt také uvádí, že nemá nezávislý bezpečnostní audit ani SOC 2 report a že část provozních procesů zůstává ve fázi návrhu.
To je přesně ta informace, která by měla být u podobných projektů vidět hned. Bezpečnostní knihovna může mít správně napsanou kontrolu podpisu, ale pokud ji aplikace nezavolá před každou citlivou akcí, výsledná ochrana je nulová. Test, že funkce umí odmítnout špatný řetězec, není totéž jako důkaz, že celý produkt nepustí špatný požadavek do produkce.
Největší test přijde u peněz a dat
Aroha správně spojuje oprávnění s limitem útraty, časem, povolenými akcemi a záznamem výsledku. Tím se dostává blíž realitě než obecné tvrzení, že agent má „přístup k nástrojům“. Ve skutečném provozu totiž nestačí vědět, že agent smí pracovat s rezervační službou. Musíte vědět, zda smí pouze hledat, vytvořit návrh, držet rezervaci, nebo také zaplatit.
Stejná otázka platí u firemních dat. Agent může mít oprávnění číst smlouvy, ale ne exportovat je. Může získat seznam zákazníků, ale ne spojit ho s marketingovým účtem. Může připravit změnu v databázi, ale ne ji sám potvrdit. Čím více agentů se do práce zapojí, tím méně stačí obecné role typu „analytik“ nebo „asistent“. Potřebujete hranice konkrétní operace.
Právě tady se ukáže, jestli bude rozpočtování AI agentů znamenat jen počítání tokenů a API volání, nebo také řízení finančního a datového rizika. Levnější agent, který bez kontroly utratí peníze nebo rozešle citlivý soubor, není levný. Jen se účet za jeho chybu objeví jinde.
Pravomoc se musí zmenšovat rychleji než počet agentů roste
Aroha přichází s jednoduchou intuicí: čím dál je agent od člověka, tím menší by měl mít prostor pro vlastní akci. Ne proto, že by každý další agent byl automaticky nebezpečný, ale protože s každým předáním přibývá možnost špatného překladu, ztraceného kontextu nebo konfliktu mezi pravidly různých služeb.
Tohle je podle mě správný směr. Agentické systémy se dnes často prodávají jako řetězec schopností, ale odpovědnost se v tom řetězci ztrácí. Jeden agent plánuje, druhý hledá, třetí kliká a čtvrtý zapisuje. Když se něco pokazí, všichni ukážou na předchozí článek. Podepsaná a zúžená delegace alespoň vytváří technickou stopu, která takové alibi komplikuje.
Současně bych z Arohy nedělal hotovou odpověď na agentní bezpečnost. Je to čerstvý návrh infrastruktury, ne nezávisle ověřený standard. Jeho hodnota se ukáže až ve chvíli, kdy bude několik různých implementací odmítat stejné neplatné mandáty, kdy odvolání skutečně zastaví běžící workflow a kdy provozovatelé dokážou dohledat nejen podpisy, ale i konkrétní dopad akce.
Do té doby je nejrozumnější číst Arohu jako připomínku základní věci: agentovi nemáme dávat plnou moc jen proto, že umí dokončit úkol. Má dostat přesně vymezený mandát, který lze ověřit, zmenšit, odvolat a po akci zpětně vysvětlit. Pokud tohle nedokážeme, není problém v tom, že agentům chybí autonomie. Problém je, že jsme jim dali pravomoc bez pořádné účetní knihy.
