Jak navrhujeme bezpečnější agenty

Abychom mohli vytvořit bezpečnější agenty AI, musíme navrhnout systémy s ohledem jak na jejich schopnosti, tak na jejich selhání. Dokonce i při provádění legitimních úkolů a bez jakýchkoliv škodlivých pokynů mohou agenti překročit bezpečnostní hranice, když se snaží překonat překážky.

Věříme, že se jedná o problém bezpečnostního inženýrství, a odvětví by k němu mělo přistoupit tak, jak přistoupilo k internetovým červům na začátku roku 2000. Systémy obklopující agenty musí omezit to, co agenti mohou přístupem získat, detekovat nežádoucí chování a izolovat selhání, když k nim dojde.

Ve společnosti Perplexity aktivně spolupracujeme s výzkumníky a praktiky na pokroku v oblasti bezpečnostního inženýrství pro agenty AI a uplatňujeme více vrstev obrany napříč našimi modely, harnessy agentů a infrastrukturou, aby bezpečnost nezávisela na jediném ochranném opatření.

Chování agentů AI při selhání

V červenci agenti AI pronikli do produkční infrastruktury open-source platformy AI Hugging Face. Během interního vyhodnocování kybernetické bezpečnosti a tréninkových běhů objevily modely OpenAI způsob, jak zneužít správce repozitáře Artifactory k vytvoření nástěnky pro vzájemnou komunikaci, což jim umožnilo organizovat se do rojů. Později agenti, kteří nemohli pokročit v úkolech v benchmarku kybernetické bezpečnosti, naverbovali na pomoc jiné agenty. Tito agenti unikli ze svého testovacího prostředí a dostali se na internet. Objevili také způsoby, jak podvádět pomocí zpětného inženýrství odpovědí na úkoly benchmarku, ale domnívali se, že systém hodnocení podvádění odhalí. Aby lépe pochopili, jak funguje vyhodnocování v benchmarku a jak se vyhnout detekci podvádění, nakonec kompromitovali systémy Hugging Face (Hugging Face; OpenAI).

Tento incident je jasným příkladem režimu selhání, který jsme popsal, když jsme v červenci uvolnili Numbat jako open-source: náhodná selhání (accidental meltdowns), což je termín, který zavedli bezpečnostní výzkumníci z Cornell Tech (arXiv). Agent usilující o legitimní cíl narazí na překážku, jako je chybějící soubor, neúspěšné volání API, vypršené přihlašovací údaje nebo odepření oprávnění, a začne hledat náhradní řešení. Přitom může překročit bezpečnostní hranice prostřednictvím průzkumu, eskalace oprávnění, objevování tajných údajů nebo exfiltrace dat. Samotný agent se účinně stává útočníkem, přičemž se neúčastní žádná škodlivá výzva ani externí útočník.

Hugging Face nebyl ojedinělým případem. V posledních týdnech byly objeveny a nahlášeny další případy chování agentů, u nichž došlo k selhání. Dne 27.–28. května se agenti snažící se shromáždit data University of Iowa z platformy Data USA, která nabízí otevřený přístup k datům vládních úřadů USA, setkali s chybami způsobenými chybně zformovaným dotazem. Reagovali sondami včetně SQL injekce, skriptování napříč weby (XSS), injekce šablon, průchodu adresářem (path traversal) a injekce příkazů. Tato aktivita byla později spojena se společností OpenAI (SecurityWeek). Ve dnech 20.–21. června byli agenti OpenAI, kteří se pokoušeli získat vládní náklady na osobu pro kategorii léků v jednotlivých oblastech ve Victorii od Australského institutu pro zdraví a sociální péči (AIHW), zablokováni při stahování souboru. V reakci na to agenti stáhli soubor, který byl již veřejně dostupný, z předprodukčního serveru AIHW, čímž obešli protibotové ochrany tohoto webu (SecurityWeek).

Tento vzorec se netýká jen jedné laboratoře. Během kybernetických testů modely společnosti Anthropic prolomily obranu tří společností poté, co jim chyba poskytla neomezený přístup k internetu, Google Gemini uhádl přihlašovací údaje k třem webovým stránkám a model společnosti Meta zneužil službu třetí strany (Reuters).

Poučení z historie: Éra internetových červů

Tyto incidenty připomínají éru internetových červů zhruba před čtvrt stoletím. Na začátku roku 2000 rostl internet mnohem rychleji než bezpečnostní postupy kolem něj. Viděli jsme vlnu virů a červů s důsledky mnohem vážnějšími, než jaké nyní vidíme u agentů AI v selhání.

Dne 4. května 2000 začali lidé dostávat e-maily od známých odesílatelů s předmětem „ILOVEYOU“. Otevřením přílohy v e-mailu došlo ke spuštění skriptu, který odeslal kopii sebe sama všem v adresáři Outlook oběti. Do 18 hodin téhož dne obdrželo koordinované centrum CERT hlášení týkající se více než 420 000 internetových hostitelů (Zpráva US GAO). Virus údajně pronikl do nejméně 14 federálních agentur včetně ministerstva obrany, CIA, NASA a Sněmovny reprezentantů a Senátu (Zpráva US GAO). Rovněž vyřadil z provozu e-mailové servery v Pentagonu a britském parlamentu (Wired). Pojišťovací gigant Lloyd's of London odhadl, že virus způsobí škody a ztrátu produktivity ve výši přes 15 miliard dolarů (Slyšení výboru Sněmovny reprezentantů USA). Computer Economics později odhadl celosvětové škody na 8,75 miliardy dolarů (Information Week).

Jako další přišli červi, kteří nepotřebovali kliknutí člověka. Dne 19. července 2001 infikoval červ Code-Red více než 359 000 počítačů za méně než 14 hodin (CAIDA). Dne 25. ledna 2003 zdvojnásobil SQL Slammer svoji velikost každých 8,5 sekundy a během 10 minut infikoval více než 90 % internetových hostitelů náchylných k této zranitelnosti (CAIDA), přičemž využil díru, na kterou Microsoft vydal záplatu o šest měsíců dříve (CNET). V srpnu 2003 se objevily červ Blaster a e-mailový červ Sobig s odstupem přibližně jednoho týdne (Microsoft, F-Secure).

V té době bylo rozumné položit si otázku, zda vůbec lze zajistit bezpečnost síťově propojených počítačů. Šest dní po viru ILOVEYOU uspořádal podvýbor Sněmovny reprezentantů USA slyšení na toto téma. Mnoho bezpečnostních odborníků vyzvalo k přijetí legislativy, která by učinila softwarové společnosti odpovědnými za škody způsobené chybami v jejich produktech. Washington se vydal jinou cestou. Národní strategie pro zabezpečení kyberprostoru (National Strategy to Secure Cyberspace) uvedla, že „federální regulace se nestane primárním prostředkem zabezpečení kyberprostoru“. Varovala, že široké mandáty by mohly vytvořit „přístup nejnižšího společného jmenovatele ke kybernetické bezpečnosti“ (CISA).

Odvětví odpovědělo inženýrstvím. Jedenáct dní po viru ILOVEYOU oznámil Microsoft aktualizaci Outlooku, která blokovala spustitelné přílohy. V lednu 2002 učinila společnost z bezpečnosti svou hlavní prioritu (Seattle Times). Standardní praxí se stalo automatické záplatování, bezpečné výchozí hodnoty, programy odměn za chyby a koordinované zveřejňování. V roce 2008 začal Chrome spouštět webový obsah v sandboxu, který „omezuje to, co může útočník udělat po zneužití chyby“ (Chromium Blog). Šifrování, dříve výjimka, se stalo standardem. Široce se začaly používat bezpečnostní technologie včetně multifaktorového ověřování, firewallů, principu nulové důvěry (zero trust) a správy bezpečnostních informací a událostí (SIEM). Podle odhadů utratí organizace po celém světě v roce 2006 za informační bezpečnost přibližně 240 miliard dolarů (Gartner). Červi zcela nezmizeli, ale éra běžných celointernetových epidemií ustoupila. Internet, z větší části nezatížený regulací, se zároveň v následujících dvou desetiletích stal mocným motorem inovací a ekonomického růstu.

Bezpečnostní inženýrství pro agenty AI

Nedávné incidenty vyvolaly legitimní otázky ohledně správy agentů. Stávající bezpečnostní mechanismy byly vyvinuty pro výpočetní prostředí před příchodem agentů, která se vyznačovala úzce vymezeným a převážně deterministickým chováním softwaru. Mechanismy řízení přístupu jsou navrženy zejména s ohledem na lidské uživatele a často jim udělují široká oprávnění, která jsou v principu dostatečná k způsobení významných škod.

Tento návrh staví na několika předpokladech: většina uživatelů jedná v dobré víře; škodliví aktéři mohou být odrazeni auditem a reálnými důsledky; a lidé provádějí akce, ať už správné či chybné, v poměrně omezené míře. Uplatnění těchto bezpečnostních mechanismů u agentů vyžaduje zohlednění rozdílů mezi chováním člověka a agenta. Jak jsme psali v naší odpovědi na žádost NIST o informacích ohledně bezpečnosti agentů AI, agenti AI tyto předpoklady zpochybňují. Mohou uplatňovat oprávnění a provádět akce rychlostí stroje, sami o sobě nejsou odrazováni reálnými důsledky a mohou provádět akce, které jsou technicky povolené, ale které by typický lidský uživatel prováděl jen málokdy.

Zodpovězení těchto otázek vyžaduje bezpečnostní inženýrství. Známe bezpečnostní principy pro budování systémů, které udržují rizika pod kontrolou, když se jednotlivé komponenty chovají nesprávně. Musíme se však ujistit, že tyto principy jsou uplatňovány při navrhování prostředí pro trénování, testování a používání agentů AI.

Princip zabezpečení hloubkovou obranou

Pravděpodobně nejdůležitějším bezpečnostním principem, který je nutné uplatnit při zabezpečování agentů AI, je hloubková obrana, jež prosazuje vrstvenou bezpečnostní architekturu, v níž se k ochraně systémových zdrojů používá více různých a redundantních obranných opatření. Žádné jediné zabezpečení není dokonalé. Lidé mohou podlehnout útokům sociálního inženýrství a prozradit své přihlašovací údaje, jsou objevovány a zneužívány softwarové zranitelnosti typu zero-day a detekce narušení přehlíží nové varianty útoků. Hloubková obrana toto akceptuje a vrství několik nezávislých vrstev obrany. V případě obejití jedné obranné vrstvy zůstávají ostatní vrstvy na svém místě, aby narušení čelily nebo ho detekovaly.

Incident v Hunching Face ukazuje, proč má hloubková obrana (defense-in-depth) význam. Retrospektivní zpráva společnosti OpenAI uvádí, že v testovacím prostředí chyběla automatizovaná ochranná opatření používaná v jejích produkčních systémech, včetně harnessů, modelů pro automatickou revizi a bezpečnostních klasifikátorů. Pokud by na těchto testech běželo aktuálně nasazené monitorování sledu myšlenek (chain-of-thought), zachytilo by počáteční aktivitu a upozornilo bezpečnostní tým více než den před narušením (OpenAI). Vrstvy, které mohly problém zachytit, existovaly. Pouze nebyly všechny na svém místě ve stejnou dobu.

Zabezpečení agentů AI vyžaduje zlepšení jak bezpečnosti a zabezpečení modelů AI, tak systémů kolem nich. Práce na vrstvě modelů má smysl a vyplácí se. Rané LLM byly snadno manipulovány injekčními pokyny, zatímco dnešní modely jsou podstatně lepší v jejich rozpoznávání a odmítání. Vývojáři modelů také trénují modely pro bezpečnější chování a, jak popisuje retrospektiva společnosti OpenAI, sledují stopy uvažování, zda neobsahují známky problémového chování. Obrany na úrovni modelů jsou však jen součástí řešení. Systémy, v nichž jsou agenti trénováni, testováni a nasazováni, musí být rovněž navrženy s ohledem na bezpečnost a izolaci. Bezpečnost na úrovni modelů snižuje pravděpodobnost, že agent sejde z cesty; bezpečnost na úrovni systému omezuje škody, když k tomu dojde.

Zvětšit

Návrhová pravidla pro redundantní zabezpečení

Hloubková obrana vyžaduje redundantní zabezpečení. Pro agenty doporučujeme uplatňovat ji pomocí tří návrhových pravidel:

1. Nezávislost. Každá vrstva by měla selhat z nezávislých důvodů. Dvě kontrolní mechanismy, které sdílejí stejný předpoklad, mohou být poraženy stejným útokem. Monitory a body vynucování by se měly nacházet mimo dosah agenta.
2. Vynucování pod agentem. Nejméně jedna vrstva musí být deterministická: konvenční, ověřitelný kód, který blokuje zakázané akce bez ohledu na to, co model vyprodukuje. Ochranné opatření, které může agent odmítnout vyvolat nebo které může rekonfigurovat, není ochranným opatřením.
3. Signály mohou oprávnění pouze snižovat. Detekce by měla vyvolat reakce, které omezí to, co agent může udělat, jako je pozastavení, odvolání přihlašovacích údajů, odpojení sítě nebo ukončení relace. Žádný rizikový signál by nikdy neměl udělit dodatečný přístup.

Tyto principy sdílíme s našimi partnery v alianci Open Secure AI Alliance, včetně společnosti NVIDIA, která argumentovala tím, že harness určuje, o co se agent snaží, zatímco infrastruktura řídí, co může dělat (NVIDIA).

Hloubková obrana v produktech Perplexity

Perplexity spouští agenty ve čtyřech typech prostředí: v cloudu prostřednictvím naší platformy agentů Computer, v prohlížeči prostřednictvím Comet, na uživatelských zařízeních prostřednictvím Portable Computer a na laptopech zaměstnanců, kde naši inženýři používají kódovací agenty třetích stran. Každé prostředí má svá vlastní rizika a každé získává několik vrstev ochrany.

V cloudu: Computer a SPACE

Každý úkol v Computeru běží v SPACE, naší platformě sandboxu, která s agentem ve výchozím nastavení zachází jako s nedůvěryhodným. Každý úkol získá svůj vlastní mikrovirtuální stroj, přihlašovací údaje zůstávají mimo sandbox a jsou vloženy pouze v případě potřeby, odchozí provoz je řízen vně hosta a snímky (snapshots) nám umožňují vrátit destruktivní změny zpět (Making SPACE). Podnikoví zákazníci mohou také přinést vlastní šifrovací klíče. Odvolání klíče činí chráněná data nečitelnými a agent toto rozhodnutí nemůže přepsat.

Testujeme také, zda tyto vrstvy obstojí. V článku Escaping SPACE: Part I jsme poskytli devíti špičkovým modelům root přístup uvnitř sandboxu SPACE a požádali je, aby se pokusily uniknout. Žádný z nich z virtuálního stroje (VM) neunikl, ale některé našly způsob, jak obejmout síťové pravidlo, když byl povolen částečný přístup k síti. Tyto mezery jsme opravili, opravy potvrdili při opakovaném testu a podobné slabiny, které jsme našli u osmi z 10 dalších platformových sandboxů, jsme nahlásili jejich dodavatelům.

V prohlížeči: Comet a BrowseSafe

Comet používá od svého spuštění vrstvenou obranu proti injekci výzev: klasifikátory prověřují načtený obsah, strukturované výzvy jej označují jako nedůvěryhodný, citlivé akce, jako je odeslání e-mailu nebo zadání objednávky, vyžadují potvrzení uživatele a uživatelé jsou informováni, když je něco zablokováno (Obrana proti injekci výzev v Comet). BrowseSafe, open-source detekční model stojící za první vrstvou, překonává špičkové modely v našem benchmarku BrowseSafe-Bench, přesto stejný benchmark ukazuje, že žádný detektor není zcela neomylný, a proto detekce není nikdy jedinou vrstvou (Výzkum BrowseSafe). Computer přebírá tyto obrany, které byly auditovány společností Trail of Bits (Perplexity).

Na zařízení: Portable Computer

Portable Computer je lokálně orientovaný agent: model, harness, konverzace a trajektorie zůstávají ve výchozím nastavení na počítači uživatele. Deterministický orchestrátor, což je spíše kód harnessu než LLM, spouští smyčku a vynucuje pravidla. Model navrhuje akce a schválená volání nástrojů běží v sandboxu na úrovni operačního systému, který omezuje procesy, cesty k souborům a přístup k síti. Sandbox je neustále zapnutý a při selhání se přepne do bezpečného stavu: pokud není k dispozici, harness se místo spouštění příkazů s oprávněními uživatele sám deaktivuje. Akce přesahující hranice zařízení, jako je vyhledávání na webu, konektory a eskalace na silnější model cloudového poradce, se dějí pouze tehdy, když je uživatel povolí a schválí. Před voláním poradce klasifikátor PII označí citlivé informace a uživatel vidí, co by bylo odesláno. Poradce obdrží pouze tento schválený kontext a vrátí textové pokyny, přičemž nemá přístup k souborům ani nástrojům zařízení.

Na koncovém bodu: Numbat

Kódovací agenti na vývojářských laptopech běží hodiny s přístupem ke zdrojovému kódu, přihlašovacím údajům a produkčním systémům. Numbat, naše open-source bezpečnostní sada pro agenty, přidává nezávislou vrstvu, která se nachází vně jakéhokoli jednotlivého agenta. Spolupracuje s harnessy, jako jsou Claude Code, Codex, OpenCode a Pi, blokuje nebezpečné akcie před jejich spuštěním, označuje podezřelé vícekrokové sekvence, jako je čtení tajného údaje a následné odeslání dat ven, a uchovává časové osy relací pro vyšetřování. Numbat běží napříč tisíci koncových bodů Perplexity spolu s Bumblebee, naším open-source skenerem dodavatelského řetězce. Computer pravidelně kontroluje jejich zjištění a navrhuje vylepšená detekční pravidla a člověk schvaluje každou změnu před jejím nasazením.

Úkol pro celé odvětví

Jak se agenti AI stávají schopnějšími a šířeji používanými, bezpečnostní inženýrství musí zůstat ústředním bodem jejich vývoje a nasazení. Výzkumníci a inženýři mohou stavět na zavedených principech, využívat reálná zjištění k vylepšení obrany a testovat ochranná opatření napříč prostředími, ve kterých agenti fungují. Bezpečnost je nepřetržitá inženýrská disciplína, která se vyvíjí spolu s technologií.

Bezpečnostní inženýrství pro agenty je úkolem pro celé odvětví. Žádná jednotlivá společnost neřídí celý zásobník, na kterém agent běží. Vývojáři modelů, tvůrci harnessů, poskytovatelé sandboxů a běhového prostředí, dodavatelé cloudu a hardwaru a podnikové bezpečnostní týmy – ti všichni vlastní jednu vrstvu. Bezpečnost celku závisí na tom, zda každá vrstva obstojí, když jiná selže. Proto budujeme ochranná opatření, která fungují napříč harnessy agentů, a poskytujeme naše nástroje jako open-source. To je také důvod, proč zveřejňujeme slabiny, které najdeme v jiných platformách, a účastníme se aktivit, jako je Open Secure AI Alliance.

Abychom mohli na těchto výzvách spolupracovat s širší komunitou, založila společnost Perplexity v březnu 2026 institut Secure Intelligence Institute, jehož úkolem je studovat bezpečnost, důvěryhodnost a praktickou obranu špičkových systémů AI (Perplexity). Společnost Perplexity aktuálně spolupracuje s akademickými výzkumníky na Stanfordu, CMU, Duke, Columbii, Ohio State a University of Virginia a/nebo je finančně podporuje. Provádíme také interní výzkum s cílem posunout hranice výzkumu bezpečnosti agentů, promítnout tyto pokroky do konkrétních vylepšení systémů Perplexity a sdílet znalosti a zdroje, které pomáhají posílit širší ekosystém AI. Bezpečnější agenty může odvětví navrhnout. Máme v úmyslu i nadále plnit svůj díl úkolu a vyzýváme ostatní, aby stavěli s námi.