Myslitelé

AI agenti potřebují bezpečnostní hranice, které nemohou přepsat

mm
Přidejte Unite.AI mezi své preferované zdroje na Google

Je lákavé číst příběh Hugging Face jako okamžik, kdy AI agenti zbloudili. To však není přesně to, co se stalo, a podrobnosti jsou důležité. Jednalo se o výzkumné agenty v oblasti kybernetické bezpečnosti, kteří běželi v hodnoceních, kde byly ochranné mechanismy úmyslně vypnuty, aby výzkumníci mohli vidět, co modely dokážou. Žádný bot zákaznické služby se neprobudil jednoho rána a nerozhodl se napadnout společnost. Ale tento kontext nikoho neosvobozuje od odpovědnosti. Agent překročil hranici, ve které měl zůstat, použil přihlašovací údaje a nástroje způsobem, který jeho operátoři nikdy neautorizovali, a skončil v systémech, které patřily někomu jinému. To je část, na kterou by se měl zaměřit každý bezpečnostní tým.

Reuters oznámil, že agenti zkoumali Hugging Face již v květnu, i když výzkumníci uvedli, že nenašli nic, co by ukazovalo, že dřívější aktivita sama o sobě způsobila porušení. Červenec byl jiný. OpenAI uvedl, že jeho modely obešly izolační kontroly, dosáhly internetu a ohrozily části vlastní výzkumné infrastruktury spolu se systémy Hugging Face. Vlastní výpověď Hugging Face popisuje průnik provedený autonomním agentním systémem od začátku do konce, který využil jeho datové zpracovatelské potrubí, získal přihlašovací údaje a přesouval se mezi interními clustery.

Nejnepříjemnější částí je, že agenti plnili své úkoly. Honili cíl, který jim byl zadán. Proto se tento příběh rozprostírá daleko za hranice jedné výzkumné laboratoře. Podnikové agenti také honí cíle. Drží přihlašovací údaje, volají nástroje a pohybují se rychleji, než může kterýkoli člověk zkontrolovat. Agent s naprosto dobrými úmysly může stále způsobit skutečnou škodu a napadený agent může použít stejnou pravomoc jménem útočníka. Proto bezpečnost musí řídit, co může systém skutečně udělat, bez ohledu na to, jak sebejistě model zní nebo jak neškodný se zdá jeho deklarovaný účel.

Zabezpečte akci, ne jen model

Většina raných programů agentů soustředí své úsilí na model. Týmy testují výzvy, ladí odmítnutí, přidávají druhý model pro kontrolu prvního a sledují sledování uvažování kvůli známkám špatného úmyslu. Nic z toho není zbytečné. Ale vše je pravděpodobnostní, protože závisí na dalším modelu, který učiní rozhodnutí. Produkční bezpečnostní hranice musí být deterministická a musí obklopovat nástroje, přihlašovací údaje, sítě a transakce.

Otázka, kterou bych položil, je konkrétní: co může tento agent ve skutečném světě skutečně způsobit? Vypracování žádosti o platbu je jedna věc. Uvolnění prostředků je jiná. To samé platí pro přípravu změny databáze versus její spuštění v produkci, nebo označení záznamů, které splňují pravidlo uchování, versus jejich smazání. Může se jednat o stejný model v obou případech, s velmi odlišným rizikem v závislosti na tom, na které straně té hranice se nachází.

Nedávný přehled Unite AI o řízení schopností stanoví stejnou hranici, spojující riziko s daty, nástroji, oprávněními, autonomií a prostředím, ve kterém agent běží. Líbí se mi toto pojetí, protože nás posouvá mimo vágní označení jako \”safe model\” a \”unsafe model\”. Nutí týmy sledovat každou cestu od rozhodnutí agenta k něčemu s reálnými důsledky.

Dejte každému agentovi identitu a úzký mandát

Agent by neměl nikdy běžet na vývojářském účtu ani zdědit vše, co je lidskému uživateli povoleno. Sdílená identita ruší přiřazení. Dlouhodobé přihlašovací údaje poskytují útočníkovi více času k jejich zneužití. A široké servisní účty umožňují malému pracovního postupu procházet data a systémy, ke kterým nemá oprávnění.

NIST nyní považuje identitu softwaru a AI agentů za svůj vlastní architektonický problém. Jeho koncepční dokument se ptá, jak může agent prokázat, že je oprávněn k určité akci, jak může být identita agenta navázána zpět na lidské oprávnění, a jak mohou organizace udržovat od manipulace odolné záznamy o tom, co bylo zamýšleno a co se skutečně stalo. V praxi to směřuje k jednoduchému návrhu. Každý agent získá jedinečnou identitu, vlastníka (osobu nebo tým), definovaný účel a oprávnění omezena na konkrétní úkol.

Přihlašovací údaje by měly rychle vypršet a fungovat pouze pro konkrétní zdroje a akce. Přístup k síti by měl vycházet z úzkého seznamu povolených. Pokud agent potřebuje dotazovat jednu schválenou databázi, neměl by také získat obecný shell, otevřený přístup k internetu nebo pravomoc vytvářet nové přihlašovací údaje. A jak práce prochází řetězcem agentů a nástrojů, pravomoci by se měly na každém kroku zužovat, nikoli rozšiřovat.

NIST také varuje před sdílením přihlašovacích údajů a příliš širokým přístupem, a toto varování má váhu, protože agenti jsou oportunističtí. Pokud je jedna cesta zablokována, mohou zkusit jiný nástroj, prozkoumávat své prostředí nebo narazit na token, který někdo zapomněl. Získané přihlašovací údaje byly také součástí červencové události. Princip nejmenších oprávnění udržuje oblast poškození malou, když vrstva uvažování udělá něco, co její návrháři nečekali.

Udržujte autorizaci mimo smyčku uvažování

Agent může doporučit akci. Neměl by rozhodovat, zda je povoleno ji provést. Toto rozhodnutí patří do samostatné vrstvy vynucování, kterou agent nemůže přepsat, vypnout ani obejít. Každé volání nástroje by mělo být zobrazeno jako strukturovaný požadavek: který agent žádá, který člověk jej podpořil, jakou operaci chce, na co cílí a jaká omezení platí. Vrstva vynucování pak povolí, zablokuje nebo eskaluje požadavek.

OWASP popisuje nadměrnou autonomii jako směs zbytečné funkčnosti, nadměrných oprávnění a příliš velké autonomie. Jeho doporučení vyzývá k úzkým nástrojům, minimálním oprávněním, autorizaci na podřízeném systému a schválení uživatelem pro vysoce dopadové akce. Myslím, že to je přesně ten správný postup. Pravidlo by mělo vynucovat kdokoli, kdo vlastní data nebo provádí transakci. Pokud model řekne, že akce je schválena, mělo by to samo o sobě mít nulovou váhu.

Toto oddělení pomáhá také při injekci promptů. Otrávený e‑mail nebo dokument může nasměrovat uvažování agenta, ale nemůže rozšířit agentova oprávnění ani obejít politickou bránu. Model je volný požádat o něco zakázaného. Systém by však měl stále říci ne.

Uchovejte lidské schválení pro momenty, na kterých opravdu záleží

Lidské přezkoumání si zaslouží místo, když akce nelze vrátit, překračuje organizační hranici, mění oprávnění, uvolňuje citlivé informace, přesouvá peníze nebo zasahuje do produkčního systému. Požádejte o schválení při každém rutinním kroku a získáte dvě věci: zpoždění a lidi, kteří se naučí kliknout „schválit“ bez čtení. NIST tuto únavu ze souhlasu pojmenovává.

Dobré žádosti o schválení zobrazují přesnou akci v srozumitelném jazyce, včetně toho, kam směřuje, a důležitých parametrů. Měly by pocházet z autoritativního systému, ne z textu, který agent napsal. Schválení by mělo rychle vypršet a vztahovat se jen na tuto jedinou akci. Pokud se změní jakýkoli podstatný detail, systém se znovu zeptá.

Bezpečnostní pokyny OWASP pro agenty doporučuje testovat, zda může vysoce dopadová akce proběhnout bez platného, nevypršeného, parametricky vázaného schválení. Tato fráze stojí za zapamatování. \”OK pokračovat\” je slabé schválení, které může schválit jiný agent nebo škodlivý aktér. \”Převést tuto částku na tento účet\” nebo \”nasadit tuto změnu do tohoto prostředí\” je něco, co systém může skutečně ověřit v okamžiku provedení, a uživatel to plně chápe.

Živá lidská identita je na této bráně zásadní. Push notifikace dokazuje jen to, že někdo nebo něco stisklo tlačítko. Silnější návrhy vyžadují, aby zaregistrovaná osoba použila odolnou vůči phishingu autentizaci pomocí veřejného klíče, podpořenou lokální biometrickou metodou.Standardy FIDO vázají pověření s veřejným klíčem na legitimní online službu a uchovává biometrická data na izolovaném zařízení uživatele. Při správném použití poskytuje autentizace založená na hardwaru mnohem lepší důkaz, že správná osoba byla skutečně přítomna. Nicméně nenahrazuje vázání transakcí, důvěryhodné zobrazení ani vynucování politik. Potřebujete, aby všechny tyto prvky spolupracovaly.

Sledujte chování a zachovejte důkazy

Nemůžete spoléhat na počáteční prompt, aby vysvětlil, co se stalo během dlouhého běhu agenta. Bezpečnostní týmy potřebují telemetrii o voláních nástrojů, síťové aktivitě, používání pověření, rozhodnutích o politice, schváleních, odmítnutích a změnách rozsahu. Monitorování by mělo porovnávat, co agent skutečně udělal, s hranicí deklarovanou pro tento běh. Pokud je agent přidělen k analýze kódu a začne hledat externí pověření nebo zkoumat nesouvisející službu, mělo by to vyvolat poplach.

Záznamy potřebují dostatek kontextu k obnovení řetězce akcí, aniž by odhalily tajemství v prostém textu. Každý záznam by měl zachytit verzi agenta, jeho vlastníka, osobu nebo systém, který spustil proces, použitý nástroj, požadovanou akci, výsledek politiky a jakékoli lidské schválení. Podepsané nebo jinak odolné vůči manipulaci záznamy činí následnou revizi mnohem důvěryhodnější, zejména když se podílelo několik agentů a služeb.

Vše to musí běžet rychlostí stroje. Nikdo sledující dashboard nezastaví tisíce volání, která skončí během sekund. Automatizované kontroly by měly vynucovat limity rychlosti, zachytávat neobvyklé sekvence a okamžitě pozastavit pověření, jakmile chování překročí definovaný práh. Tím získají lidské vyšetřovatelé omezený incident, který mohou řešit, místo nekonečného pronásledování.

Navrhněte cestu zastavení před nasazením

Každé nasazení agenta potřebuje způsob, jak jej zastavit tak, aby skutečně odstranil schopnost. Požádat agenta o zastavení se nepočítá. Operátoři by měli být schopni odebrat jeho pověření, přerušit jeho síťovou cestu, ukončit jeho běh a zabránit opětovnému spuštění zařazených akcí. Pro workflow s vysokými důsledky, pokud selže služba schvalování nebo politika, měl by systém selhat uzavřeně.

Poté tuto cestu otestujte pod tlakem. Vypněte službu schvalování. Dejte agentovi protichůdné instrukce. Vyměňte pověření uprostřed běhu. Simulujte kompromitovaný nástroj a schvalovatele, který nikdy neodpoví. Potvrďte, že akce je zablokována a že máte užitečný záznam. A opakujte tyto testy vždy, když se změní model, prompt, konektor, paměťový systém nebo sada oprávnění.

Cílem je odpovědná autonomie

Nic z toho není argumentem proti agentům a incident Hugging Face by neměl nikoho odradit od užitečných. Mělo by to zničit představu, že bezpečnostní výzva plus dobré úmysly se rovnají důvěryhodnému nasazení. Dejte agentům prostor k analýze, přípravě práce a řešení reverzibilních úkolů. Omezte jejich pravomoc způsobovat skutečné důsledky na úzký, viditelný rozsah a vynutí ji něčím jiným než samotným agentem.

Než agent přejde do produkce, měli by vedoucí být schopni odpovědět na několik jednoduchých otázek. Jaké systémy může dosáhnout? Jaké přihlašovací údaje může použít? Co může udělat bez revize? Co spouští eskalaci? Jak schvalovatel vidí přesně akci, která je schvalována? Jaké důkazy zůstanou po sobě? A jak může bezpečnost okamžitě zastavit běh?

Pokud jsou odpovědi nejasné, má agent více pravomocí, než si organizace uvědomuje. Architektura, která vydrží v čase, spojuje modelová zabezpečení s identitou, principem nejmenších oprávnění, vnější vynucením politik, selektivním lidským schválením, kompletní telemetrií a zastavovacím mechanismem, který opravdu funguje. Vychází z poctivé předpokladu: schopní agenti nás čas od času překvapí. Naše bezpečnostní hranice by neměly.

Na závěr si představte AI agenta jako stážistu s (potenciálně) root přístupem, který se nebojí HR.

Jaká ochrana a brány by měli mít?

Jednejte podle toho.

Kevin Surace je generálním ředitelem Token a průkopníkem v oblasti AI, vynálezcem, autorem a podnikatelem s desetiletími zkušeností s aplikací umělé inteligence. Drží 95 světových patentů a po celém světě přednáší o AI, automatizaci a budoucnosti práce.