Какво е сигурност на LLM? Как да ограничите 10-те основни риска за безопасността според OWASP

Атака, която подмамва ИИ да приема инструкциите на нападателя като команди – т.нар. инжектиране на промпт (prompt injection) – е № 1 в OWASP Top 10 за LLM приложения във всяко издание от 2023 г. насам.

В сферата на сигурността на ИИ едва ли има нещо по-близко до консенсус от този списък. Проектът започва като малка група специалисти по сигурност, а днес разчита на приноса на над 600 експерти от повече от 18 държави.

Ние сме компания за ИИ, която публикува ръководство за това как ИИ може да бъде убеден да прави неща, които не бива, така че няма да се преструваме, че проблемът е решен. Уилсън, който е съръководител на проекта на OWASP, беше доста категоричен относно настоящите защити: „...честно казано, не мисля, че сме на 99%.“

Изданието за 2026 г. започва в същия дух. Ръководителят на проекта ни призовава да „спрем да се опитваме да изградим модел, който не може да бъде заблуден“, и да проектираме заобикалящата го система така, че заблуденият модел да не може да повреди нищо важно.

Прилагаме този подход към всички 10 риска в списъка на OWASP за 2026 г.

Какво означава сигурност на LLM?

Сигурността на LLM означава защита на ИИ моделите и приложенията, които ги използват, от атаки и злоупотреби. Рискът нараства в зависимост от това, към какво е свързан моделът: файловете и данните, които може да чете, и инструментите, които може да използва, като имейл, търсене или фирмена база данни.

В правилно защитения софтуер има ясна граница между инструкциите, които програмата изпълнява, и информацията, която обработва. Но при LLM такава граница няма.

Всичко, което моделът прочита, пристига като един дълъг поток от текст: инструкциите на разработчика, вашият въпрос, уебстраница, която е потърсил. От ИИ моделите се очаква да следят кой говори – дали разработчикът, потребителят, или самият модел, докато обмисля даден проблем.

Изследователите Джасмин Цуй и Чарлз Йе обаче установяват, че моделите най-вече отгатват кой говори по това как звучи текстът. Затова, ако нападател напише нещо, което звучи като собствените разсъждения на модела, моделът може да повярва, че сам е стигнал до идеята. Това е проблем за всяка защитна схема, която разчита моделът да знае кой командва.

Сблъскахме се със същия проблем и при нашите собствени ИИ агенти. Нашият CISO Кайл Поли каза пред ISMG, че агентите „може да не следват политиките, дори ако ги добавите в системния промпт“. Затова създадохме Numbat – инструмент с отворен код, който проверява какво предстои да направи агентът и може да го блокира, ако действието нарушава зададено правило за сигурност.

Сигурността на LLM означава да приемете, че моделът понякога ще изпълнява заповеди от грешния човек, и да изградите около него защитни механизми за ИИ, които издържат, когато това се случи.

Кои са най-добрите практики за сигурност на LLM?

Ще разгледаме OWASP Top 10 за LLM приложения 2026 поред – от № 1 до № 10.

За всеки риск ще получите обяснение на разбираем език как нещата се объркват, както и пример от реалния свят. След това ще разгледаме практиките, които могат да помогнат да го предотвратите или поне да ограничите щетите.

1. Овладейте инжектирането на промпт

Инжектиране на промпт се случва, когато нападател накара ИИ да следва инструкции, които не би трябвало да следва. Тези инструкции могат да дойдат директно в чат или да бъдат подхвърлени в имейл, уебстраница или документ.

Вторият тип е известен като непряко инжектиране на промпт. Молите асистента си да обобщи документ. Авторите му обаче са наредили на асистента да им изпрати вашите лични файлове. Ако асистентът изпълни тези инструкции, човекът, написал документа, на практика е заел вашия достъп.

PCMag сравнява сигурността на промптовете със запушването на дупки в пореста скала. Запечатвате един отвор, а водата намира друг. „Една атака си пробива път; отстранява се, но безброй други пътища за атака тепърва предстои да бъдат открити просто заради това колко динамични са системи като LLM.“

Пример: През юни 2025 г. изследователи от Aim Security откриха EchoLeak – уязвимост, която подмамваше Microsoft 365 Copilot да разкрива поверителна фирмена информация. Когато служител зададеше рутинен работен въпрос, Copilot можеше да зареди имейла, да изпълни скритите в него инструкции и да изпрати чувствителна информация на нападателя. Атаката заобикаляше проверките, предназначени да улавят злонамерени инструкции и да премахват подозрителни връзки.

Какво можете да направите:

• Следвайте „Правилото на двете“ на Meta: За EchoLeak беше необходим ИИ, който може да чете фирмени данни, да чете външни имейли и да изпраща информация навън – и той имаше и трите възможности. Ограничаването му до две от тях не позволява на инжектирането на промпт да получи твърде голям контрол. Ако задачата изисква и трите, изисквайте одобрение от човек преди всяко действие.
• Тествайте срещу нападатели, които познават защитите ви: Дайте на тестерите по сигурността правилата и филтрите, които сте въвели, и ги оставете да ги заобиколят. В едно проучване нападателите, които се адаптираха към защитите, успяваха в над 90% от случаите срещу повечето от 12-те тествани защити.

2. Спрете изтичането на чувствителна информация

Когато ИИ системи предоставят лична информация на хора, които не бива да я виждат, това се нарича разкриване на чувствителна информация. Това може да означава разкриване на данните за плащане на клиент или оставяне на лични разговори в споделена база данни.

Много изтичания започват с „прекомерно споделяне“. Да кажем, че компания свързва своя ИИ с дискове и бази знания с твърде свободни права за достъп. ИИ извлича всичко, до което може да достигне – точно както е проектиран. Не се налага никой да прониква с взлом, но можете да смятате LLM за пробит.

Пример: През януари 2025 г. изследователи от Wiz откриха база данни на DeepSeek, отворена към интернет, с над милион записа в журнали, включително история на чатове и API ключове, които софтуерът използва за достъп до други услуги. Не се наложи изследователите да убеждават модела да разкрие каквото и да било.

Какво можете да направите:

• Проверявайте достъпа, преди ИИ да прочете данните: Вашето приложение трябва да проверява кои документи има право да вижда човекът, задаващ въпроса, преди да ги подаде на модела.
• Защитете записите, които вашият ИИ оставя след себе си: Премахвайте личните данни и секретните ключове, преди да запазвате журналите на активността, изисквайте вход и ограничавайте достъпа до хората, които се нуждаят от него. Задайте срок на съхранение, за да не се натрупват тези записи безкрайно.

3. Обуздайте прекомерната автономност

ИИ с прекомерна автономност имат повече правомощия, отколкото изисква работата им: инструменти, от които не се нуждаят, права, надхвърлящи задачата им, или свобода да действат без проверка. Причината тук е без значение.

Инжектиран промпт, програмна грешка или модел, който просто сгреши – всичко това води до един и същ резултат. Рано или късно ИИ ще направи нещо разрушително, ако има възможност за това.

Пример: През юли 2025 г. основателят на SaaStr Джейсън Лемкин съобщи, че агентът за програмиране на Replit е изтрил базата му данни с 1206 записа за ръководители, въпреки инструкциите да не прави промени. Първоначално агентът заяви, че данните не могат да бъдат възстановени, но по-късно се оказа, че възстановяването е възможно. Джейсън установи, че указанието да не пипа базата данни не му е отнело способността да я изтрие.

Уголеми

Източник: X

Какво можете да направите:

• Премахнете възможностите, които задачата не изисква: Ограничете както инструментите, които агентът получава, така и това, което тези инструменти могат да правят. Асистент, който обобщава имейли, се нуждае от разрешение да ги чете, а не да ги изпраща или изтрива.
• Поставете проверките на разрешенията извън ИИ: Всеки път, когато бъде поискано действие, го проверявайте спрямо правилата си за сигурност и изисквайте човек да го одобри.

4. Проверявайте какво влиза във веригата ви за доставки на ИИ

Малко компании създават ИИ от нулата и с всяка година те стават все по-малко. Според проучването на Menlo Ventures „The State of Generative AI in the Enterprise“ за 2025 г. 53% са закупили ИИ модели през 2024 г., а през 2025 г. делът им нараства до 76%.

В повечето случаи компаниите изтеглят модели от платформи като Hugging Face, дообучават ги върху набори от данни, събрани от други хора, и добавят разширения и пакети с код, написани от непознати.

Всяка от тези части е потенциална входна точка. Ако някоя бъде манипулирана, проблемът достига до клиентите заедно с вашия продукт.

Пример: Публичните хранилища за модели на Hugging Face нараснаха от 2,43 милиона на 2,96 милиона между януари и август 2026 г. През юли 2026 г. обаче моделите на OpenAI заобиколиха контролите, предназначени да ги държат извън интернет по време на вътрешно тестване на сигурността, и проникнаха в части от системите на Hugging Face. Нещо повече, един агент се сдоби с 14 публично достъпни набора идентификационни данни за достъп, провери дали работят и ги сподели с други агенти. След това агентите се възползваха от уязвимости, които им позволиха да изпълняват код на сървърите на Hugging Face.

„Въвеждаме по-строги изисквания за съгласуваност (alignment) през целия жизнен цикъл на модела и създаваме по-изолирани sandbox среди, ограничаваме достъпа до интернет и допълнително контролираме достъпа до теглата на моделите“, се казва в доклада на OpenAI.

Какво можете да направите:

• Фиксирайте моделите към точна версия и ги проверявайте: Фиксирайте всеки модел към прегледана версия и проверявайте цифровия отпечатък на файла му, преди да го заредите, за да не може подменен файл да се промъкне под същия етикет. OWASP препоръчва и цифрови подписи, с уговорка – подписът доказва откъде идва моделът, а не че е безопасен.
• Проверявайте всеки пакет, който вашият ИИ предлага: Преди да инсталирате пакет с код, препоръчан от ИИ асистент, уверете се, че той съществува, че е пакетът, който сте имали предвид, и че идва от очаквания издател.

5. Защитете се от отравяне на данни и модели

Отровеният ИИ се учи от повредени данни. Това може да са примерите, върху които е дообучен, или база знания, в която търси отговори. Моделът привидно продължава да работи; просто научава грешните уроци, а понякога се научава да се държи неправилно само когато види конкретна фраза спусък.

Моделът ще премине всеки тест, на който го подложите, докато някой не използва тази фраза.

Уголеми

Освен това отравянето е много трудно за отстраняване. То не е програмна грешка, която можете да закърпите. Ако данните ви са грешни, може да се наложи да ги проверите отново, да преобучите модела или изцяло да го замените.

Пример: През октомври 2025 г. изследователи от Anthropic, Института за сигурност на ИИ на Обединеното кралство и Института „Алан Тюринг“ показаха, че 250 отровени документа могат да научат модел да генерира безсмислици всеки път, когато срещне определен спусък. Същият брой сработи и при четирите тествани размера на модела, въпреки че най-големият беше обучен на над 20 пъти повече чисти данни.

Какво можете да направите:

• Следете откъде идват данните ви: Водете запис на всеки набор от данни и модел, който използвате, откъде идва всеки от тях и какво се е променило между версиите. Препоръчваме контрол на версиите за наборите от данни, така че ако се открие отравяне, да можете да се върнете към чиста версия и да установите как е проникнало.
• Тествайте за задни врати: „Задна врата“ е скрито поведение, което нападателят вгражда в модела и което чака определена фраза или друг спусък, за да се активира. Тествайте за тях с входни данни, създадени да накарат модела да наруши обичайните си правила.

6. Сложете таван на неограниченото потребление

Когато ИИ нямат никакви ограничения за това колко работа могат да свършат или колко могат да струват, потреблението им се смята за „неограничено“. Повечето ИИ услуги таксуват според използването, така че нападател може да ви натрупа огромна сметка или да създаде копие на вашия модел.

OWASP нарича основния проблем „асиметрия на разходите“. Кратка и евтина заявка може да задейства скъпи изчисления от ваша страна.

Пример: През май 2024 г. екипът за изследване на заплахи на Sysdig откри нова атака, наречена „LLMjacking“. Група нападатели се насочиха към 10 облачно хоствани LLM услуги, използвайки откраднати идентификационни данни. Те проникнаха през уязвима версия на Laravel, след което установиха какво позволяват идентификационните данни и какви квоти има, с очевидната цел да продават достъпа. Нападателите направиха и множество заявки към настройките за журналиране – вероятно за да избегнат откриване. Според Sysdig в най-лошия случай жертвата може да понесе разходи от над 46 000 долара на ден.

Какво можете да направите:

• Задайте бюджети, които спират разходите: Въведете твърди лимити на разходите за отделни потребители, API ключове, екипи и за акаунта като цяло. Прилагайте ги навсякъде, откъдето могат да постъпват заявки.
• Дайте на всяка задача точка на спиране: Ограничете колко дълго може да се изпълнява задачата, колко текст може да обработи и генерира и колко извиквания на инструменти може да направи. Добавете автоматично прекъсване за агенти, които се повтарят или надхвърлят лимита си.

7. Улавяйте невярната информация, преди да предприемете действия

Когато ИИ генерира нещо невярно, което звучи правдоподобно, и някой – или нещо – действа въз основа на него, това се нарича невярна информация. Основният риск не е толкова самият грешен отговор, колкото това, че на грешния отговор се вярва и той се използва.

Регистрираните инциденти подсказват, че специалистите не са били толкова загрижени за невярната информация, колкото е трябвало. Според встъпителното писмо към изданието за 2026 г. гласуващите са я поставили близо до дъното на списъка, но реалните инциденти я поставят близо до върха.

Пример: През 2025 г. Deloitte Australia представи преглед на ИТ системите за социално подпомагане по държавен договор на стойност 440 000 австралийски долара. Изследователят от Университета в Сидни Крис Ръдж откри препратки към несъществуващи изследвания и измислен цитат от решение на федерален съд. В ревизирания доклад се посочва, че Deloitte е използвала Azure OpenAI GPT-4o в своята методология, а фирмата се съгласи да възстанови последната вноска. За съжаление, ставаше дума именно за преглед, чиято цел е да осигури увереност (assurance review).

Какво можете да направите:

• Проверявайте дали доказателствата подкрепят отговора: Обосновавайте твърденията с актуални, авторитетни източници. За отговор относно политика извлечете одобрената политика и проверете дали тя подкрепя заключението, включително изключенията в нея.
• Проверявайте, преди системата да действа: Ако агент твърди, че клиент е преминал проверка на самоличността, потвърдете това в системата за верификация, преди да освободите плащане. Изисквайте одобрение от човек за решения с последици, като подкрепящите доказателства трябва да са достъпни за проверяващия.

8. Ограничете щетите от разкриването на скрития контекст

ИИ приложенията дават на модела инструкции и фонова информация, които потребителите обикновено не виждат. Това може да включва системния промпт, вътрешни политики, описания на наличните инструменти и правила за това кой може да ги използва. Разкриване на скрития контекст има, когато моделът разкрие тази информация на някого.

През 2026 г. OWASP разшири тази точка от „изтичане на системния промпт“, защото системният промпт е само част от това, което може да изтече. Опасността зависи от това какво сте поставили там. Изтекло ръководство за тона на комуникация е леко неудобно, но изтекъл API ключ дава на някого достъп до вашата поверителна база данни.

Пример: През февруари 2023 г. потребители накараха Bing Chat на Microsoft да разкрие вътрешните си инструкции. Един успешен опит дойде от Марвин фон Хаген, който твърдеше, че е разработчик в OpenAI, и поиска инструкциите, за да може да конфигурира модела. Bing разкри правилата, уреждащи търсенията, отговорите и поведението му по отношение на безопасността, както и вътрешното си име – Sydney. Сред разкритите инструкции имаше и такава, която му нарежда да пази тези инструкции в тайна.

Какво можете да направите:

• Пазете тайните извън контекста на модела: Приемете, че всичко, което моделът може да прочете, може да стане видимо за потребителите – съхранявайте паролите, API ключовете и токените за достъп в отделна система за управление на тайни.
• Направете така, че разрешенията да действат дори при изтичане на правилата: Налагайте проверките за достъп в кода на приложението си. Ако даден инструмент е достъпен само за администратори, проверете разрешенията на акаунта на потребителя, преди да го стартирате.

9. Защитете векторите и ембедингите

Когато ИИ използва векторно търсене, за да намира отговори в документите на вашата компания, той не търси директно в текста. Документите се преобразуват в „ембединги“ – дълги поредици от числа, които улавят смисъла на всеки откъс – и се съхраняват във векторна база данни. Въпросът се преобразува по същия начин, а системата извлича откъсите, чиито числа са най-близо до него.

OWASP обобщава четирите начина, по които тази система може да се провали: отравянето я кара да греши, инверсията – да издава данни, блокирането – да замлъкне, а нарушеният контрол на достъпа – да предоставя всичко на всекиго.

Числата не са толкова безопасна абстракция, колкото изглеждат. Съхранените ембединги могат да бъдат превърнати обратно в текст, като един метод възстанови точно 92% от кратките откъси с дължина 32 токена в тестовете си. Така изтекло резервно копие „само с ембединги“ също може да разкрие съдържанието на документите.

Пример: В проучване, представено на USENIX Security 2025, изследователи показаха, че един внимателно изработен документ може да попречи на ИИ да отговори на конкретен въпрос. Те го добавиха към колекцията, в която ИИ търсеше. Когато ИИ го откриеше, той можеше да заяви, че няма достатъчно информация или че отговорът би бил небезопасен. Документът нямаше нужда да казва на ИИ да игнорира правилата си. Това се нарича „блокиране на извличането“ (retrieval jamming).

Какво можете да направите:

• Поддържайте отделни индекси за публични и частни данни: Не смесвайте съдържание, събрано от уеб, с данни на партньори или поверителни вътрешни документи. Осигурете физическо разделяне по ниво на доверие, вместо да маркирате съдържанието в един индекс – така се елиминира цял клас грешни конфигурации, а съдържание, събрано от интернет, не може да се озове до документите на борда на директорите ви.
• Третирайте ембедингите като документите, от които произлизат: Шифровайте ги, защитавайте резервните копия на векторната база данни така, както и изходните файлове, и изтривайте ембедингите, когато изтривате оригинала. API ключовете за услугата ви за ембединги трябва да се пазят в тайна.

10. Проверявайте изхода на ИИ, преди да го предадете нататък

Когато дадено приложение предава изхода на ИИ на друга система, без да провери дали той е безопасен за използване там, то обработва неправилно изхода на LLM.

Тази категория обхваща и несигурния код, който ИИ асистентите за програмиране генерират в голям мащаб. Следователно всеки ред, написан от асистента, също е изход.

Пример: През 2025 г. изследователят Йохан Ребергер показа как асистентът за програмиране Amp на Sourcegraph може да издаде съдържание от чата само чрез показване на изображение. Той използва инжектиране на подкани (prompt injection), за да накара Amp да включи поверителна информация в уеб адреса на изображение. След това приложението автоматично изтегли това изображение и така изпрати информацията до неговия сървър. Грешката в обработката на изхода беше именно тази автоматична заявка – генерираният от модела текст се превърна във връзка с външен сървър, която пренесе поверителни данни.

Какво можете да направите:

• Направете изхода безопасен за неговата дестинация: Проверявайте и обработвайте отговорите според това къде ще бъдат изпратени. За уеб страница не позволявайте генерираният текст да се превърне в изпълним код. За база данни използвайте подготвени заявки, които държат подадените стойности отделно от командите.
• Не позволявайте на отговорите да създават автоматични външни връзки: По подразбиране изключете автоматичното зареждане на изображения, визуализациите на връзки и вградените страници в отговорите на модела. Ограничете необходимите връзки до изрично одобрени дестинации.

Как Perplexity осигурява сигурността на LLM?

Приемаме, че всеки от рисковете по-горе рано или късно ще се прояви, и проектираме системите си така, че когато това се случи, да не може да нанесе големи щети. Нашият главен директор по информационна сигурност (CISO) Кайл Поли обясни как го правим на скорошен семинар.

• Агентът получава собствен компютър, който в началото е празен: Инструментите за агенти, инсталирани на лаптопа ви, могат да получат достъп до неговите файлове, приложения и запазени идентификационни данни. Perplexity Computer работи по обратния начин. Всяка задача се изпълнява в собствена изолирана среда Sandbox и, както казва Поли, „по подразбиране тя няма достъп до нищо“.
• Агентът никога не вижда паролите: Идентификационните данни за свързаните услуги се съхраняват извън средата Sandbox. Когато агентът трябва да достигне до услуга като GitHub, той изпраща заявка без прикачени идентификационни данни. Шлюз проверява дали дестинацията и заявката са очакваните и едва след това добавя идентификационните данни, докато заявката излиза навън. Агентът може да използва връзката, без да получава ключовете.
• Разрешенията ви се пренасят и можете да ги затегнете: Връзките, осъществени чрез OAuth, запазват разрешенията ви за достъп в свързаната услуга. Ако вие не можете да видите нещо, агентът ви също не може.
• Всяка уеб страница се третира като непозната: Създадохме BrowseSafe за Comet, нашия агентски браузър, защото инструментите, които тествахме, не отговаряха на нуждите ни при реална употреба. Браузърът сканира уеб страниците и друго външно съдържание, включително имейли, за инжектиране на подкани. Публикувахме като отворен код както модела, така и набора от данни.
• Наблюдаваме агента и машините, на които той работи: Numbat стои между решението на агента да предприеме действие и реалното изпълнение на инструмента. Numbat регистрира активността на поддържаните агенти за програмиране и може да блокира действия, нарушаващи конфигурираните политики, преди те да бъдат изпълнени. Bumblebee инвентаризира софтуерните пакети на лаптопи, сървъри и конвейери за компилиране и маркира известните злонамерени пакети. И двата инструмента са с отворен код.
• Доставчиците на модели не съхраняват данните ви: Имаме споразумения за нулево съхранение на данни с нашите външни доставчици на LLM. Администраторите в Enterprise могат също да ограничат срока, за който самият Perplexity съхранява данните, до едва 24 часа.

Създадохме Numbat проактивно – по причина, която Поли обобщава в едно изречение: „Колкото повече автономия давате на един агент, толкова по-голям е рискът.“

Често задавани въпроси за сигурността на LLM

Кой е най-сигурният LLM?

Никой LLM сам по себе си не прави едно приложение сигурно – моделите все още могат да объркат съдържание, което трябва да прочетат, с инструкции, които трябва да изпълнят. Защитите, които изглеждат надеждни в стандартните тестове, също могат да поддадат под натиск.

По-добрият въпрос е коя конфигурация е най-сигурна за вашия сценарий на употреба. Това означава ограничени разрешения, идентификационни данни, държани далеч от модела, одобрение от човек за рисковите действия и тестване от хора, които познават защитите ви.

Какво представляват уязвимостите на LLM?

Уязвимостите на LLM са слабости, които позволяват една система с ИИ да бъде заблудена, да издаде данни или да причини вреди – било то заради нападател, или заради собствените си грешки.

Десетте основни риска са инжектиране на подкани, разкриване на чувствителна информация, прекомерна автономност, рискове във веригата на доставки, отравяне на данни и модели, неограничено потребление, дезинформация, разкриване на скрит контекст, слабости на векторите и ембедингите и неправилна обработка на изхода.

Безопасен ли е частният LLM?

За някои неща е по-безопасен вариант, но не по подразбиране. Имате повече контрол върху обработката на данните, ако изпълнявате модела в собствената си инфраструктура или в облачна среда. Няма автоматичен начин да предотвратите инжектирането на подкани, прекомерната автономност, отравянето или дезинформацията.

Когато хоствате модела сами, вие отговаряте и за модела, който изтегляте, включително за рисковете във веригата на доставки и за инфраструктурата, която той изисква.