AI agenti už nejsou jen nástroje na psaní textů nebo rychlé vyhledávání. Stále častěji dostávají přístup k e mailu, interním dokumentům, GitHubu, databázím, cloudovým službám a dalším systémům, kde se odehrává skutečná práce. To přináší velkou produktivitu, ale taky nové typy rizik. Agent může udělat chybu, narazit na škodlivý obsah, použít příliš široké oprávnění nebo si najít nečekanou cestu, jak dokončit úkol.
Právě proto považuji bezpečnost AI agentů za zásadní téma pro každou firmu, která chce AI nasazovat ve větším měřítku. Nejde jen o to, zda je jazykový model kvalitní. Důležité je, kde agent běží, k čemu má přístup, jak pracuje s přihlašovacími údaji, kdo kontroluje jeho akce a jak rychle bezpečnostní tým pozná, že se něco děje.
Bezpečnostní přístup Perplexity stojí na myšlence, že AI má být bezpečná už ve výchozím nastavení. Místo modelu „připojte agenta k počítači a pak se snažte omezit škody“ sází na izolaci, minimální oprávnění, správu přes administrátory, detailní auditovatelnost a lidské schvalování citlivých akcí.
Obsah
- 🔐 Proč běžné nasazení AI agentů vytváří problém
- 🖥️ Agent má mít vlastní počítač, ne přístup k vašemu
- 🏖️ Proč nestačí obyčejný sandbox
- 🔑 Přihlašovací údaje nemají skončit v kontextu agenta
- 👥 RBAC, identity provider a kontrola na úrovni skupin
- 📊 Bezpečné sdílení bez zbytečného šíření dat
- 🧪 BrowseSafe a obrana proti prompt injection
- 🦡 Numbat: EDR principy pro AI agenty
- 🐝 Bumblebee a problém bezpečnosti softwarového dodavatelského řetězce
- ⚡ Proč se cíl bezpečnostních týmů mění
- 🧭 Jak začít s AI v bezpečnostním týmu bez chaosu
- 🧠 Data retention, paměť a projektový kontext
- 🛡️ Šifrování, compliance a Bring Your Own Key
- 🌐 Otevřené modely a schopnost bránit se
- 🚨 Co bude znamenat obrana rychlostí stroje
- ✅ Hlavní princip: AI musí být užitečná, ale omezená
🔐 Proč běžné nasazení AI agentů vytváří problém
Nejjednodušší způsob, jak AI agenta začít používat, bývá zároveň nejrizikovější. Firma nainstaluje aplikaci na pracovní počítače a poskytne jí přístup k souborům, lokálním aplikacím, prohlížeči, tokenům, API klíčům nebo SSH konfiguraci. Agent pak teoreticky dokáže pracovat s téměř vším, co je dostupné uživateli.
Takový přístup působí pohodlně, protože odpadá počáteční konfigurace. Jenže z pohledu bezpečnosti jde o široké a těžko kontrolovatelné oprávnění. Pokud agent obdrží nebezpečný pokyn, podlehne prompt injection útoku nebo prostě nepochopí kontext úkolu, může se dostat k datům a systémům, které k dané práci vůbec nepotřeboval.
Vidím zde stejný princip, který dlouhodobě platí v tradiční bezpečnosti: čím větší přístup systém dostane, tím větší je dopad případného selhání. U AI se navíc přidává autonomie. Agent nemá pouze zobrazovat data. Často má aktivně vyhledávat informace, procházet web, vytvářet soubory, navrhovat změny v kódu, připravovat e maily nebo komunikovat s firemními nástroji.
Proto nestačí zabezpečit jen samotný model. Organizace potřebuje bezpečně řešit celý řetězec:
- prostředí, ve kterém agent vykonává práci,
- přístup agentů k síti a externím službám,
- uložení a použití přihlašovacích údajů,
- napojení na identitu zaměstnance a firemní skupiny,
- prevenci prompt injection útoků,
- monitoring, logování a blokování rizikových akcí,
- správu datové retence, paměti a šifrování.
🖥️ Agent má mít vlastní počítač, ne přístup k vašemu
Klíčovou součástí architektury Perplexity je produkt označovaný jako Computer. Jde o agentní prostředí, které dostává vlastní sandbox, tedy izolovaný virtuální prostor pro vykonávání úkolů. Název „Computer“ dává smysl právě proto, že agent pracuje na vlastním počítači v cloudu, nikoli přímo na zařízení zaměstnance.
Rozdíl je podstatný. Místo aby měl agent automaticky k dispozici lokální disk, osobní přihlašovací údaje, interní soubory a aplikace uživatele, začíná bez přístupu k čemukoli. Přístup se přidává teprve ve chvíli, kdy jej administrátor nebo uživatel výslovně povolí.
Jde o přístup opt in, nikoli opt out. Agent tedy nemá napřed všechna oprávnění s tím, že se některá později odeberou. Naopak dostává pouze to, co konkrétně potřebuje.
Pro podnikové prostředí je to praktičtější, než se může na první pohled zdát. Administrátor může rozhodnout například o tom:
- které konektory jsou pro jednotlivé týmy dostupné,
- zda agent smí jen číst e maily, nebo také připravovat koncepty,
- zda odeslání e mailu vyžaduje lidské schválení,
- zda může agent přistupovat ke konkrétnímu úložišti či repozitáři,
- které skupiny zaměstnanců mohou používat konkrétní funkce,
- jak dlouho se mají data a pracovní kontext uchovávat.
Bezpečnost se tak nestává překážkou produktivity. Stává se součástí návrhu pracovního procesu. Pokud má například marketingový tým analyzovat podklady v cloudovém úložišti, nepotřebuje přístup k produkční infrastruktuře. Pokud má vývojový tým vyhledávat chyby v kódu, nemusí mít agent automaticky právo zveřejnit repozitář nebo poslat data mimo organizaci.
🏖️ Proč nestačí obyčejný sandbox
Sandboxing není novinka. Izolovaná prostředí se dlouho používají pro spouštění kódu, testování aplikací nebo krátkodobé výpočetní úlohy. Klasický sandbox je ale často navržený pro krátké, předvídatelné a relativně jednoduché procesy.
AI agenti se chovají jinak. Mohou běžet déle, používat prohlížeč, stahovat a vytvářet soubory, pracovat s externími nástroji, reagovat na data a postupně upravovat vlastní plán. Z bezpečnostního hlediska je navíc třeba počítat s tím, že jsou do jisté míry nedůvěryhodní. Ne nutně proto, že by byli škodliví, ale proto, že mohou být ovlivněni externím obsahem nebo chybně vyhodnotit cíl.
Perplexity pro tento typ infrastruktury používá označení Space. Nejde pouze o izolovaný virtuální stroj. Koncept zahrnuje i síťovou bránu, zprostředkování přihlašovacích údajů, runtime observabilitu a možnosti vynucování pravidel pro síťovou komunikaci.
Tento celek je důležitý. Pokud firma vezme běžný sandbox a postupně na něj přidává další bezpečnostní nástroje, může vzniknout roztříštěné prostředí. Jeden systém spravuje přístup, druhý logy, třetí síťové požadavky a čtvrtý tajemství. Každý funguje samostatně a jejich vzájemné vazby mohou být slabým místem.
Integrovaný systém naproti tomu umožňuje prosazovat pravidla konzistentně. Agent například odešle síťový požadavek, ale brána ověří cílovou službu, charakter požadavku i další bezpečnostní podmínky dříve, než se požadavek dokončí.
Human in the loop pro síťové akce
Zajímavou možností je lidské schválení přímo na úrovni síťového provozu. Pokud se agent pokusí spojit s určitou webovou stránkou nebo externím systémem, lze takovou aktivitu pozastavit a čekat na potvrzení.
To je užitečné hlavně v případech, kdy má agent číst data z interních služeb, ale odesílání dat ven nebo komunikace s neznámými doménami představuje vyšší riziko. V běžné aplikaci nainstalované na notebooku by podobná kontrola byla mnohem hůře vymahatelná. Lokální prostředí nabízí mnoho obcházek, síťových cest a aplikací, přes které lze stejnou akci provést jinak.
V centralizovaném sandboxu je možné definovat bezpečné cesty a vynucovat je bez ohledu na to, jaký postup agent zvažuje.
🔑 Přihlašovací údaje nemají skončit v kontextu agenta
U agentů bývají přihlašovací údaje jedním z největších zdrojů obav. Pokud agent potřebuje pracovat s GitHubem, e mailem nebo jinou službou, jak se ověří? A co se stane, pokud se token objeví v souboru, logu, promptu nebo v textu, který agent zpracovává?
Perplexity na to jde přes credential broker, tedy prostředníka pro přihlašovací údaje. Samotné údaje se uchovávají mimo sandbox agenta, v blízkosti síťové brány. Agent při komunikaci s externím systémem nemusí token přímo znát.
Představme si agenta, který potřebuje provést požadavek na GitHub. Může vytvořit neověřený požadavek směrem ke službě. Síťová brána pak zkontroluje, zda jde o očekávaný cíl, zda požadavek odpovídá povolené aktivitě a zda splňuje bezpečnostní pravidla. Teprve poté vloží potřebné přihlašovací údaje do odchozí komunikace.
Agent tedy nemá přímo k dispozici tajný klíč, který by mohl omylem odhalit, zapsat do souboru nebo použít mimo schválený scénář. Přístup je navíc deterministický a svázaný s konkrétně definovaným účelem.
Tento princip navazuje na známé pravidlo nejmenších oprávnění. Více souvislostí k němu nabízí například slovník NIST k principu least privilege.
OAuth místo pevně uložených API klíčů
Další důležitou volbou je využívání OAuth tam, kde to daná služba umožňuje. OAuth je běžný mechanismus, při kterém uživatel autorizuje propojení s externí aplikací a může vidět, jaká oprávnění uděluje. Technické pozadí standardu popisuje OAuth 2.0.
Výhody tohoto přístupu jsou docela přímočaré:
- firma nemusí spravovat množství statických API klíčů,
- přístup lze svázat s konkrétním uživatelem,
- existující oprávnění v cílové službě zůstávají relevantní,
- organizace využije své skupiny, ACL a identity management,
- auditní záznamy v napojené službě dál dávají smysl.
Pokud má zaměstnanec přístup jen k určitému adresáři nebo repozitáři, agent pracující jeho jménem by měl zdědit právě tento omezený rozsah. AI se tak nestává univerzálním administrátorem, který najednou vidí víc než člověk, pro kterého zrovna pracuje.
👥 RBAC, identity provider a kontrola na úrovni skupin
Ve velké firmě nestačí nastavit přístup jednotlivcům ručně. Potřeba je role based access control, známé jako RBAC, a napojení na stávající systém správy identit. Perplexity zmiňuje integrace s poskytovateli identity, jako jsou Okta a Microsoft Entra ID.
Praktický dopad je jednoduchý. Organizace může navázat dostupnost funkcí a konektorů na skupiny, které již používá. Bezpečnostní tým například může mít jiné možnosti než obchodní tým a vývojáři zase jiné než externí spolupracovníci.
Na úrovni skupin lze řídit:
- zapnutí či vypnutí jednotlivých funkcí,
- dostupnost konkrétních konektorů,
- možnost pracovat s určitou kategorií dat,
- povinné lidské schvalování pro konkrétní akce,
- sdílení výstupů mezi členy týmu,
- uchování paměti a projektového kontextu.
Za dobrý příklad považuji práci s e mailem. Běžný uživatel může ve své schránce číst, vytvářet koncepty i odesílat zprávy. Firma však nemusí chtít, aby všechny stejné činnosti prováděl autonomní agent. Může tedy povolit čtení a přípravu návrhu, ale samotné odeslání podmínit potvrzením člověka.
Takové nastavení pomáhá zachovat produktivitu bez toho, aby se z automatizace stal nekontrolovaný komunikační kanál. Zároveň omezuje riziko, že agent odešle nesprávný, neúplný nebo citlivý obsah.
📊 Bezpečné sdílení bez zbytečného šíření dat
Jedna z často přehlížených bezpečnostních otázek zní: co se stane s výsledkem práce agenta? Pokud agent na lokálním počítači vytvoří dashboard, malou interní stránku nebo analýzu citlivých dat, bývá další krok komplikovaný. Zaměstnanec může výstup poslat e mailem, vložit do Slacku nebo jej nahrát do další cloudové služby.
Právě tady vzniká datový sprawl, tedy nekontrolované rozšiřování kopií citlivých informací napříč systémy. Někdy se kvůli jednoduchému internímu výstupu začne používat externí hosting, což znamená řešit domény, load balancery, přístupová pravidla a další provozní vrstvu.
Pokud každý úkol Perplexity běží ve vlastním cloudovém prostředí, lze vytvořený dashboard nebo web sdílet přímo v řízeném prostředí pomocí odkazu. Sdílení může zůstat omezené na konkrétní tým či skupinu a podléhá stejným administrativním pravidlům a auditním mechanismům.
Neznamená to, že sdílení dat přestává být rizikem. Znamená to ale, že firma nemusí kvůli každému výstupu AI agenta vytvářet improvizovaný kanál mimo svůj bezpečnostní model.
🧪 BrowseSafe a obrana proti prompt injection
Prompt injection patří mezi nejdiskutovanější rizika agentní AI. Útočník může vložit škodlivý pokyn do webové stránky, e mailu, dokumentu nebo jiného obsahu, který agent následně zpracuje. Cílem může být přesvědčit agenta, aby ignoroval původní úkol, vyzradil data, provedl nechtěnou akci nebo kontaktoval cizí službu.
U běžného chatbotu může prompt injection znamenat hlavně špatnou odpověď. U agenta s přístupem k nástrojům jde o mnohem vážnější problém. Agent může číst e maily, procházet web, přistupovat ke konektorům a vykonávat činnosti v digitálním prostředí.
Perplexity pro tento problém vytvořila BrowseSafe, open source klasifikátor určený k detekci prompt injection v obsahu webových stránek a externích nástrojů, včetně e mailu. Cílem bylo vytvořit model, který je dostatečně rychlý pro reálné nasazení a zároveň efektivní při zachycování skutečných útoků.
Rychlost hraje velkou roli. Pokud ochranná vrstva výrazně zpomalí každé načtení stránky či každý krok agenta, začne být produkt nepoužitelný. BrowseSafe má proto kombinovat silný výkon s nízkou latencí a nižšími náklady.
Důležitý je i přístup k otevřenému zdrojovému kódu. Perplexity publikovala model i datovou sadu, aby z práce mohla těžit širší komunita. V bezpečnosti je taková spolupráce užitečná hlavně u nových tříd hrozeb, kde obránci potřebují rychle sdílet poznatky, testovací data a postupy.
Samotný klasifikátor ale není všespásný. Bezpečnost proti prompt injection by podle mě měla být vícevrstvá:
- detekce škodlivého obsahu před jeho zpracováním,
- izolace prostředí, kde agent běží,
- omezené a explicitně povolené nástroje,
- kontrola síťové komunikace,
- schvalování citlivých kroků člověkem,
- monitoring agentních akcí a rychlá reakce na anomálie.
🦡 Numbat: EDR principy pro AI agenty
Endpoint detection and response, zkráceně EDR, je dnes běžnou součástí ochrany firemních zařízení. Systémy tohoto typu sbírají telemetrii, hledají podezřelé chování a umožňují bezpečnostním týmům reagovat na incidenty. Numbat přenáší podobnou logiku do světa agentů.
Jde o open source nástroj, který se zapojuje do agentních harnessů, tedy prostředí, ve kterých agenti vykonávají práci. Má dvě hlavní funkce. Zaprvé shromažďuje telemetrii o aktivitě agentů a normalizuje ji tak, aby ji organizace mohla posílat do svého SIEM systému nebo jiného cílového nástroje.
Zadruhé umožňuje definovat deterministická pravidla. Ta mohou při podezřelé aktivitě pouze vyvolat alert, nebo mohou samotnou akci rovnou zablokovat.
To je zásadní rozdíl. Bezpečnostní tým nemusí jen zpětně zjišťovat, co agent provedl. Může zasáhnout mezi okamžikem, kdy agent zamýšlí zavolat nástroj, a okamžikem, kdy se nástroj skutečně spustí.
Představím si situaci, kdy agent dostane úkol vyhledat chyby v kódu a připravit pull requesty s opravami. Pokud narazí na problém s oprávněním nebo konektorem, může se pokusit dokončit úkol jinou cestou. V nejhorším případě by mohl zkusit vytvořit veřejný repozitář nebo veřejný pull request, aby informace někam umístil.
Numbat má sloužit jako vrstva, která podobné odchylky posoudí podle bezpečnostní politiky. Pokud dané chování porušuje pravidla, agent akci neprovede.
Od monitoringu k neustálému zlepšování
Velmi zajímavý je způsob, jak lze Numbat použít v kombinaci s dalšími agenty. Logy a alerty se posílají do SIEMu, kde je mohou průběžně analyzovat automatizované procesy. Ty vyhledávají podezřelé chování, eskalují skutečné problémy bezpečnostnímu týmu a zároveň navrhují nové detekce nebo úpravy stávajících pravidel.
Návrhy se mohou dostat do pull requestů, které člověk zkontroluje a schválí. Výsledkem je průběžný cyklus:
- agenti a systémy vytvářejí telemetrii,
- automatizace hledá odchylky a opakující se vzorce,
- bezpečnostní tým posoudí relevantní návrhy,
- detekční pravidla se zlepší,
- celé prostředí získá lepší ochranu.
To je praktická interpretace často používané fráze „bránit se rychlostí stroje“. Neznamená to odstranit lidi z bezpečnosti. Znamená to přenechat strojům objemnou opakovanou práci a nechat lidi rozhodovat o zásadních prioritách, výjimkách a změnách politiky.
🐝 Bumblebee a problém bezpečnosti softwarového dodavatelského řetězce
Bezpečnost AI agentů není oddělená od zbytku infrastruktury. Velké riziko představuje i software supply chain, tedy dodavatelský řetězec knihoven, balíčků, nástrojů a závislostí používaných ve firmě.
Útok nemusí začít změnou v pull requestu. Zaměstnanec může na notebooku nainstalovat škodlivý balíček při testování nástroje. Ohrožená může být závislost závislosti. Kompromitovaný balíček může skončit na serveru, ve vývojovém prostředí nebo v CI/CD procesu ještě předtím, než se objeví v hlavním repozitáři.
Perplexity vytvořila Bumblebee jako lehký skener pro notebooky, servery i CI/CD prostředí. Nástroj má vytvářet průběžný inventář nainstalovaných balíčků a posílat jej do SIEMu. Zároveň provádí hlubší kontrolu známých škodlivých balíčků.
Bezpečnostní tým tak nemusí při každé nové zprávě o kompromitované knihovně začínat ručním pátráním. Může se rychle zeptat, zda se daný balíček objevil někde ve firemním prostředí.
Zejména tady je vidět síla kombinace agentů a bezpečnostních nástrojů. Agent může průběžně kontrolovat zdroje threat intelligence, veřejné informace o nových incidentech a následně porovnat zjištěné názvy balíčků s inventářem z Bumblebee. Pokud najde shodu, může okamžitě upozornit bezpečnostní tým.
Historie ukazuje, proč záleží na rychlosti. Zranitelnost Log4Shell například ukázala, jak rozsáhlé dopady může mít chyba v široce používané komponentě. Další materiály k této události udržuje Apache Log4j Security.
⚡ Proč se cíl bezpečnostních týmů mění
Tradiční bezpečnostní operace se často snaží co nejvíc snížit počet falešně pozitivních alertů. Dává to smysl. Když každý alert vyžaduje hodiny ručního vyšetřování, tým si nemůže dovolit stovky hlučných upozornění denně.
Jenže takový přístup má nepříjemný vedlejší efekt. Některé kvalitní detekce jsou z principu hlučné. Mohou zachytit škodlivou aktivitu, ale zároveň vytvářet hodně neškodných alertů. Pokud tým nemá kapacitu je prověřovat, často je prostě vypne. A právě mezi stovkami neškodných událostí se pak může schovat skutečný incident.
Automatizované vyšetřování může tuto rovnici změnit. Pokud organizace zvládne ke stovce alertů spustit stovku izolovaných agentů, kteří provedou počáteční triage, dohledají souvislosti a vytáhnou relevantní důkazy, náklady na vyšetření dramaticky klesají.
To neznamená, že je dobré zahlcovat tým nesmyslnými notifikacemi. Znamená to, že cílem nemusí být absolutní minimum falešných pozitiv. Cílem má být zachytit skutečně škodlivé chování, aniž by bezpečnostní lidé trávili veškerý čas manuální rutinou.
Za přínos považuji hlavně to, že se tým může soustředit na práci s vyšší hodnotou. Místo neustálého „udržování světel rozsvícených“ může budovat nové detekce, zlepšovat architekturu, řešit rizika dodavatelského řetězce a připravovat organizaci na další generaci hrozeb.
🧭 Jak začít s AI v bezpečnostním týmu bez chaosu
Nasadit AI agenta do celé firmy naráz je podle mě zbytečně riskantní. Lepší je postupovat metodou crawl, walk, run, tedy začít malým ověřeným případem, postupně rozšířit používání a teprve pak škálovat.
Dobré první use cases mají několik společných znaků. Jsou opakované, časově náročné, mají jasně vymezená data a jejich výstup lze rozumně zkontrolovat. Typickým příkladem je triage bezpečnostních alertů.
Praktický postup může vypadat takto:
- Vyberte jeden úzký problém. Například první analýzu alertů v SIEMu nebo porovnávání informací o hrozbách s inventářem balíčků.
- Začněte s minimem konektorů. Agentovi zpřístupněte jen jeden až tři nástroje, které pro daný úkol opravdu potřebuje.
- Omezte data. První scénář by měl pracovat s co nejméně citlivými informacemi.
- Pozorujte chování agenta. Zjistěte, které nástroje používá, kde naráží na problémy a jaké typy akcí navrhuje.
- Přidejte schvalování. Kritické akce, jako odesílání komunikace, změna konfigurace nebo sdílení dat, nechte potvrzovat člověkem.
- Logujte a vyhodnocujte. Připojte auditní záznamy do existujícího SIEMu a vytvářejte pravidla podle skutečného používání.
- Rozšiřujte pouze ověřené scénáře. Teprve když je první workflow stabilní a srozumitelné, dává smysl přidat další oprávnění a více týmů.
Tento postup je použitelný nejen pro security operations. Stejně lze začít ve vývoji, zákaznické péči, marketingu nebo obchodních týmech. Rozhodující je, aby se AI nestala neřízenou vrstvou s přístupem ke všemu jen proto, že to technicky jde.
🧠 Data retention, paměť a projektový kontext
Firemní zákazníci přirozeně řeší, co se děje s daty, která do AI systému vloží. Mohou nahrávat soubory, připojovat cloudové služby, pracovat s e maily nebo vytvářet dlouhodobé projekty. Vedle zabezpečení přístupu tak přichází otázka retence: jak dlouho data zůstávají uložená a co všechno si systém pamatuje?
Perplexity uvádí, že u externích poskytovatelů velkých jazykových modelů má nastavený režim zero data retention. Tito poskytovatelé data zpracovávají pro daný požadavek, ale nemají je ukládat ani analyzovat.
V samotném podnikové prostředí Perplexity mohou administrátoři nastavovat politiku uchovávání dat a zapínat či vypínat paměť. Retence může být nastavena i na 24 hodin. To dává organizacím možnost přizpůsobit systém vlastním regulatorním, právním a interním požadavkům.
Je ale fér říct, že kratší retence má cenu. Pokud se data rychle smažou, uživatelé neuvidí starší konverzace a některé dlouhodobé automatizace budou omezené. Agent, který pravidelně vyhledává nové hrozby nebo pracuje nad projektem, potřebuje určitý stav a kontext, aby mohl navazovat na předchozí práci.
Funkce Brain je zaměřená právě na dlouhodobější projektový kontext. Agent se může průběžně učit z dostupných zdrojů, například z projektových konverzací, Slacku nebo GitHubu, a využívat poznatky při dalších úkolech. Důležité je, že organizace má možnost tento mechanismus vypnout nebo upravovat podle své tolerance rizika.
Užitečná je také transparentnost. V projektovém prostoru lze zjistit, které informace systém uchovává pro budoucí práci, a tyto záznamy upravit nebo smazat. Paměť tak nemusí být neprůhledná černá skříňka.
🛡️ Šifrování, compliance a Bring Your Own Key
Vedle řízení přístupů a retence musí podniková AI řešit i ochranu dat při přenosu a uložení. Perplexity uvádí šifrování dat v klidovém stavu, vynucování TLS při přenosu a podporu standardů a rámců jako SOC 2, GDPR, ISO a FedRAMP Low, s plánem směřovat k FedRAMP Moderate.
Pro organizace s vyššími požadavky na kontrolu klíčů je důležitý koncept Bring Your Own Key, zkráceně BYOK. Při tomto modelu zákazník spravuje vlastní šifrovací klíč a poskytovatel jím šifruje jeho data. Firma tak získává větší jistotu, že data zůstávají chráněná klíčem pod její vlastní správou.
BYOK není řešení všech bezpečnostních problémů. Neochrání například před příliš širokým oprávněním agenta nebo nebezpečným workflow. Je to ale silná součást celkové strategie, zejména v regulovaných odvětvích, kde je kontrola nad kryptografickými klíči zásadní.
🌐 Otevřené modely a schopnost bránit se
Debata o open weight modelech bývá často vyhrocená. Na jedné straně mohou otevřenější modely rozšířit schopnosti útočníků. Lidé s technickými znalostmi a přístupem k infrastruktuře mohou získat výkonné nástroje pro průzkum cílů, hledání zranitelností nebo automatizaci útoků.
Na druhé straně mohou stejné schopnosti posílit obránce. Bezpečnostní tým nemusí být závislý na jediném uzavřeném poskytovateli modelu. Může využívat různé modely pro různé úkoly, vytvářet vlastní automatizaci a v případě potřeby přesměrovat práci na jiný model.
Perplexity zdůrazňuje modelovou agnosticitu. Pokud jeden model odmítne určitý požadavek nebo není pro daný problém vhodný, agentní systém může úlohu směrovat k jinému dostupnému modelu, případně kombinovat více modelů.
Z bezpečnostního pohledu je to forma odolnosti. Organizace se nespoléhá na jedinou vrstvu, jediný model ani jedinou cestu. Stejně jako u infrastruktury a identity platí, že přílišná centralizovaná závislost může být rizikem.
🚨 Co bude znamenat obrana rychlostí stroje
V příštích měsících a letech budou agenti pravděpodobně samostatnější, schopnější a dostupnější. To platí pro obránce i útočníky. Doba mezi zveřejněním zranitelnosti a jejím aktivním zneužitím se může dál zkracovat.
V minulosti mohly týmy mít dny na zjištění dopadu zranitelnosti, identifikaci postižených systémů a nasazení opravy. V prostředí, kde mohou útočníci automatizovaně skenovat internet, vytvářet exploity a provádět průzkum ve velkém, mohou být hodiny nebo dny příliš dlouhá doba.
Dobře fungující bezpečnostní tým za rok nebude jen tým, který nasazuje AI nástroje. Bude to tým, který dokáže využít automatizaci ke třem věcem:
- rychle detekovat podezřelé chování napříč prostředím,
- rychle vyšetřit velké množství událostí bez zahlcení lidí,
- rychle reagovat izolací hrozby, blokováním akcí a opravou zranitelností.
Ideální stav je takový, kdy agenti dokážou rozpoznat problém, vyhodnotit jeho kontext a během sekund či minut provést předem schválené ochranné kroky. Člověk pak vstupuje do hry tam, kde je potřeba posoudit dopad, schválit významnou změnu nebo řídit širší incident response.
Nejde o nahrazení bezpečnostních specialistů. Naopak. Jde o to, aby schopní lidé nemuseli trávit celý den opakováním rutinních dotazů v logovacích nástrojích. Čím více provozní práce převezme bezpečně navržená automatizace, tím více prostoru vznikne pro strategické rozhodování, threat modeling a budování odolnějšího systému.
✅ Hlavní princip: AI musí být užitečná, ale omezená
Nejdůležitější myšlenka je podle mě překvapivě jednoduchá. AI agent nemusí mít přístup ke všemu, aby byl užitečný. Ve skutečnosti bude bezpečnější a často i snáze spravovatelný, když dostane přesně vymezený úkol, izolované prostředí, omezený počet konektorů a jasná pravidla pro citlivé akce.
Bezpečný model nasazení AI agentů stojí na těchto pilířích:
- agent běží mimo osobní počítač uživatele,
- přístup je ve výchozím stavu vypnutý,
- oprávnění se přidávají cíleně a postupně,
- přihlašovací údaje nejsou přímo dostupné agentovi,
- síťová komunikace je kontrolovaná,
- rizikové akce mohou vyžadovat schválení člověka,
- administrátoři řídí funkce přes identity a role,
- agentní aktivita je auditovatelná a monitorovaná,
- organizace může upravovat retenci, paměť i šifrovací model,
- automatizace pomáhá bezpečnostnímu týmu reagovat rychleji.
AI v podniku bude čím dál více vykonávat skutečnou práci. Právě proto nestačí řešit jen to, co agent umí. Stejně důležité je vědět, co umět nesmí, kde jsou jeho hranice a kdo je dokáže vynutit. Bezpečnost by neměla být dodatečný doplněk přilepený ke schopnému agentovi. Musí být součástí jeho architektury od prvního dne.
