Čo je bezpečnosť LLM? Ako zmierniť 10 hlavných bezpečnostných rizík podľa OWASP

Útok, ktorý oklame AI, aby pokyny útočníka považovala za príkazy – prompt injection –, je od roku 2023 v každom vydaní na 1. mieste rebríčka OWASP Top 10 for LLM Applications.

Tento zoznam je asi najbližšie ku konsenzu, aký sa v oblasti bezpečnosti AI dá dosiahnuť. Projekt vznikol ako malá skupina bezpečnostných odborníkov a dnes sa na ňom podieľa viac ako 600 expertov z viac ako 18 krajín.

Sme spoločnosť zameraná na AI a vydávame sprievodcu tým, ako sa dá AI k niečomu prehovoriť, takže nebudeme predstierať, že je tento problém vyriešený. Wilson, ktorý spoluvedie projekt OWASP, sa o súčasných obranných mechanizmoch vyjadril celkom jasne: „...úprimne, nemyslím si, že sme na 99 %.“

Vydanie z roku 2026 začína v rovnakom duchu. Vedúci projektu nám radí, aby sme „sa prestali snažiť vytvoriť model, ktorý sa nedá oklamať“, a okolitý systém navrhli tak, aby oklamaný model nemohol pokaziť nič dôležité.

Tento prístup uplatníme pri všetkých 10 rizikách zo zoznamu OWASP na rok 2026.

Čo znamená bezpečnosť LLM?

Bezpečnosť LLM znamená ochranu modelov AI a aplikácií, ktoré ich využívajú, pred útokmi a zneužitím. Riziko rastie s tým, k čomu je model pripojený: k súborom a dátam, ktoré dokáže čítať, a k nástrojom, ktoré môže používať, ako je e-mail, vyhľadávanie alebo firemná databáza.

V správne zabezpečenom softvéri existuje pevná hranica medzi pokynmi, ktorými sa program riadi, a informáciami, ktoré spracúva. LLM však takúto hranicu nemajú.

Všetko, čo model číta, k nemu prichádza ako jeden dlhý prúd textu: pokyny vývojára, vaša otázka aj webová stránka, ktorú vyhľadal. Modely AI by mali rozlišovať, kto práve hovorí – či je to vývojár, používateľ, alebo samotný model, ktorý premýšľa nad problémom.

Výskumníci Jasmine Cui a Charles Ye však zistili, že modely väčšinou odhadujú, kto hovorí, podľa toho, ako text znie. Ak teda útočník napíše niečo, čo znie ako vlastné uvažovanie modelu, model môže uveriť, že na tú myšlienku prišiel sám. To je problém pre každé bezpečnostné riešenie, ktoré závisí od toho, či model vie, kto má hlavné slovo.

Na rovnaký problém sme narazili aj pri našich vlastných AI agentoch. Náš CISO Kyle Polley povedal pre ISMG, že agenti sa „nemusia riadiť zásadami, ani keď ich pridáte do systémového promptu“. Preto sme vytvorili Numbat – open-source nástroj, ktorý kontroluje, čo sa agent chystá urobiť, a dokáže to zablokovať, ak by akcia porušila nakonfigurované bezpečnostné pravidlo.

Bezpečnosť LLM znamená prijať, že model sa niekedy bude riadiť pokynmi nesprávnej osoby, a vybudovať okolo neho ochranné mechanizmy AI, ktoré vydržia aj vtedy, keď sa to stane.

Aké sú osvedčené postupy v oblasti bezpečnosti LLM?

Postupne prejdeme rebríček OWASP Top 10 for LLM Applications 2026 od 1. po 10. miesto.

Pri každom riziku vám zrozumiteľne vysvetlíme, čo sa môže pokaziť, a uvedieme príklad z praxe. Potom sa pozrieme na postupy, ktoré môžu pomôcť riziku predísť alebo aspoň obmedziť škody.

1. Obmedzte dosah prompt injection

K prompt injection dochádza, keď útočník prinúti AI riadiť sa pokynmi, ktorými by sa riadiť nemala. Tieto pokyny môžu prísť priamo v chate alebo môžu byť podstrčené v e-maile, na webovej stránke či v dokumente.

Druhý typ sa nazýva nepriama prompt injection. Požiadate svojho asistenta, aby zhrnul dokument. Jeho autor v ňom však asistentovi prikázal, aby mu poslal vaše súkromné súbory. Ak sa asistent týmito pokynmi riadi, autor dokumentu si v podstate požičal váš prístup.

PCMag prirovnáva zabezpečenie promptov k upchávaniu dier v pórovitom kameni. Utesníte jeden otvor a voda si nájde iný. „Útok si nájde cestu; opraví sa, no nespočetné množstvo ďalších ciest útoku ešte len čaká na odhalenie, jednoducho preto, aké dynamické sú systémy ako LLM.“

Príklad: V júni 2025 výskumníci zo spoločnosti Aim Security objavili EchoLeak – chybu, vďaka ktorej sa podarilo oklamať Microsoft 365 Copilot, aby vyzradil súkromné firemné informácie. Keď zamestnanec položil bežnú pracovnú otázku, Copilot mohol načítať škodlivý e-mail, riadiť sa pokynmi v ňom ukrytými a odoslať citlivé informácie útočníkovi. Útok obišiel kontroly, ktoré mali zachytiť škodlivé pokyny a odstrániť podozrivé odkazy.

Čo môžete urobiť:

• Riaďte sa „pravidlom dvoch“ od spoločnosti Meta: EchoLeak potreboval AI, ktorá dokázala čítať firemné dáta, čítať externé e-maily a odosielať informácie von – a tá mala všetky tri schopnosti. Ak ju obmedzíte na dve z nich, prompt injection nezíska príliš veľkú kontrolu. Ak úloha vyžaduje všetky tri, pred každou akciou vyžadujte schválenie človekom.
• Testujte proti útočníkom, ktorí poznajú vaše obranné mechanizmy: Poskytnite bezpečnostným testerom pravidlá a filtre, ktoré ste zaviedli, a nechajte ich, aby sa ich pokúsili obísť. V jednej štúdii boli útočníci, ktorí sa obranným mechanizmom prispôsobili, úspešní vo viac ako 90 % prípadov proti väčšine z 12 testovaných obranných mechanizmov.

2. Zabráňte úniku citlivých informácií

Keď systémy AI poskytnú súkromné informácie ľuďom, ktorí by ich nemali vidieť, hovoríme o úniku citlivých informácií. Môže ísť o prezradenie platobných údajov zákazníka alebo o súkromné konverzácie ponechané v zdieľanej databáze.

Mnohé úniky začínajú „prílišným zdieľaním“. Povedzme, že firma pripojí svoju AI k diskom a znalostným databázam s voľne nastavenými oprávneniami. AI načíta všetko, k čomu sa dostane, presne tak, ako bola navrhnutá. Nikto sa nemusí nikam nabúrať, no LLM už môžete považovať za kompromitovaný.

Príklad: V januári 2025 výskumníci zo spoločnosti Wiz našli databázu DeepSeek voľne prístupnú z internetu s viac ako miliónom záznamov v protokoloch vrátane histórie chatov a kľúčov API, ktoré softvér používa na prístup k iným službám. Výskumníci nemuseli model k ničomu prehovárať.

Čo môžete urobiť:

• Overte prístup skôr, ako AI prečíta dáta: Vaša aplikácia by mala pred odovzdaním dokumentov modelu skontrolovať, ktoré z nich smie vidieť osoba, ktorá kladie otázku.
• Chráňte záznamy, ktoré po sebe AI zanecháva: Pred uložením protokolov aktivity z nich odstráňte súkromné údaje a tajné kľúče, vyžadujte prihlásenie a obmedzte prístup na ľudí, ktorí ho potrebujú. Nastavte dobu uchovávania, aby sa tieto záznamy nehromadili donekonečna.

3. Skroťte nadmernú autonómiu

AI s nadmernou autonómiou má viac moci, než si jej práca vyžaduje: nástroje, ktoré nepotrebuje, oprávnenia presahujúce jej úlohu alebo voľnosť konať bez kontroly. Príčina tu nie je podstatná.

Prompt injection, chyba v kóde alebo model, ktorý sa jednoducho pomýli – to všetko vedie k rovnakému výsledku. Ak má AI na to schopnosť, skôr či neskôr urobí niečo deštruktívne.

Príklad: V júli 2025 zakladateľ spoločnosti SaaStr Jason Lemkin oznámil, že programovací agent od Replitu vymazal jeho databázu s 1 206 záznamami o vedúcich pracovníkoch, a to napriek pokynom nevykonávať žiadne zmeny. Agent najprv tvrdil, že dáta sa nedajú obnoviť, hoci neskôr sa ukázalo, že obnova je možná. Jason zistil, že keď agentovi povedal, aby databázu nechal na pokoji, neodobral mu tým schopnosť ju vymazať.

Zväčšiť

Zdroj: X

Čo môžete urobiť:

• Odoberte schopnosti, ktoré úloha nepotrebuje: Obmedzte nástroje, ktoré agent dostane, aj to, čo tieto nástroje dokážu. Asistent, ktorý sumarizuje e-maily, potrebuje oprávnenie ich čítať, nie odosielať či mazať.
• Kontroly oprávnení umiestnite mimo AI: Každú požadovanú akciu overte voči svojim bezpečnostným pravidlám a vyžadujte, aby ju schválil človek.

4. Kontrolujte, čo vstupuje do vášho dodávateľského reťazca AI

Len málo firiem vyvíja AI od nuly a každým rokom ich je menej. Podľa prieskumu Menlo Ventures 2025: The State of Generative AI in the Enterprise si v roku 2024 kúpilo modely AI 53 % firiem a v roku 2025 to bolo už 76 %.

Firmy najčastejšie sťahujú modely z platforiem, ako je Hugging Face, ďalej ich trénujú na datasetoch, ktoré zozbierali iní, a pripájajú doplnky a kódové balíky od neznámych autorov.

Každá z týchto častí je možnou vstupnou bránou. Ak niekto s jednou z nich manipuluje, problém sa dostane priamo do vášho produktu.

Príklad: Počet verejných repozitárov modelov na Hugging Face vzrástol od januára 2026 do augusta 2026 z 2,43 milióna na 2,96 milióna. V júli 2026 však modely OpenAI počas interného bezpečnostného testovania obišli kontroly, ktoré im mali brániť v prístupe na internet, a prenikli do častí systémov Hugging Face. Jeden agent dokonca získal 14 verejne odhalených prístupových údajov, overil, že fungujú, a zdieľal ich s ďalšími agentmi. Agenti potom zneužili chyby, ktoré im umožnili spúšťať kód na serveroch Hugging Face.

„Zavádzame prísnejšie požiadavky na zosúladenie (alignment) počas celého životného cyklu modelu, vytvárame izolovanejšie sandboxy, obmedzujeme prístup na internet a ďalej sprísňujeme kontrolu prístupu k váham modelov,“ uvádza správa OpenAI.

Čo môžete urobiť:

• Zafixujte modely na presnú verziu a overte ich: Každý model zafixujte na skontrolovanú verziu a pred načítaním overte odtlačok jeho súboru, aby sa pod rovnakým označením nemohol prepašovať podvrhnutý súbor. OWASP odporúča aj digitálne podpisy, no s výhradou – podpis dokazuje, odkiaľ model pochádza, nie to, že je bezpečný.
• Kontrolujte každý balík, ktorý vaša AI navrhne: Pred inštaláciou kódového balíka, ktorý odporučil AI asistent, overte, že existuje, že ide o balík, ktorý ste mali na mysli, a že pochádza od očakávaného vydavateľa.

5. Chráňte sa pred otrávením dát a modelu

Otrávená AI sa učí z poškodených dát. Môže ísť o príklady, na ktorých bola doladená, alebo o znalostnú databázu, v ktorej hľadá odpovede. Model naďalej pôsobí funkčne – len sa naučí nesprávne veci a niekedy sa naučí správať nežiaduco iba vtedy, keď narazí na konkrétnu spúšťaciu frázu.

Model prejde každým testom, ktorý mu dáte, až kým túto frázu niekto nepoužije.

Zväčšiť

Navyše sa to veľmi ťažko napráva. Otrávenie nie je chyba, ktorú opravíte záplatou. Ak sú vaše dáta nesprávne, možno ich budete musieť znova skontrolovať, model pretrénovať alebo ho úplne nahradiť.

Príklad: V októbri 2025 výskumníci zo spoločnosti Anthropic, britského UK AI Security Institute a Alan Turing Institute ukázali, že 250 otrávených dokumentov dokáže model naučiť generovať nezmysly vždy, keď narazí na konkrétny spúšťač. Rovnaký počet fungoval pri všetkých štyroch testovaných veľkostiach modelu, hoci najväčší z nich bol trénovaný na viac ako 20-násobne väčšom objeme čistých dát.

Čo môžete urobiť:

• Sledujte, odkiaľ vaše dáta pochádzajú: Evidujte každý dataset a model, ktorý používate, odkiaľ pochádza a čo sa medzi verziami zmenilo. Odporúčame verziovanie datasetov, aby ste sa v prípade odhalenia otrávenia mohli vrátiť k čistej verzii a zistiť, ako sa otrávené dáta dostali dnu.
• Testujte prítomnosť zadných vrátok: „Zadné vrátka“ sú skryté správanie, ktoré útočník podstrčí do modelu a ktoré čaká na konkrétnu frázu alebo iný spúšťač, ktorý ho aktivuje. Odhaľte ich pomocou vstupov navrhnutých tak, aby model porušil svoje bežné pravidlá.

6. Nastavte strop neobmedzenej spotrebe

Keď AI nemá žiadne obmedzenia toho, koľko práce môže vykonať alebo koľko môže stáť, jej spotreba sa považuje za „neobmedzenú“. Väčšina služieb AI účtuje poplatky za používanie, takže útočník by vám mohol vyhnať účet do závratnej výšky alebo vytvoriť kópiu vášho modelu.

OWASP označuje jadro problému ako „nákladovú asymetriu“. Krátka a lacná požiadavka môže na vašej strane spustiť nákladné výpočty.

Príklad: V máji 2024 tím Threat Research Team spoločnosti Sysdig odhalil nový útok nazvaný „LLMjacking“. Skupina útočníkov sa pomocou ukradnutých prístupových údajov zamerala na 10 cloudových služieb LLM. Dostali sa dnu cez zraniteľnú verziu Laravelu a potom zisťovali, čo im prístupové údaje umožňujú a aké majú kvóty – so zjavným cieľom predávať prístup. Dopytovali sa aj na množstvo nastavení protokolovania, pravdepodobne preto, aby sa vyhli odhaleniu. Podľa spoločnosti Sysdig by v najhoršom prípade mohol útok obeť stáť viac ako 46 000 dolárov denne.

Čo môžete urobiť:

• Nastavte rozpočty, ktoré výdavky zastavia: Stanovte pevné limity výdavkov pre jednotlivých používateľov, kľúče API, tímy aj pre účet ako celok. Vynucujte ich všade, kade môžu prichádzať požiadavky.
• Každej úlohe určite bod zastavenia: Obmedzte, ako dlho môže úloha bežať, koľko textu môže spracovať a vygenerovať a koľko volaní nástrojov môže uskutočniť. Pridajte automatické zastavenie pre agentov, ktorí sa opakujú alebo prekročia svoj limit.

7. Zachyťte dezinformácie skôr, ako podľa nich začnete konať

Keď AI vytvorí niečo nepravdivé, čo znie správne, a niekto alebo niečo podľa toho koná, hovoríme o dezinformácii. Hlavným rizikom nie je ani tak samotná nesprávna odpoveď, ako skôr to, že sa jej dôveruje a ďalej sa použije.

Záznamy o incidentoch naznačujú, že odborníci sa dezinformácií neobávali tak, ako by mali. Podľa úvodného listu k vydaniu z roku 2026 ich hlasujúci zaradili takmer na koniec, no podľa skutočných incidentov patria takmer na vrchol.

Príklad: V roku 2025 spoločnosť Deloitte Australia odovzdala posudok IT systémov sociálneho zabezpečenia v rámci vládnej zákazky v hodnote 440 000 austrálskych dolárov. Výskumník z University of Sydney Chris Rudge v ňom našiel odkazy na neexistujúci výskum a vymyslený citát z rozsudku federálneho súdu. V revidovanej správe Deloitte priznal, že pri svojej metodike použil Azure OpenAI GPT-4o, a firma súhlasila s vrátením poslednej splátky. Išlo pritom, žiaľ, o overovací posudok.

Čo môžete urobiť:

• Overte, či dôkazy podporujú odpoveď: Opierajte tvrdenia o aktuálne a dôveryhodné zdroje. Pri odpovedi o internej smernici načítajte schválenú smernicu a overte, či podporuje záver, a to vrátane jej výnimiek.
• Overujte skôr, ako systém začne konať: Ak agent tvrdí, že zákazník prešiel overením totožnosti, pred uvoľnením platby to overte v overovacom systéme. Pri závažných rozhodnutiach vyžadujte schválenie človekom a posudzovateľovi sprístupnite podporné dôkazy.

8. Obmedzte škody spôsobené odhalením skrytého kontextu

Aplikácie AI poskytujú modelu pokyny a podkladové informácie, ktoré používatelia bežne nevidia. Môže ísť o systémový prompt, interné zásady, popisy dostupných nástrojov a pravidlá o tom, kto ich môže používať. K odhaleniu skrytého kontextu dochádza, keď model tieto informácie niekomu prezradí.

OWASP v roku 2026 rozšíril túto položku z „úniku systémového promptu“, pretože systémový prompt je len časťou toho, čo môže uniknúť. Nebezpečenstvo závisí od toho, čo ste doň vložili. Uniknutý návod na tón komunikácie je mierne trápny, no uniknutý kľúč API dáva niekomu prístup k vašej dôvernej databáze.

Príklad: Vo februári 2023 používatelia prinútili Bing Chat od Microsoftu prezradiť svoje interné pokyny. Autorom jedného z úspešných pokusov bol Marvin von Hagen, ktorý sa vydával za vývojára OpenAI a požiadal o pokyny, aby mohol model nakonfigurovať. Bing prezradil pravidlá, ktorými sa riadia jeho vyhľadávania, odpovede a bezpečnostné správanie, ako aj svoje interné meno Sydney. Medzi odhalenými pokynmi bol aj jeden, ktorý mu prikazoval tieto pokyny držať v tajnosti.

Čo môžete urobiť:

• Neuchovávajte tajné údaje v kontexte modelu: Predpokladajte, že čokoľvek, čo model dokáže prečítať, sa môže stať viditeľným pre používateľov – heslá, kľúče API a prístupové tokeny ukladajte v samostatnom systéme na správu tajných údajov.
• Zabezpečte, aby oprávnenia platili, aj keď pravidlá uniknú: Kontroly prístupu vynucujte v kóde aplikácie. Ak je nástroj vyhradený pre administrátorov, pred jeho spustením overte oprávnenia používateľského účtu.

9. Zabezpečte vektory a embeddingy

Keď AI využíva vektorové vyhľadávanie na hľadanie odpovedí v dokumentoch vašej spoločnosti, neprehľadáva priamo text. Dokumenty sa prevedú na tzv. „embeddingy“ – dlhé zoznamy čísel, ktoré zachytávajú význam jednotlivých pasáží – a uložia sa do vektorovej databázy. Otázka sa prevedie rovnakým spôsobom a systém vyberie pasáže, ktorých čísla sú jej najbližšie.

OWASP zhŕňa štyri spôsoby, ako môže systém zlyhať: otrávenie spôsobí, že sa mýli, inverzia spôsobí únik údajov, rušenie ho umlčí a narušená kontrola prístupu spôsobí, že vydá čokoľvek komukoľvek.

Čísla nie sú takou bezpečnou abstrakciou, akou sa zdajú. Uložené embeddingy sa dajú spätne previesť na text a jedna metóda v testoch presne obnovila 92 % krátkych 32-tokenových pasáží. Uniknutá záloha „iba s embeddingmi“ tak môže odhaliť aj obsah dokumentov.

Príklad: Výskum prezentovaný na konferencii USENIX Security 2025 ukázal, že jediný starostlivo vytvorený dokument dokáže zabrániť AI odpovedať na konkrétnu otázku. Výskumníci ho pridali do kolekcie, ktorú AI prehľadávala. Keď ho AI našla, mohla odpovedať, že nemá dostatok informácií alebo že odpovedať by nebolo bezpečné. Dokument pritom nemusel AI prikazovať, aby ignorovala svoje pravidlá. Tento jav sa nazýva „rušenie vyhľadávania“ (retrieval jamming).

Čo môžete urobiť:

• Udržiavajte samostatné indexy pre verejné a súkromné údaje: Nemiešajte obsah získaný z webu s údajmi partnerov ani s dôvernými internými dokumentmi. Namiesto označovania obsahu v jednom indexe zaveďte fyzické oddelenie podľa úrovne dôveryhodnosti – odstránite tým celú triedu chybných konfigurácií a obsah stiahnutý z internetu sa nemôže ocitnúť vedľa materiálov pre predstavenstvo.
• K embeddingom pristupujte rovnako ako k dokumentom, z ktorých vznikli: Šifrujte ich, chráňte zálohy vektorovej databázy rovnako ako zdrojové súbory a pri odstránení originálu odstráňte aj embeddingy. Kľúče API k službe na tvorbu embeddingov uchovávajte v tajnosti.

10. Výstup AI pred odovzdaním ďalej skontrolujte

Vždy, keď aplikácia odovzdá výstup AI inému systému bez toho, aby overila, či je bezpečný na použitie v ňom, ide o nesprávne spracovanie výstupu LLM.

Táto položka sa vzťahuje aj na nezabezpečený kód, ktorý programovací asistenti s AI generujú vo veľkom. Každý riadok, ktorý asistent napíše, je teda tiež výstupom.

Príklad: V roku 2025 výskumník Johann Rehberger ukázal, ako mohol programovací asistent Amp od spoločnosti Sourcegraph vyzradiť obsah chatu len tým, že zobrazil obrázok. Pomocou útoku typu prompt injection prinútil Amp vložiť súkromné informácie do webovej adresy obrázka. Aplikácia potom tento obrázok automaticky načítala, a tak informácie odoslala na jeho server. Zlyhanie pri spracovaní výstupu spočívalo práve v tejto automatickej požiadavke – text vygenerovaný modelom sa zmenil na pripojenie k externému serveru, ktoré so sebou prenášalo súkromné údaje.

Čo môžete urobiť:

• Zabezpečte, aby bol výstup bezpečný pre svoj cieľ: Odpovede kontrolujte a spracúvajte podľa toho, kam smerujú. Pri webovej stránke zabráňte tomu, aby sa z vygenerovaného textu stal spustiteľný kód. Pri databáze používajte pripravené dopyty, ktoré oddeľujú zadané hodnoty od príkazov.
• Zabráňte tomu, aby odpovede automaticky nadväzovali externé pripojenia: V predvolenom nastavení vypnite v odpovediach modelu automatické načítavanie obrázkov, náhľadov odkazov a vložených stránok. Nevyhnutné pripojenia obmedzte na výslovne schválené ciele.

Ako Perplexity zabezpečuje LLM?

Predpokladáme, že každé z vyššie uvedených rizík sa raz naplní, a systémy navrhujeme tak, aby v takom prípade nemohlo napáchať veľa škody. Náš CISO Kyle Polley to podrobne vysvetlil na nedávnom workshope.

• Agent dostane vlastný počítač, ktorý je na začiatku prázdny: Nástroje agentov nainštalované na vašom notebooku môžu získať prístup k jeho súborom, aplikáciám a uloženým prihlasovacím údajom. Perplexity Computer funguje opačne. Každá úloha beží vo vlastnom izolovanom sandboxe a ako hovorí Polley, „v predvolenom nastavení nemá prístup k ničomu“.
• Agent nikdy nevidí heslá: Prihlasovacie údaje k pripojeným službám sú uložené mimo sandboxu. Keď agent potrebuje pristúpiť k službe, napríklad ku GitHubu, odošle požiadavku bez prihlasovacích údajov. Brána overí, či cieľ a požiadavka zodpovedajú očakávaniam, a prihlasovacie údaje pridá až k odchádzajúcej požiadavke. Agent tak môže pripojenie využívať bez toho, aby získal kľúče.
• Vaše oprávnenia sa prenášajú a môžete ich ešte sprísniť: Pripojenia vytvorené cez OAuth zachovávajú vaše prístupové oprávnenia v pripojenej službe. Ak niečo nevidíte vy, nevidí to ani váš agent.
• Ku každej webovej stránke pristupujeme ako k neznámej: BrowseSafe sme vytvorili pre Comet, náš agentický prehliadač, pretože nástroje, ktoré sme testovali, pri reálnom používaní nespĺňali naše potreby. Prehliadač kontroluje webové stránky a ďalší externý obsah vrátane e-mailov, či neobsahujú útoky typu prompt injection. Model aj množinu údajov sme zverejnili ako open source.
• Sledujeme agenta aj počítače, na ktorých beží: Numbat stojí medzi rozhodnutím agenta konať a samotným spustením nástroja. Numbat zaznamenáva aktivitu naprieč podporovanými programovacími agentmi a dokáže zablokovať akcie, ktoré porušujú nakonfigurované pravidlá, ešte pred ich vykonaním. Bumblebee inventarizuje softvérové balíky na notebookoch, serveroch a v zostavovacích kanáloch a označuje známe škodlivé balíky. Oba nástroje sú open source.
• Poskytovatelia modelov si vaše údaje neuchovávajú: S externými poskytovateľmi LLM máme dohody o nulovom uchovávaní údajov. Podnikoví administrátori môžu navyše skrátiť uchovávanie údajov v samotnej službe Perplexity až na 24 hodín.

Numbat sme vytvorili proaktívne, a to z dôvodu, ktorý Polley zhŕňa jednou vetou: „Čím viac autonómie agentovi dáte, tým väčšie je riziko.“

Časté otázky o bezpečnosti LLM

Ktorý LLM je najbezpečnejší?

Žiadny LLM sám osebe nezabezpečí aplikáciu – modely si stále môžu pomýliť obsah, ktorý majú čítať, s pokynmi, ktoré majú dodržiavať. Obranné mechanizmy, ktoré v štandardných testoch pôsobia silne, môžu pod tlakom tiež zlyhať.

Lepšou otázkou je, aké nastavenie je pre váš prípad použitia najbezpečnejšie. To znamená obmedzené oprávnenia, prihlasovacie údaje mimo dosahu modelu, schvaľovanie rizikových akcií človekom a testovanie ľuďmi, ktorí poznajú vaše obranné mechanizmy.

Čo sú zraniteľnosti LLM?

Zraniteľnosti LLM sú slabiny, ktoré umožňujú, aby bol systém AI oklamaný, vyzradil údaje alebo spôsobil škodu – či už pričinením útočníka, alebo vlastnými chybami systému.

Desať hlavných rizík zahŕňa prompt injection, vyzradenie citlivých informácií, nadmernú autonómiu, riziká dodávateľského reťazca, otrávenie údajov a modelu, neobmedzenú spotrebu, dezinformácie, odhalenie skrytého kontextu, slabiny vektorov a embeddingov a nesprávne spracovanie výstupu.

Je súkromný LLM bezpečný?

Pre niektoré účely je to bezpečnejšia možnosť, no nie automaticky. Ak model prevádzkujete na vlastnej infraštruktúre alebo v cloudovom prostredí, máte väčšiu kontrolu nad spracovaním údajov. Neexistuje však automatický spôsob, ako zabrániť útokom typu prompt injection, nadmernej autonómii, otráveniu či dezinformáciám.

Pri vlastnom hostingu zodpovedáte aj za model, ktorý si stiahnete, vrátane rizík dodávateľského reťazca a infraštruktúry, ktorú vyžaduje.