Bezpečný pilot AI v e-mailu: čtení, omezení a potvrzení

Proč je e-mail pro AI rizikový

AI může z přijaté zprávy vyčíst cizí text a považovat ho za pokyn. Stačí, aby e-mail obsahoval soukromé údaje, smlouvu, fakturu, odkaz nebo přiložený dokument. Model pak nemusí jen chybně vyhodnotit data. Agent může na jejich základě rozhodnout a provést akci s vedlejším efektem, například odeslat zprávu.

Proto se připojení AI k e-mailu neřeší jen kvalitou modelu, ale návrhem oprávnění a schvalování. V diskuzi se objevují dva společné názory: buď AI do schránky nepouštět, nebo začít velmi omezeným pilotem. Praktická varianta mezi nimi je oddělená schránka nebo přístup pouze ke čtení.

Odborně se tento postup označuje jako princip nejmenších oprávnění a human-in-the-loop, tedy zapojení člověka do rozhodování. Přesnější je mluvit o agentovi s omezeným rozhraním: může data číst, ale nemá oprávnění je bez omezení měnit nebo odesílat.

Nejmenší bezpečný pilot

Jako pilot zvolte jednu schránku nebo jednu složku, kterou běžně používáte jen k neosobním záležitostem. Nejprve zpracujte jen zprávy z tohoto vybraného prostoru. Soukromou hlavní schránku ponechte mimo dosah integrace.

Úkol musí mít jediný měřitelný výsledek. Dobrým příkladem z diskuse je převést data z potvrzení nákupů do tabulky: název obchodníka, datum, částku a případně číslo objednávky. AI může výsledek navrhnout, ale první verze by měla zůstat bez zápisu do vašich významných systémů.

Nechte agenta připravovat návrh odpovědi nebo seznam úkolů. Vlastní odeslání, přesun, úpravu či smazání ponechte člověku. U každého výstupu zkontrolujte, zda odpovídá zadanému úkolu, zda nechybí částky a zda model nepřidal informace, které v podkladech nebyly.

Pilot veďte jako malý, uzavřený cyklus: omezený počet zpráv, jedno pravidlo na kontrolu a záznam chybných výstupů. Teprve potom rozšiřujte počet zpráv nebo povolené akce.

Oprávnění: čtení, mazání a odesílání

Účet připojený k AI by měl mít jen právo číst jednu vybranou složku nebo alias. Token nechte krátkodobý a nepoužívejte trvalé „always allow“. Agentovi neudělujte široká práva kvůli jednoduchosti integrace.

Mazání, přesuny, změny příznaků, vytváření příloh a odesílání zpráv oddělte od čtení. Pokud platforma skutečně podporuje přístup typu read-only, využijte jej. Jestliže oprávnění nelze odebrat, každou zápisovou akci nechte ručně potvrdit. V diskuzi se tento vzorec objevuje jako praktická zkušenost s propojením přes MCP, kde lze čtení ponechat bez potvrzení, zatímco zásah do schránky vyžaduje schválení.

U ChatGPT je důležité rozlišit dvě různé úrovně kontroly. Nastavení „Allow read actions“ umožňuje číst zprávy bez dalšího dotazu, ale před provedením změny se ChatGPT zeptá. Nejde však o čistý OAuth scope gmail.readonly; aplikace OpenAI pro Google uvádí scope gmail.modify. Skutečná míra omezení proto závisí i na implementaci a konfiguraci integrace.

MCP samo o sobě e-mailová oprávnění nevynucuje. Server může vystavit samostatné nástroje pro čtení a zápis a doporučuje schválení citlivých operací, ale oddělení čtení od odesílání musí zajistit návrh nástrojů a klient. Anotace readOnlyHint je pouze nápověda, nikoli technická záruka.

Nepoužívejte přihlašovací údaje hlavního účtu, pokud lze vytvořit účet služební. Oddělte také přístup k přílohám, kalendáři a sdíleným souborům. Každá nová integrace je samostatná proměnná rizika, kterou je nutné znovu posoudit.

Prompt injection není jen „špatný prompt“

Prompt injection znamená, že útočník vloží do e-mailu, PDF nebo jiného dokumentu text, který má model vykonat. Útok nemusí obsahovat malware ani výrazný požadavek na heslo. Může se schovat v uvozovkách, patičce, bílém textu nebo v příloze a maskovat se jako další pracovní pokyn.

Model obvykle nemá oddělený kanál pro data a instrukce. System prompt, text zprávy, OCR z PDF i výsledek nástroje se skládají do jednoho kontextu, kde se jejich význam může smíchat. Instruction hierarchy je pouze měkká priorita, nikoli technicky vynutitelná hranice. Upozornění v system promptu proto útok může ztížit, ale samo o sobě jej nezablokuje.

Nedůvěryhodné zprávy oddělte od pokynů, na nichž provádění závisí. Při čtení je zobrazujte jako data, nikoli jako autoritu. Jakmile se obsah načte do kontextu, ponechte nástroje s vedlejším efektem vypnuté, dokud člověk neschválí konkrétní akci.

Oddělená schránka a potvrzení zápisu

Vybrané zprávy přesměrujte do samostatné schránky a AI připojte pouze k ní. Uživatel si tak ponechá kontrolu nad tím, co do testovacího prostoru vstoupí. Filtry mohou omezit přílohy, velikost souborů nebo počet zpráv, ale samy o sobě nejsou bezpečnostní hranicí.

Vyžadujte lidské potvrzení nejen u odesílání, ale i u mazání, přesunu, úpravy příznaků a zápisu do jiných aplikací. Potvrzení musí být konkrétní: ukažte příjemce, přílohy, částku nebo změnu, která se má provést. Nejlepší je zobrazit finální akci až po schválení a před odesláním vytvořit čerstvý kontext, do kterého se původní nedůvěryhodné zprávy už nedostanou.

Tento postup je doporučený bezpečnostní mechanismus, nikoli automatická vlastnost všech platforem. Záleží na tom, zda jej konkrétní integrace skutečně podporuje.

Agent s potvrzováním může připravit návrh, ale vlastní jednání zůstává lidskou odpovědností. Jde tedy o jinou úroveň kontroly než u běžného chatbota.

Jak to funguje pod kapotou a kde má postup limity

Nejrizikovější kombinace, známá jako „lethal trifecta“, je agent, který současně přistupuje k soukromým datům, čte libovolný cizí obsah a má možnost provést odchozí akci. Omezení jednotlivých promptů tuto kombinaci neodstraní.

Spolehlivější obrana proto stojí za modelem: krátkodobý token, účet s minimálními právy, oddělená schránka, zablokované vedlejší efekty a policy decision point neboli místo, kde pravidlo vyžaduje lidské schválení. Model nemůže toto rozhodnutí přepsat pouhým textem v kontextu.

Oddělovače, překódování nedůvěryhodného textu a filtry typu Prompt Shields mohou útok zeslabit, ale neposkytují deterministickou ochranu. Prompt Shields je ochranný filtr Microsoftu v Azure AI Content Safety a Microsoft Foundry proti útokům v promptech a dokumentech; není to funkce Google Gemini. Zároveň samotné odmítnutí e-mailu není řešení: chráněný pilot musí odlišit data od pokynů, omezit dopad chyby a umožnit audit.

Kdy použít dedikovaný nástroj

Pro jednorozměrné čtení a klasifikaci postačí model s připojeným e-mailem v režimu read-only. Pro složitější extrakci z příloh je vhodná specializovaná aplikace s vlastním parserem, která přijímá pouze dokumenty předem připravené k danému úkolu. Pro práci napříč e-mailem, kalendářem a soubory je potřeba AI agent s oddělenou pamětí, nástroji a schvalovacím krokem.

Nástroje jako ChatGPT, Claude nebo Gemini mohou e-mail číst, ale samotná zvolená platforma nezaručuje bezpečné oddělení oprávnění. To musí zajistit konfigurace připojení a provozní pravidla.

Co si z toho vzít

• Začněte čtením jedné oddělené složky a jedním úkolem s měřitelným výstupem.
• Udělujte jen nejmenší potřebná oprávnění; mazání a odesílání oddělte od čtení.
• Považujte obsah e-mailu a příloh za nedůvěryhodná data, ne za autoritativní pokyny.
• Vyžadujte konkrétní lidské potvrzení každé akce s vedlejším efektem.
• Zaznamenejte chyby pilotáže a rozšiřujte oprávnění až po jejich vyřešení.
• U citlivých dat zvažte oddělený nebo lokální systém místo širšího cloudového přístupu.