Bezpečnost CRM a AI integrací: data mohou uniknout i přes platná oprávnění
V předchozím článku „MCP a CRM: Jeden standard pro propojení AI s firemními daty“ jsme vysvětlili, jak Model Context Protocol sjednocuje rozhraní mezi AI aplikací a firemními systémy. Teď navážeme na konkrétní rozhodnutí při návrhu: jak zajistit, aby nové rozhraní neotevřelo širší přístup, než firma zamýšlela.
Nejde o tvrzení, že za úniky dat nestojí útočníci. Špatně nastavená oprávnění mohou zneužít také oni. Problém je v tom, že integrace může vydat data přes běžné, technicky platné volání. Samotná úspěšná autentizace proto ještě neznamená, že je konkrétní požadavek správně povolený.
Když obchodní asistent dostane přístup ke všem klientům
Představme si modelovou firmu, která chce obchodníkům usnadnit přípravu schůzek. Asistent má dohledat poslední komunikaci, otevřené příležitosti a domluvené další kroky. Integrace vznikne pod jedním servisním účtem, který má přístup k celému CRM.
Obchodník v běžné aplikaci vidí jen své zákazníky. Přes asistenta se ale zeptá na jinou firmu a dostane přehled jejího obratu, individuálních cen nebo interních poznámek. CRM požadavek přijme, protože servisní účet tato data číst smí. Asistent tak vytvoří další cestu k informacím, která nerespektuje původní hranice.
Nemusí přitom dojít k odeslání mimo organizaci. Už zpřístupnění neveřejných informací nesprávnému internímu uživateli představuje bezpečnostní problém. Následné vložení odpovědi do sdíleného dokumentu může okruh příjemců rozšířit ještě dál.
OWASP popisuje používání privilegované společné identity a zbytečně široké pravomoci AI nástrojů jako součást rizika Excessive Agency. Doporučuje omezit dostupné funkce a jejich oprávnění a kontrolovat přístup v navazujících systémech. [1]
Přihlášení uživatele neřeší přístup ke konkrétnímu záznamu
Autentizace ověřuje identitu. Autorizace rozhoduje, co daná identita smí udělat. U AI integrace je potřeba propojit obě otázky až ke konkrétnímu CRM záznamu.
Přihlášení do firemního asistenta samo neříká, zda uživatel smí načíst určitou nabídku, upravit kontakt nebo zobrazit obchodní marži. Role „obchodník“ také nemusí stačit. Přístup může záviset na vlastníkovi zákazníka, týmu, pobočce nebo organizaci, do které záznam patří.
OWASP doporučuje kontrolovat oprávnění při každém požadavku a přístup ve výchozím stavu odmítat. Přístup k jednomu objektu určitého typu automaticky neopravňuje k přístupu ke všem ostatním. [2]
Při návrhu proto požadujte kontrolu na serveru ještě před vydáním dat. Pokyn v systémovém promptu „zobrazuj pouze vlastní klienty“ není spolehlivou bezpečnostní hranicí. Stejně tak nestačí skrýt nepovolený nástroj v uživatelském rozhraní, pokud jeho volání backend přijme.
Rozsah oprávnění musí odpovídat úkolu
Princip nejmenšího oprávnění znamená poskytnout právě takový přístup, který daný úkol vyžaduje. U asistenta pro přípravu schůzek to může být čtení omezeného souboru záznamů a polí. Oprávnění měnit cenové podmínky ani exportovat celou databázi k tomu nejsou potřeba.
Následující tabulka je modelovým návrhem. Konkrétní hranice musí vycházet z vašich procesů a citlivosti dat.
| Úkol asistenta | Potřebný přístup | Co má zůstat omezené |
|---|---|---|
| Připravit podklady na schůzku | Vybraná pole dostupného zákazníka | Cizí portfolio a nepotřebné interní údaje |
| Navrhnout follow-up | Relevantní komunikace a kontext obchodu | Automatické odeslání zprávy |
| Založit úkol | Vytvoření úkolu u povoleného záznamu | Změna cen nebo vlastnictví zákazníka |
| Připravit report pro vedení | Schválené ukazatele a agregace | Neomezený export všech kontaktů |
Také nástroje mají mít konkrétní účel. Funkce „založit úkol k příležitosti“ se vymezuje snáz než univerzální nástroj „proveď libovolný požadavek na CRM API“. U každého nástroje lze určit povolené vstupy, cílové objekty i očekávaný výsledek.
To je praktický začátek integrace AI do CRM nebo vlastního systému: nejprve popsat práci, kterou má asistent zjednodušit, a podle ní vymezit jeho schopnosti.
Read-only režim chrání před změnami, ale neřeší celý tok dat
Pilot v režimu pouze pro čtení snižuje riziko nechtěných zápisů. Neznamená ale, že všechna zpřístupněná data jsou bezpečná. Asistent může citlivou informaci zobrazit nesprávnému člověku nebo ji zahrnout do výstupu s širším okruhem příjemců.
V modelovém příkladu pro přípravu schůzky stačí poslední domluvený krok, kontaktní osoba a stav příležitosti. Celá historie fakturace, přílohy smluv a neveřejná cenová kalkulace mohou být zbytečné. Rozhodnutí, která pole vrátit, proto udělejte v integrační vrstvě před předáním modelu.
Samostatně zmapujte, kam informace putují dál: do AI aplikace, k poskytovateli modelu, do historie konverzace, exportu nebo sdíleného dokumentu. Ověřte podmínky konkrétního produktu a nastavení jeho uchovávání dat. Označení „firemní AI“ samo tento přehled nenahrazuje.
Prompt injection může z běžného obsahu udělat falešný pokyn
CRM často obsahuje texty od zákazníků, importované e-maily a přílohy. Prompt injection je pokus ovlivnit chování modelu vloženým pokynem. U nepřímé varianty se pokyn nachází v obsahu, který asistent načítá při plnění běžného úkolu. OWASP mezi takové vstupy řadí například e-maily a externí dokumenty. [3]
Modelový scénář: asistent shrnuje zákaznickou komunikaci. V jednom e-mailu je pokyn, aby do odpovědi přidal seznam dalších klientů a použil nový externí kontakt. Tento text má zůstat předmětem zpracování, nikoli získat pravomoc měnit zadání uživatele.
Z pohledu návrhu je důležité, jak daleko může takový pokus dojít. Má-li asistent omezené čtení a nemá nástroj k odesílání, některé následky jsou technicky zablokované. Pokud může zároveň načíst celé CRM a poslat zprávu na libovolnou adresu, je dopad potenciální chyby výrazně širší.
Filtrování obsahu a oddělení instrukcí pomáhají, ale nenahrazují autorizaci ani kontrolu nástrojů. OWASP doporučuje validovat navržené parametry a vynucovat oprávnění v prováděcím kódu mimo model. [3]
U MCP kontrolujte také identitu a určení tokenů
MCP sjednocuje komunikaci; oprávnění ke konkrétním zákazníkům musí stále vynucovat implementace. U vzdáleného serveru oddělte přístup AI klienta k MCP serveru od přístupu serveru k navazujícímu CRM.
Oficiální bezpečnostní dokumentace MCP zakazuje token passthrough, tedy přijímání tokenů bez ověření, že jsou určené MCP serveru, a jejich přeposílání navazujícímu API. Popisuje rizika obcházení kontrol i ztráty přehledu o volajících. [4]
Pro projekt z toho plyne konkrétní otázka: jak server ověřuje volajícího a jak překládá jeho oprávnění do CRM? Delegovaný přístup podle uživatele může zachovat jeho kontext. Servisní účet může být vhodný pro automatizaci, ale vyžaduje samostatně vymezené pravomoci a pravidla. Noční report například potřebuje určit vlastníka, příjemce a rozsah dat i bez aktuálně přihlášeného člověka.
Potvrzení musí patřit ke konkrétní akci
Pro citlivé operace navrhněte kontrolu před provedením. Uživatel má vidět cílový záznam, změněná pole a u zprávy také příjemce a obsah. Souhlas s připojením CRM při instalaci nepopisuje všechny budoucí operace.
V modelovém workflow může asistent samostatně navrhovat follow-upy, zatímco odeslání vyžaduje schválení konkrétního návrhu. Pokud se po schválení změní příjemce nebo obsah, původní souhlas už nemá pokrývat novou podobu zprávy.
Míru kontroly nastavte podle dopadu. Založení osobního úkolu a hromadná změna obchodních podmínek potřebují odlišná pravidla. Plošné potvrzování každého čtení může práci zdržovat; smysluplnější je soustředit kontrolu na operace s vyšším rizikem.
Auditní stopa a testy mají ukázat skutečné hranice
Navrhněte záznamy tak, aby šlo spojit požadavek uživatele, použitého klienta, nástroj, rozhodnutí o oprávnění a výsledek. Log však nemá být automatickou kopií veškeré komunikace. OWASP doporučuje z logů vylučovat nebo chránit například přístupové tokeny, hesla a citlivé údaje. [5]
Před nasazením ověřte modelové scénáře s testovacími daty: přístup k cizímu zákazníkovi, změněné ID záznamu, odebrané oprávnění, nepovolený export a instrukci ukrytou v e-mailu. U více organizací ověřte také oddělení jejich dat. Výsledkem má být důkaz, že zamítnutá akce opravdu nevydala data ani nevytvořila změnu.
Určete rovněž postup pro zastavení integrace. Kdo může zablokovat nástroj nebo odvolat přístup? Jak se změna promítne do běžících procesů a již vytvořených kopií? Tyto otázky je snazší vyřešit před pilotem než při prvním incidentu.
Co si nechat ukázat před spuštěním
Před schválením pilotu požadujte konkrétní odpovědi:
- Čí jménem asistent pracuje a kde se kontroluje přístup k záznamům?
- Jaká pole a nástroje dostává pro každý podporovaný úkol?
- Kam data putují a kdo vidí výsledné výstupy?
- Které operace vyžadují kontrolu a jak je schválení svázané s jejich obsahem?
- Jaké nepovolené scénáře byly otestované a jak lze integraci zastavit?
Pokud odpovědi ukazují na jeden administrátorský účet a pravidla pouze v promptu, návrh potřebuje dopracovat. Užitečný pilot může začít jedním procesem s jasnými hranicemi a postupně přidávat další schopnosti podle ověřených výsledků.
Plánujete propojit AI s CRM nebo rozšířit stávající integraci? Proberme váš systém, potřebná oprávnění a vhodný rozsah prvního pilotu.
