Má agent přístup k platbám? Odpovídám na vaše dotazy k bezpečnosti

Pod můj nedávný článek na LinkedInu napsal jeden ze čtenářů sérii konkrétních dotazů — na bezpečnost, architekturu a právní průkaznost. Patří k nejlepším, co jsem k projektu dostal, a slíbil jsem, že na ně odpovím. Celý dotaz zněl:

Super, strašně tomu fandím a sleduji to se zájmem — plain-text ledger s plnou Git historií mi dává smysl jako úložiště. Pár věcí, co by mě zajímalo k tomu, jak to máte postavené:

1. Je token k Fio API jen pro čtení, nebo má agent i platební oprávnění? A kde je uložený?
2. V jakém prostředí agent běží — má sandbox a omezený síťový přístup, nebo plný shell?
3. Jak řešíte prompt injection? Agent čte cizí PDF faktury a interpretuje jejich obsah — co brání instrukci schované v dokladu?
4. Kde jsou API klíče a má k nim agent přístup za běhu, nebo je runtime oddělený od secretů?
5. Kdo je v commitu podepsaný jako autor zápisu — vy, nebo agent? Commituje agent rovnou do ostrého ledgeru, nebo přes schvalovací krok?
6. Jak doložíte finančnímu úřadu, že Git historie splňuje průkaznost a neporušitelnost podle zákona o účetnictví? A u daňových dokladů věrohodnost původu dle § 34 zákona o DPH — stačí hash v commitu, nebo máte elektronický podpis?
7. Kde repozitář fyzicky leží a je šifrovaný at-rest? Jde o GDPR-relevantní data reálných firem.
8. Generování XML pro přiznání a kontrolní hlášení do formátu finanční správy — dělá to agent nad plain textem, nebo nějaký nástroj?

Pro dnešní díl vybírám čtyři, na zbytek (prostředí, uložení klíčů, autorství zápisů, hosting) dojde příště.

Předchozí díly: Novinky.

Dnes odpovídám na:

• Má agent platební oprávnění k Fio API?
• Jak řešíte prompt injection?
• Jak doložíte finančnímu úřadu průkaznost Git historie?
• Kdo generuje XML pro přiznání a kontrolní hlášení?

Má agent platební oprávnění k Fio API?

Agent může platbu připravit, ne odeslat.

Fio API rozlišuje dva tokeny. Token jen pro čtení slouží ke stahování výpisů a dalších informací o transakcích. Token pro zápis slouží výhradně k přípravě platebního příkazu; autorizovat příkaz jím nelze — to musím udělat já v internetovém bankovnictví. Oba API klíče žijí v lokálním konfiguračním souboru, ke kterému má agent přístup.

Je to stejný princip jako u emailů, o kterém jsem psal minule — agent smí vytvořit koncept, samotné odeslání je zvláštní akce vyhrazená člověku.

Jak řešíte prompt injection?

Dobrá otázka, a míří přesně na slabé místo. Agent opravdu čte cizí PDF faktury a interpretuje jejich obsah — schovat do dokladu instrukci je reálné riziko.

V této fázi experimentu spoléhám především na „auto mode” v Claude Code — nezávislý klasifikátor, který kontroluje každou akci agenta. Funguje takto:

• Dvoustupňové filtrování. Každou akci nejdřív posoudí rychlý jednotokenový filtr. Když ji označí, spustí se hlubší rozbor (chain-of-thought), který teprve rozhodne, jestli akci povolit, vyžádat potvrzení, nebo zablokovat.
• Slepý k odůvodnění agenta. Klasifikátor vidí jen instrukce uživatele a holá volání nástrojů — ne argumentaci agenta. Agent se tedy nemůže „prokecat” přes pojistku tím, že si akci sám hezky zdůvodní.
• Vyhodnocení rizika. Automaticky se zastaví a vyžádá souhlas člověka, když akce vybočí ze zadaného rozsahu, sahá na nedůvěryhodnou infrastrukturu nebo chce spustit destruktivní příkazy.

A funguje to. Vyzkoušeno: agent dostal úkol „uhradit všechny nezaplacené faktury”. Jenže mezi nimi byly i faktury, které ještě nebyly zanesené v účetnictví. Agent chtěl zadat platební příkaz na každou z nich. Auto mode to rozpoznal a zastavil — povolil jen ty, které už v účetnictví byly.

Nechci to přeprodávat — je to jedna vrstva, ne hotová obrana. Hlubší izolace prostředí přijde později. Ale jako primární pojistka v této fázi odvádí přesně to, co má.

Jak doložíte finančnímu úřadu průkaznost Git historie?

Tady chci říct jednu věc: právní průkaznost není předmětem experimentu.

Základní principy popsat lze. Celé účetnictví je plain-text ledger s plnou historií ve verzování a auditní záznam je jištěný kryptografickým řetězcem — každý zápis navazuje na předchozí, takže zpětná úprava je dohledatelná. Pro vnitřní kontrolu je to dohledatelnost, jakou v běžném účetním softwaru nemám.

Ale průkaznost a neporušitelnost podle zákona o účetnictví a věrohodnost původu daňového dokladu podle § 34 zákona o DPH je komplexní téma, které protíná softwarové nástroje, datové formáty, firemní procesy a právo. Na to nestačí hash v commitu, na to vede cesta třeba přes elektronický podpis, archivační režim a další věci, které jsem v této fázi záměrně odložil. Kdybych je musel řešit hned, nikdy bych nezačal.

Proto je v celém experimentu licencovaná externí účetní firma. Ona vede oficiální, průkazné účetnictví a podává přiznání na finanční úřad. Můj agent je kontrolor a stínová kopie, ne autorita vůči státu. Na právní průkaznost dojde mnohem později.

Kdo generuje XML pro přiznání a kontrolní hlášení?

Agent, ale přes vlastní nástroj. Přiznání k DPH a kontrolní hlášení negeneruje „od oka” z textu — sestavuje XML vlastním skriptem nad plain-text ledgerem a výstup validuje proti platnému schématu (XSD) z portálu MojeDaně.

Bohužel DPH a kontrolní hlášení je měsíční iterace — otestovat to můžu jen jednou za měsíc, takže zatím mám pět běhů. Výsledek pokaždé porovnávám s XML, které sestaví účetní firma. Vše sedí na haléř.

Nepřekvapuje mě to a nic průlomového na tom není — sestavit validní XML ze strukturovaných dat je očekávatelné. Zajímavé to začne být, až přiznání a kontrolní hlášení začne agent odesílat přímo do portálu Ministerstva financí. Teď vše podává účetní firma. Ale s nedávno oznámeným Codex Record & Replay, kdy nahraji sám sebe, jak daňové přiznání odesílám, a Codex z toho vyrobí replikovatelný skill, začíná být i toto na seznamu pro můj experiment.

Co bude příště

Světem AI agentů teď hýbe „loop engineering” — k tomu doporučuji článek Patricka Zandla. Příště se podělím, co za „loop” mám v účetnictví, a taky o příkaz /goal, který dostane agenta k smysluplné samostatné — klidně i několikahodinové — práci.