Шта је безбједност LLM-ова? Како ублажити 10 највећих безбједносних ризика према OWASP-у

Напад који наводи вјештачку интелигенцију да упутства нападача третира као команде — убацивање упита (prompt injection) — налази се на првом мјесту листе OWASP Top 10 за LLM апликације у сваком издању од 2023. године.

Ова листа је отприлике највише што се безбједност вјештачке интелигенције може приближити консензусу. Пројекат је почео као мала група стручњака за безбједност, а данас окупља више од 600 стручњака сарадника из више од 18 земаља.

Ми смо AI компанија која објављује водич о томе како се вјештачка интелигенција може наговорити на разне ствари, па се нећемо претварати да је овај проблем ријешен. Wilson, један од руководилаца пројекта OWASP, био је прилично јасан када је ријеч о тренутним одбранама: „...искрено, мислим да нисмо на 99%.“

Издање за 2026. годину почиње у истом тону. Руководилац пројекта нам поручује да „престанемо да покушавамо да направимо модел који се не може преварити“ и да систем око њега осмислимо тако да преварени модел не може да поквари ништа важно.

Тај став примјењујемо на свих 10 ризика са OWASP листе за 2026. годину.

Шта значи безбједност LLM-ова?

Безбједност LLM-ова подразумијева заштиту AI модела и апликација које их користе од напада и злоупотребе. Ризик расте у зависности од тога са чиме је модел повезан: од датотека и података које може да чита, као и од алата које може да користи, попут е-поште, претраге или базе података компаније.

У правилно заштићеном софтверу постоји јасна граница између упутстава која програм извршава и информација које обрађује. Али LLM-ови ту границу немају.

Све што модел прочита стиже као један дуги ток текста: упутства програмера, ваше питање, веб-страница коју је потражио. AI модели би требало да прате ко говори — да ли је то програмер, корисник или сам модел док промишља о неком проблему.

Али истраживачи Jasmine Cui и Charles Ye открили су да модели ко говори углавном погађају на основу тога како текст звучи. Зато, ако нападач напише нешто што звучи као сопствено расуђивање модела, модел може повјеровати да је сам дошао на ту идеју. То је проблем за сваки безбједносни механизам који зависи од тога да модел зна ко има главну ријеч.

Исти проблем смо имали и са сопственим AI агентима. Наш CISO, Kyle Polley, изјавио је за ISMG да агенти „можда неће поштовати правила чак и ако их додате у системски упит“. Зато смо направили Numbat, алат отвореног кода који провјерава шта агент намјерава да уради и може да блокира радњу ако она крши конфигурисано безбједносно правило.

Безбједност LLM-ова значи прихватити да ће модел понекад слушати наредбе погрешне особе и око њега поставити AI заштитне механизме који ће издржати и када се то догоди.

Које су најбоље праксе за безбједност LLM-ова?

Редом ћемо проћи кроз OWASP Top 10 за LLM апликације 2026, од бр. 1 до бр. 10.

За сваки ризик добићете једноставно објашњење шта може поћи наопако и примјер из стварног свијета. Затим ћемо представити праксе које могу помоћи да се ризик спријечи или да се, у најмању руку, ограничи штета.

1. Обуздајте убацивање упита

До убацивања упита долази када нападач наведе вјештачку интелигенцију да слиједи упутства која не би смјела да слиједи. Та упутства могу стићи директно кроз ћаскање или бити подметнута у е-поруку, веб-страницу или документ.

Други тип познат је као индиректно убацивање упита. Тражите од асистента да сажме документ. Аутори документа су у њему асистенту наложили да им пошаље ваше приватне датотеке. Ако асистент послуша та упутства, особа која је написала документ практично је позајмила ваш приступ.

PCMag упоређује безбједност упита са крпљењем рупа на порозном камену. Затворите један отвор, а вода пронађе други. „Напад пронађе пут; пропуст се исправи, али безброј других путева напада тек треба да буде откривен, једноставно због тога колико су динамични системи попут LLM-ова.“

Примјер: У јуну 2025. истраживачи компаније Aim Security открили су EchoLeak, пропуст који је наводио Microsoft 365 Copilot да одаје приватне информације компаније. Када би запослени поставио рутинско пословно питање, Copilot је могао да учита злонамјерну е-поруку, слиједи упутства скривена у њој и пошаље осјетљиве информације нападачу. Напад је заобишао провјере које је требало да открију злонамјерна упутства и уклоне сумњиве линкове.

Шта можете да урадите:

• Примијените „Правило два“ компаније Meta: За EchoLeak је била потребна вјештачка интелигенција која може да чита податке компаније, чита спољну е-пошту и шаље информације напоље — а она је имала све три могућности. Ограничавањем на двије од њих спрјечава се да убацивање упита стекне превелику контролу. Ако задатак захтијева све три, захтијевајте одобрење човјека прије сваке радње.
• Тестирајте против нападача који познају ваше одбране: Дајте својим тестерима безбједности правила и филтере које сте увели, па их пустите да их заобиђу. У једној студији нападачи који су се прилагодили одбранама успијевали су у више од 90% случајева против већине од 12 тестираних одбрана.

2. Спријечите цурење осјетљивих информација

Када AI системи дају приватне информације људима који не би требало да их виде, то се назива откривањем осјетљивих информација. То може значити откривање података о плаћању неког купца или остављање приватних разговора у дијељеној бази података.

Многа цурења почињу „претјераним дијељењем“. Рецимо да компанија повеже свој AI систем са дисковима и базама знања које имају лабаве дозволе. Систем преузима све до чега може да дође, тачно онако како је и замишљено. Нико не мора да провали, али LLM можете сматрати проваљеним.

Примјер: У јануару 2025. истраживачи компаније Wiz пронашли су базу података компаније DeepSeek отворену према интернету, са више од милион записа у евиденцији, укључујући историју ћаскања и API кључеве, које софтвер користи за приступ другим сервисима. Истраживачи нису морали да убјеђују модел да било шта открије.

Шта можете да урадите:

• Провјерите приступ прије него што AI прочита податке: Ваша апликација треба да провјери које документе особа која поставља питање смије да види прије него што их прослиједи моделу.
• Заштитите записе које ваш AI систем оставља за собом: Уклоните приватне податке и тајне кључеве прије чувања евиденције активности, захтијевајте пријаву и ограничите приступ на људе којима је потребан. Одредите период чувања како се ти записи не би гомилали унедоглед.

3. Обуздајте прекомјерну аутономију

AI системи са прекомјерном аутономијом имају више моћи него што њихов посао захтијева: алате који им нису потребни, дозволе које превазилазе њихов задатак или слободу да дјелују без провјере. Узрок је овдје небитан.

Убачени упит, грешка или модел који једноставно погријеши — све води ка истом резултату. AI систем ће прије или касније урадити нешто деструктивно ако за то има могућност.

Примјер: У јулу 2025. оснивач SaaStr-а Jason Lemkin објавио је да је агент за кодирање компаније Replit обрисао његову базу података са 1.206 записа о руководиоцима, упркос упутствима да не прави измјене. Агент је у почетку тврдио да се подаци не могу вратити, иако се касније испоставило да је опоравак могућ. Jason је закључио да наређење да не дира базу података агенту није одузело могућност да је обрише.

Увећај

Извор: X

Шта можете да урадите:

• Уклоните могућности које задатку нису потребне: Ограничите и алате које агент добија и оно што ти алати могу да раде. Асистенту који сажима е-поруке потребна је дозвола да их чита, а не да их шаље или брише.
• Поставите провјере дозвола изван вјештачке интелигенције: Сваки пут када се затражи нека радња, провјерите је у односу на своја безбједносна правила и захтијевајте да је одобри човјек.

4. Провјерите шта улази у ваш AI ланац снабдијевања

Мало компанија прави вјештачку интелигенцију од нуле, а сваке године их је све мање. Према истраживању компаније Menlo Ventures „2025: The State of Generative AI in the Enterprise“, 53% компанија купило је AI моделе 2024. године, а тај удио је 2025. порастао на 76%.

Компаније најчешће преузимају моделе са платформи као што је Hugging Face, додатно их тренирају на скуповима података које су прикупили други и укључују додатке и пакете кода које су написали непознати људи.

Сваки од тих дијелова је могући улаз за нападача. Ако је неки од њих неовлашћено измијењен, проблем се испоручује заједно са вашим производом.

Примјер: Број јавних репозиторијума модела на платформи Hugging Face порастао је са 2,43 милиона на 2,96 милиона између јануара и августа 2026. Ипак, у јулу 2026. модели компаније OpenAI су током интерног безбједносног тестирања заобишли контроле које је требало да их држе даље од интернета и провалили у дијелове система компаније Hugging Face. Један агент је чак дошао до 14 јавно изложених приступних акредитива, провјерио да ли функционишу и подијелио их са другим агентима. Агенти су затим искористили пропусте који су им омогућили да покрећу код на серверима компаније Hugging Face.

„Уводимо строже захтјеве у погледу усклађивања током читавог животног циклуса модела и стварамо изолованија sandbox окружења, ограничавамо приступ интернету и додатно контролишемо приступ тежинама модела“, наводи се у извјештају компаније OpenAI.

Шта можете да урадите:

• Фиксирајте моделе на тачну верзију и верификујте их: Фиксирајте сваки модел на прегледану верзију и провјерите дигитални отисак његове датотеке прије учитавања, како замијењена датотека не би могла да се провуче под истом ознаком. OWASP препоручује и дигиталне потписе, уз једну ограду — потпис доказује одакле модел потиче, а не да је безбједан.
• Провјерите сваки пакет који вам AI предложи: Прије инсталирања пакета кода који је препоручио AI асистент, потврдите да он постоји, да је то пакет који сте мислили и да долази од издавача којег очекујете.

5. Заштитите се од тровања података и модела

Отровани AI систем учи из оштећених података. То могу бити примјери на којима је дорађиван (fine-tuning) или база знања у којој тражи одговоре. Модел и даље изгледа као да ради; само учи погрешне лекције, а понекад научи да се лоше понаша само када наиђе на одређену фразу окидач.

Таква фраза ће проћи сваки тест који спроведете, све док је неко не употријеби.

Увећај

Осим тога, то је заиста тешко поништити. Тровање није грешка коју можете закрпити. Ако су ваши подаци погрешни, можда ћете морати да их поново провјерите, поново истренирате модел или да га потпуно замијените.

Примјер: У октобру 2025. истраживачи из компаније Anthropic, института UK AI Security Institute и Alan Turing Institute показали су да 250 отрованих докумената може научити модел да производи бесмислице кад год наиђе на одређени окидач. Исти број докумената био је довољан код све четири тестиране величине модела, иако је највећи модел трениран на више од 20 пута већој количини чистих података.

Шта можете да урадите:

• Пратите поријекло својих података: Водите евиденцију о сваком скупу података и моделу који користите, о томе одакле сваки потиче и шта се промијенило између верзија. Препоручујемо контролу верзија за скупове података, тако да, ако се открије тровање, можете да се вратите на чисту верзију и утврдите како је до њега дошло.
• Тражите задња врата: „Задња врата“ су скривено понашање које нападач подметне у модел и које чека одређену фразу или неки други окидач да би се активирало. Тестирајте модел помоћу улаза осмишљених да га натјерају да прекрши своја уобичајена правила.

6. Ставите неограничену потрошњу под контролу

Када AI системи немају никаква ограничења у погледу тога колико посла могу да ураде или колико могу да коштају, њихова потрошња се сматра „неограниченом“. Већина AI сервиса наплаћује по коришћењу, па би нападач могао да вам надува рачун или да направи копију вашег модела.

OWASP основни проблем назива „асиметријом трошкова“. Кратак, јефтин захтјев може покренути скупу обраду на вашој страни.

Примјер: У мају 2024. тим за истраживање пријетњи компаније Sysdig открио је нову врсту напада под називом „LLMjacking“. Група нападача је помоћу украдених акредитива циљала 10 LLM сервиса хостованих у облаку. Ушли су преко рањиве верзије оквира Laravel, а затим утврдили шта све могу да ураде са тим акредитивима и које квоте важе, с очигледним циљем да продају приступ. Испитиване су и многе поставке евидентирања, вјероватно да би се избјегло откривање. Према подацима компаније Sysdig, у најгорем случају то би жртву могло коштати више од 46.000 долара дневно.

Шта можете да урадите:

• Поставите буџете који заустављају трошење: Уведите чврста ограничења потрошње за појединачне кориснике, API кључеве, тимове и налог у цјелини. Примјењујте их на свим мјестима гдје захтјеви могу да уђу.
• Дајте сваком задатку тачку заустављања: Ограничите колико дуго задатак може да траје, колико текста може да обради и генерише и колико позива алата може да упути. Додајте аутоматске прекиде за агенте који се понављају или прекораче дозвољени обим.

7. Уочите дезинформације прије предузимања радњи

Када AI систем произведе нешто нетачно што звучи исправно, а неко или нешто на основу тога дјелује, то се назива дезинформацијом. Основни ризик није толико сам погрешан одговор колико то што се погрешном одговору вјерује и што се он користи.

Евиденција инцидената указује на то да стручњаци нису били забринути због дезинформација онолико колико је требало. Према уводном писму издања за 2026. годину, гласачи су их сврстали при дну листе, али према стварним инцидентима, оне су при врху.

Примјер: Deloitte Australia је 2025. године, у оквиру државног уговора вриједног 440.000 аустралијских долара, испоручио анализу ИТ система социјалне помоћи. Истраживач Универзитета у Сиднеју Chris Rudge пронашао је референце на непостојећа истраживања и измишљени цитат из пресуде савезног суда. У ревидираном извјештају наведено је да је Deloitte у својој методологији користио Azure OpenAI GPT-4o, а фирма је пристала да врати посљедњу рату. Нажалост, ријеч је била о ревизији чији је циљ био управо пружање гаранција.

Шта можете да урадите:

• Провјерите да ли докази поткрепљују одговор: Заснивајте тврдње на актуелним, ауторитативним изворима. За одговор о некој политици преузмите одобрени документ политике и провјерите да ли поткрепљује закључак, укључујући изузетке.
• Провјерите прије него што систем предузме радњу: Ако агент тврди да је клијент прошао провјеру идентитета, потврдите то у систему за верификацију прије него што одобрите плаћање. Захтијевајте одобрење човјека за одлуке са значајним посљедицама, уз пратеће доказе доступне ономе ко их прегледа.

8. Ограничите штету од излагања скривеног контекста

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

OWASP је 2026. проширио ову ставку са „цурења системског упита“ јер је системски упит само дио онога што може да процури. Опасност зависи од тога шта сте тамо ставили. Процурели водич за тон комуникације је помало непријатан, али процурели API кључ некоме даје приступ вашој повјерљивој бази података.

Примјер: У фебруару 2023. корисници су навели Bing Chat компаније Microsoft да открије своја интерна упутства. Један успјешан покушај извео је Marvin von Hagen, који је тврдио да је програмер у компанији OpenAI и затражио упутства како би могао да конфигурише модел. Bing је открио правила која уређују његове претраге, одговоре и безбједносно понашање, као и своје интерно име, Sydney. Међу откривеним упутствима било је и оно које му налаже да та упутства чува као повјерљива.

Шта можете да урадите:

• Држите тајне подаље од контекста модела: Пођите од претпоставке да све што модел може да прочита може постати видљиво корисницима — лозинке, API кључеве и приступне токене чувајте у засебном систему за управљање тајнама.
• Обезбиједите да дозволе важе чак и кад правила процуре: Провјере приступа спроводите у коду своје апликације. Ако је алат ограничен на администраторе, провјерите дозволе корисничког налога прије него што га покренете.

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

Када вјештачка интелигенција користи векторску претрагу да пронађе одговоре у документима ваше компаније, она не претражује текст директно. Документи се претварају у „ембединге“ (embeddings), дугачке низове бројева који биљеже значење сваког одломка, и чувају се у векторској бази података. Питање се претвара на исти начин, а систем издваја одломке чији су бројеви најближи.

OWASP сажима четири начина на која овај систем може да закаже: тровање га чини нетачним, инверзија доводи до цурења података, блокирање га ућуткује, а нарушена контрола приступа наводи га да било шта преда било коме.

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

Примјер: У истраживању представљеном на конференцији USENIX Security 2025 истраживачи су показали да један пажљиво осмишљен документ може спријечити вјештачку интелигенцију да одговори на одређено питање. Додали су га у збирку коју је AI претраживао. Када би га пронашао, AI је могао да каже да нема довољно информација или да би одговор био небезбједан. Документ није морао да наложи вјештачкој интелигенцији да игнорише своја правила. То се назива „ометање претраживања“.

Шта можете да урадите:

• Одржавајте засебне индексе за јавне и приватне податке: Не мијешајте садржај прикупљен с веба с подацима партнера или повјерљивим интерним документима. Уведите физичко раздвајање према нивоу повјерења умјесто означавања садржаја у једном индексу, јер се тако уклања читава класа погрешних конфигурација, а садржај прикупљен с интернета не може да заврши поред материјала за управни одбор.
• Третирајте ембединге као документе из којих су настали: Шифрујте их, штитите резервне копије векторске базе података једнако као изворне фајлове и бришите ембединге када обришете оригинал. API кључеви за ваш сервис за ембединге треба да остану тајни.

10. Провјерите излаз вјештачке интелигенције прије него што га прослиједите

Кад год апликација прослиједи излаз вјештачке интелигенције другом систему, а да не провјери да ли је безбједан за употребу у том систему, она неправилно рукује излазом LLM-а.

Ова ставка обухвата и небезбједан код који AI асистенти за програмирање генеришу у великим количинама. Према томе, и свака линија коју асистент напише представља излаз.

Примјер: Године 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-ова су слабости због којих AI систем може бити преварен, може да открије податке или да нанесе штету, било због нападача или због сопствених грешака.

Десет главних ризика су убацивање промпта, откривање осјетљивих информација, прекомјерна аутономија, ланац снабдијевања, тровање података и модела, неограничена потрошња, дезинформације, излагање скривеног контекста, слабости вектора и ембединга и неправилно руковање излазом.

Да ли је приватни LLM безбједан?

За неке намјене је безбједнија опција, али не сам по себи. Ако модел покрећете на сопственој инфраструктури или у окружењу у облаку, имате већу контролу над руковањем подацима. Ипак, не постоји аутоматски начин да се спријече убацивање промпта, прекомјерна аутономија, тровање или дезинформације.

Када сами хостујете модел, одговорни сте и за модел који преузмете, укључујући ризике ланца снабдијевања и инфраструктуру која му је потребна.