Když programovací agent pokazí úpravu kódu, obvykle zůstane rozdíl v Gitu. Když ale přečte přístupový klíč, stáhne cizí instrukce a něco odešle ven, samotný výsledný kód už mnoho neřekne. Potřebujeme vědět, co se stalo mezi zadáním a výsledkem. Právě do téhle mezery míří agent-blackbox, otevřený projekt, o kterém jsme informovali v rychlé zprávě o záznamníku pro Claude Code.
Jeho nápad je rozumný: zaznamenávat práci agenta a před provedením kontrolovat riziková volání nástrojů. Podle nás je ovšem nejcennější jiná část dokumentace. Autor otevřeně popisuje, kdy tahle ochrana neplatí, co umí proces se stejnými oprávněními a proč může práce pokračovat i při výpadku záznamníku. Právě takové odstavce by měly být povinnou četbou před tím, než někdo agentovi svěří firemní tajemství.
Podezřelá není jedna věta, ale sled kroků
Dokumentace agent-blackbox popisuje lokální proces, který ukládá prompty, volání nástrojů a jejich výsledky. Záznamy propojuje kryptografickými otisky a podepisuje klíčem Ed25519. Rozpoznané citlivé hodnoty před uložením nahrazuje otisky; obsah záznamů a jejich krátká shrnutí šifruje klíči jednotlivých relací. Nejde o službu, kam si musíte založit účet a posílat pracovní historii.
Vedle záznamu má projekt pravidla pro kontrolu akcí. U Claude Code je spouští před provedením nástroje. Sleduje například situaci, kdy agent už četl soukromá data, následně narazil na nedůvěryhodný obsah a nyní chce komunikovat s cílem, který uživatel nezadal. Pokud se dříve přečtené tajemství objeví v odchozím volání, pravidlo má operaci zablokovat. Jiné rizikové kombinace předává člověku k potvrzení.
Tohle je užitečný pohled na prompt injection, tedy útok, při kterém se cizí obsah snaží vydávat za instrukci pro asistenta. Představme si modelový příklad: agent čte dokumentaci k opravované aplikaci a ta jej nabádá odeslat diagnostiku na cizí server. Samotné čtení dokumentace je běžná práce. Stejně tak síťový požadavek. Nebezpečí vznikne jejich spojením s daty, která má agent v dosahu.
Pravidla proto nemusejí správně pochopit každou zákeřnou větu, aby omezila některé nebezpečné následky. Mohou se ptát, zda má daná operace vůbec proběhnout. Také abstrakt výzkumu Design Patterns for Securing LLM Agents against Prompt Injections, zveřejněného v červnu 2025, zdůrazňuje bezpečnostní návrh agentů a kompromisy mezi jejich užitečností a ochranou. Není to ovšem certifikace agent-blackbox ani důkaz účinnosti jeho konkrétních pravidel.
Složení několika zdánlivě nevinných vstupů jsme na Radyz popsali také ve zprávě o útoku rozděleném mezi kanály MCP. Pro provozovatele z toho plyne praktická zásada: nestačí kontrolovat každou zprávu odděleně. Potřebuje sledovat, co agent četl a jakou akci se chystá udělat potom.
Podpis nezaručí, že se zaznamenalo všechno
Černá skříňka je dobrá metafora, dokud ji nezačneme brát jako bezpečnostní slib. Řetězený protokol umožňuje odhalovat změny zaznamenané historie. Sám o sobě ale nedokazuje, že do historie přibylo všechno, co agent provedl. Dokumentace tenhle rozdíl výslovně přiznává: integrita záznamu není jeho úplnost.
Ještě citlivější je otázka, kdo drží klíče. Ve výchozím uspořádání může podle autora jiný proces běžící pod stejným uživatelským účtem číst hlavní šifrovací i podpisový klíč. Tím získává možnost obsah rozšifrovat a historii přepsat a znovu podepsat. Pravidlo, které agentovi zakazuje sahat do složky záznamníku, není stejná překážka jako omezení vynucené operačním systémem.
Projekt proto nabízí postup pro oddělený systémový účet záznamníku. I tady ale uvádí hranici ověření: popisuje vyzkoušené uspořádání na macOS, zatímco cestu přes Linux a systemd označuje za nevyzkoušenou na skutečném stroji. To není detail, který má zmizet pod tlačítkem instalace. Správce linuxového serveru z něj musí vyvodit, že ho čeká vlastní ověření.
Další pojistkou je zveřejnit nebo uložit podepsaný otisk aktuálního konce protokolu někam, kam agent nemůže zapisovat. Pozdější přepsaná historie už se s tímto otiskem nebude shodovat. Z principu tedy nestačí mít všechny důkazy, všechny klíče a správce důkazů ve stejné složce dostupné stejnému účtu. Oddělení pravomocí je tady důležitější než délka seznamu použitých kryptografických algoritmů.
Bezpečnostní výpadek může vypadat jako hladký provoz
Agent-blackbox ve výchozím nastavení při nedostupnosti záznamníku nechává nástroje běžet dál. Dokumentace tomu říká fail-open a nabízí také režim, který při výpadku operace odmítá. První volba chrání plynulost práce, druhá dává přednost kontrole. Rozhodnutí, kterou z nich použít, patří provozovateli, nikoli náhodě při instalaci.
U pokusu s vlastním ukázkovým repozitářem je pokračování bez kontroly přijatelný kompromis. U automatizace s přístupem k produkčním údajům je to podstatně horší výchozí poloha. Bezpečnostní nástroj, jehož výpadek nepoznáme podle chování systému, vyžaduje samostatný dohled. Jinak si jen myslíme, že hlídá.
Podobně opatrně je potřeba číst výsledky testů. Autor v aktuálním README uvádí zachycení všech 62 útoků ve vlastním statickém souboru a žádný falešný poplach u 20 neškodných případů. Současně upozorňuje, že jde o známé útoky, nikoli o měření proti protivníkovi, který si pravidla prostuduje a přizpůsobí se jim. Čísla jsme nezávisle nereprodukovali. Vyvozovat z nich stoprocentní ochranu by bylo chybné.
Projekt přiznává také technické mezery: pracuje s heuristikami, některé zakódované či rozdělené tajné hodnoty mohou uniknout detekci a u shellových příkazů kontroluje příkazovou řádku, nikoli celý obsah následné šifrované síťové komunikace. Smyslem takového nástroje je ztížit rizikovou akci a zachovat podklady k jejímu vyšetření. Kdo ho prodává jako důvod zrušit ostatní omezení, používá ho obráceně.
Záznamník se může stát nejzajímavější složkou na disku
Samostatný dokument o soukromí ukazuje druhou cenu důkladného záznamu. Protokol obsahuje informace o relacích, nástrojích a rozhodnutích; část metadat zůstává čitelná. Automatické mazání je ve výchozím nastavení vypnuté. Lokální uložení proto neznamená, že se o dobu uchovávání nemusíme starat.
Šifrování po relacích dovoluje zničit příslušný klíč a tím znepřístupnit obsah i v dříve vytvořených zálohách, pokud tyto zálohy neobsahují použitelné kopie klíčů. Dokumentace přitom upozorňuje, že metadata a důvody rozhodnutí mohou zůstat. Rozpoznávání přístupových klíčů navíc není totéž jako odstranění všech citlivých obchodních informací. Text zákaznické reklamace nemusí připomínat heslo, a přesto do veřejného logu nepatří.
Zvláštní pozornost si zaslouží volitelné zaznamenávání úplných požadavků a odpovědí modelu. Podle dokumentace je nejprve zapisuje samotný Claude Code v otevřené podobě a záznamník je až následně čistí a přesouvá, s možnou prodlevou přibližně tří minut. Tohle nastavení bychom pro běžný provoz s citlivými daty nezapínali bez konkrétního důvodu a kontroly celé cesty ukládání.
Před pilotním nasazením bychom chtěli znát odpovědi na několik prostých otázek: kdo může číst klíče, kdo měnit kontrolní mechanismy a co se stane při výpadku? Dále kam se ukládá nezávislý otisk historie, jak dlouho se uchovává obsah a kdo řeší varování? Vlastní test má zahrnout i běžnou práci týmu, protože ochrana, která stále žádá potvrzení neškodných operací, lidi naučí potvrzovat bez čtení.
Takový záznamník má smysl doplnit omezením oprávnění a odděleným pracovním prostředím. Pro sandboxing platí jednoduchý požadavek: agent nemá mít přístup k datům a síťovým cílům, které pro úkol nepotřebuje. Ani vlastní infrastruktura to nezařídí automaticky. Jak ukazuje projekt Valet pro agenty na vlastním serveru, otázka hostingu a otázka pravomocí agenta jsou dvě různé věci.
Agent-blackbox jsme neposuzovali jako hotovou firemní bezpečnostní službu a neprovedli jsme jeho nezávislý audit. Z dokumentace ale vychází užitečná a dost konkrétní teze: odpovědnost za agentovu práci potřebuje stopu, která je mimo jeho vlastní vyprávění. Tým, jenž agentovi přiděluje přístupové údaje, musí umět vysvětlit i to, kdo hlídá záznamník a kdo zasáhne, když přestane fungovat. Samotný nápis „černá skříňka“ tenhle problém nevyřeší.
