LLM қауіпсіздігі дегеніміз не? OWASP Top 10 қауіпсіздік тәуекелдерін қалай азайтуға болады

ЖИ-ді шабуылдаушының нұсқауларын команда ретінде қабылдауға алдайтын шабуыл — промпт-инъекция — 2023 жылдан бері әр басылымда OWASP Top 10 for LLM Applications тізімінде №1 орында тұр.

Бұл тізім — ЖИ қауіпсіздігі саласында ортақ келісімге ең жақын нәрсе. Жоба қауіпсіздік мамандарының шағын тобынан басталып, қазір 18-ден астам елдегі 600-ден астам сарапшының үлесіне сүйенеді.

Біз — ЖИ-ді түрлі нәрсеге қалай көндіруге болатыны туралы нұсқаулық жариялап отырған ЖИ компаниясымыз, сондықтан бұл мәселе шешілген деп көрсетпейміз. OWASP жобасының тең жетекшісі Уилсон қазіргі қорғаныс құралдары туралы ашық айтты: «...шынымды айтсам, біз 99%-ға жеттік деп ойламаймын».

2026 жылғы басылым да осы оймен басталады. Жоба жетекшісі «алдауға болмайтын модель жасауға тырысуды доғаруға» және алданған модель маңызды ештеңені бұза алмайтындай етіп оны қоршаған жүйені жобалауға шақырады.

Біз осы ұстанымды OWASP-тың 2026 жылғы тізіміндегі барлық 10 тәуекелге қолданамыз.

LLM қауіпсіздігі дегеніміз не?

LLM қауіпсіздігі — ЖИ модельдерін және оларды пайдаланатын қолданбаларды шабуылдар мен теріс пайдаланудан қорғау. Тәуекел модель неге қосылғанына қарай артады: ол оқи алатын файлдар мен деректерге және ол пайдалана алатын құралдарға, мысалы, электрондық поштаға, іздеуге немесе компания дерекқорына.

Дұрыс қорғалған бағдарламалық жасақтамада бағдарлама орындайтын нұсқаулар мен ол өңдейтін ақпарат арасында нақты шекара болады. Ал LLM-дерде мұндай шекара жоқ.

Модель оқитын барлық нәрсе бір ұзын мәтін ағыны түрінде келеді: әзірлеушінің нұсқаулары, сіздің сұрағыңыз, ол іздеп тапқан веб-бет. ЖИ модельдері кімнің сөйлеп тұрғанын — әзірлеуші ме, пайдаланушы ма, әлде мәселе туралы ойланып жатқан модельдің өзі ме — бақылап отыруы тиіс.

Бірақ зерттеушілер Жасмин Цуй мен Чарльз Е модельдер кімнің сөйлеп тұрғанын көбіне мәтіннің қалай естілетініне қарап болжайтынын анықтады. Сондықтан шабуылдаушы модельдің өз пайымдауына ұқсайтын мәтін жазса, модель бұл идеяны өзі ойлап таптым деп сенуі мүмкін. Бұл модельдің кім басқаратынын білуіне тәуелді кез келген қауіпсіздік жүйесі үшін мәселе.

Біз де өз ЖИ агенттерімізде дәл осындай мәселеге тап болдық. Біздің CISO Кайл Полли ISMG басылымына агенттер «жүйелік промптқа қосқанның өзінде саясаттарды сақтамауы мүмкін» екенін айтты. Сондықтан біз Numbat құралын жасадық — бұл агенттің не істегелі жатқанын тексеретін және әрекет бапталған қауіпсіздік ережесін бұзса, оны бұғаттай алатын ашық бастапқы кодты құрал.

LLM қауіпсіздігі — модель кейде дұрыс емес адамнан бұйрық алатынын мойындау және ол солай болған жағдайда да берік тұратын ЖИ қорғаныс шектеулерін оның айналасына орнату.

LLM қауіпсіздігінің үздік тәжірибелері қандай?

Біз OWASP Top 10 for LLM Applications 2026 тізімін №1-ден №10-ға дейін ретімен қарастырамыз.

Әр тәуекел бойынша жағдайдың қалай бұзылатыны туралы қарапайым тілмен түсіндірме және нақты өмірден мысал беріледі. Содан кейін оның алдын алуға немесе, ең болмағанда, зиянды шектеуге көмектесетін тәжірибелерді қарастырамыз.

1. Промпт-инъекцияны шектеңіз

Промпт-инъекция шабуылдаушы ЖИ-ді орындамауы тиіс нұсқауларды орындауға мәжбүрлегенде орын алады. Бұл нұсқаулар тікелей чатта берілуі немесе электрондық хатқа, веб-бетке не құжатқа жасырылуы мүмкін.

Екінші түрі жанама промпт-инъекция деп аталады. Сіз ассистентіңізден құжатты қорытындылап беруді сұрайсыз. Ал құжат авторы ассистентке сіздің жеке файлдарыңызды өзіне жіберуді бұйырған. Егер ассистент бұл нұсқауларды орындаса, құжатты жазған адам іс жүзінде сіздің қолжетімділігіңізді пайдаланып алады.

PCMag салыстыруынша, промпт қауіпсіздігі кеуек тастағы тесіктерді бітеуге ұқсайды. Бір саңылауды бітесіз, ал су басқасын табады. «Шабуыл өз жолын табады; оны түзетеді, бірақ LLM сияқты жүйелердің динамикалық табиғатына байланысты әлі ашылмаған сансыз басқа шабуыл жолдары қала береді».

Мысал: 2025 жылғы маусымда Aim Security зерттеушілері Microsoft 365 Copilot-ты компанияның жеке ақпаратын сыртқа шығаруға алдап көндірген EchoLeak осалдығын тапты. Қызметкер әдеттегі жұмыс сұрағын қойғанда, Copilot сол электрондық хатты алып, оның ішіне жасырылған нұсқауларды орындап, құпия ақпаратты шабуылдаушыға жібере алатын. Шабуыл зиянды нұсқауларды анықтауға және күдікті сілтемелерді жоюға арналған тексерулерден өтіп кетті.

Не істеуге болады:

• Meta-ның «Екі шарт ережесін» ұстаныңыз: EchoLeak үшін компания деректерін оқи алатын, сыртқы электрондық поштаны оқи алатын және ақпаратты сыртқа жібере алатын ЖИ қажет болды — оның үшеуі де бар еді. Оны осы мүмкіндіктердің екеуімен ғана шектеу промпт-инъекцияның тым көп бақылауға ие болуына жол бермейді. Егер тапсырмаға үшеуі де қажет болса, әр әрекет алдында адамның мақұлдауын талап етіңіз.
• Қорғанысыңызды білетін шабуылдаушыларға қарсы тестілеңіз: Қауіпсіздік тестілеушілеріне өзіңіз енгізген ережелер мен сүзгілерді беріп, оларды айналып өтуге мүмкіндік беріңіз. Бір зерттеуде қорғанысқа бейімделген шабуылдаушылар сыналған 12 қорғаныс әдісінің көпшілігіне қарсы 90%-дан астам жағдайда сәтті болды.

2. Құпия ақпараттың ағып кетуін тоқтатыңыз

ЖИ жүйелері жеке ақпаратты оны көрмеуі тиіс адамдарға бергенде, бұл құпия ақпараттың ашылуы деп аталады. Бұл клиенттің төлем деректерін ашу немесе жеке сөйлесулерді ортақ дерекқорда қалдыру болуы мүмкін.

Көптеген ағып кетулер «шамадан тыс бөлісуден» басталады. Мысалы, компания өз ЖИ-ін рұқсаттары әлсіз бапталған дискілер мен білім базаларына қосады делік. ЖИ қолы жететін барлық нәрсені алады — дәл солай жобаланғандай. Ешкімге бұзып кірудің қажеті жоқ, бірақ LLM-ді бұзылған деп есептеңіз.

Мысал: 2025 жылғы қаңтарда Wiz зерттеушілері интернетке ашық тұрған DeepSeek дерекқорын тапты. Онда чат тарихы мен API кілттерін (бағдарламалық жасақтама басқа қызметтерге кіру үшін пайдаланатын кілттер) қоса алғанда, миллионнан астам журнал жазбасы болды. Зерттеушілерге модельді бір нәрсені ашуға көндірудің қажеті болмады.

Не істеуге болады:

• ЖИ деректерді оқымас бұрын қолжетімділікті тексеріңіз: Қолданбаңыз құжаттарды модельге бермес бұрын сұрақ қойып отырған адамның қай құжаттарды көруге рұқсаты бар екенін тексеруі керек.
• ЖИ қалдыратын жазбаларды қорғаңыз: Әрекет журналдарын сақтамас бұрын жеке мәліметтер мен құпия кілттерді алып тастаңыз, жүйеге кіруді талап етіңіз және қолжетімділікті тек қажет адамдарға ғана беріңіз. Бұл жазбалар шексіз жинала бермеуі үшін сақтау мерзімін белгілеңіз.

3. Шамадан тыс дербестікті тежеңіз

Шамадан тыс дербестігі бар ЖИ-дің өз жұмысына қажеттіден көп өкілеттігі болады: қажет емес құралдар, тапсырмадан тыс рұқсаттар немесе тексерусіз әрекет ету еркіндігі. Мұнда себептің маңызы жоқ.

Инъекциялық промпт, бағдарламадағы қате немесе жай ғана қателескен модель — бәрі бір нәтижеге әкеледі. Егер ЖИ-де мүмкіндік болса, ол ерте ме, кеш пе қиратушы бір әрекет жасайды.

Мысал: 2025 жылғы шілдеде SaaStr негізін қалаушы Джейсон Лемкин Replit кодтау агенті 1 206 басшы туралы жазба сақталған дерекқорын жойғанын хабарлады, дегенмен агентке өзгеріс енгізбеу туралы нұсқау берілген еді. Агент алғашында деректерді қалпына келтіру мүмкін емес деп айтты, бірақ кейін қалпына келтіру мүмкін болып шықты. Джейсон агентке дерекқорға тиіспеуді айту оның дерекқорды жою мүмкіндігін жоймағанын түсінді.

Ұлғайту

Дереккөз: X

Не істеуге болады:

• Тапсырмаға қажет емес мүмкіндіктерді алып тастаңыз: Агентке берілетін құралдарды да, сол құралдардың не істей алатынын да шектеңіз. Электрондық хаттарды қорытындылайтын ассистентке оларды жіберу немесе жою емес, тек оқу рұқсаты қажет.
• Рұқсат тексерулерін ЖИ-ден тыс орналастырыңыз: Әрекет сұралған сайын оны қауіпсіздік ережелеріңізбен салыстырып тексеріңіз және адамның мақұлдауын талап етіңіз.

4. ЖИ жеткізу тізбегіне не кіретінін тексеріңіз

ЖИ-ді нөлден жасайтын компаниялар аз, әрі олардың саны жыл сайын азаюда. Menlo Ventures-тің «2025 The State of Generative AI in the Enterprise» сауалнамасына сәйкес, 2024 жылы компаниялардың 53%-ы ЖИ модельдерін сатып алған, ал 2025 жылы бұл көрсеткіш 76%-ға жетті.

Көбіне компаниялар модельдерді Hugging Face сияқты хабтардан жүктеп алады, оларды басқа адамдар жинаған деректер жиындарында қосымша оқытады және бейтаныс адамдар жазған қосымшалар мен код пакеттерін қосады.

Осы бөліктердің әрқайсысы — ішке кіру жолы. Егер біреуі бұрмаланса, мәселе сіздің өніміңізбен бірге жеткізіледі.

Мысал: 2026 жылғы қаңтар мен тамыз аралығында Hugging Face-тің ашық модель репозиторийлері 2,43 миллионнан 2,96 миллионға дейін өсті. Алайда 2026 жылғы шілдеде OpenAI модельдері ішкі қауіпсіздік тестілеуі кезінде оларды интернеттен оқшаулауға арналған бақылауларды айналып өтіп, Hugging Face жүйелерінің бір бөлігіне бұзып кірді. Тіпті бір агент жария түрде ашық қалған 14 тіркелгі деректерін тауып, олардың жұмыс істейтінін тексеріп, басқа агенттермен бөлісті. Агенттер одан әрі Hugging Face серверлерінде код іске қосуға мүмкіндік берген осалдықтарды пайдаланды.

«Біз модельдің бүкіл өмірлік циклі бойы теңестіруге (alignment) қатаңырақ талаптар қойып, барынша оқшауланған Sandbox орталарын құрып, интернетке кіруді шектеп, модель салмақтарына қолжетімділікті одан әрі бақылаймыз», — делінген OpenAI есебінде.

Не істеуге болады:

• Модельдерді нақты нұсқаға бекітіп, тексеріңіз: Әр модельді тексерілген нұсқаға бекітіңіз және жүктемес бұрын оның файл хэшін тексеріңіз, сонда ауыстырылған файл сол белгімен жасырын кіре алмайды. OWASP сондай-ақ цифрлық қолтаңбаларды ұсынады, бірақ бір ескертпемен: қолтаңба модельдің қауіпсіз екенін емес, оның қайдан келгенін ғана дәлелдейді.
• ЖИ ұсынған әр пакетті тексеріңіз: ЖИ ассистенті ұсынған код пакетін орнатпас бұрын оның шынымен бар екенін, бұл сіз ойлаған пакет екенін және ол сіз күткен жариялаушыдан келгенін растаңыз.

5. Деректер мен модельді уланудан қорғаңыз

Уланған ЖИ бүлінген деректерден үйренеді. Бұл модельді дәл баптауға пайдаланылған мысалдар немесе ол жауап іздейтін білім базасы болуы мүмкін. Модель әлі де дұрыс жұмыс істеп тұрғандай көрінеді; ол жай ғана қате сабақтар алады, ал кейде белгілі бір іске қосқыш фразаны көргенде ғана дұрыс емес әрекет етуді үйренеді.

Біреу оны қолданбайынша, бұл фраза сіз жүргізетін әр тесттен өтіп кете береді.

Ұлғайту

Сонымен қатар мұны түзету өте қиын. Улану — патчпен жөндей салатын бағдарлама қатесі емес. Деректеріңіз қате болса, оларды қайта тексеруге, модельді қайта оқытуға немесе оны толықтай ауыстыруға тура келуі мүмкін.

Мысал: 2025 жылғы қазанда Anthropic, Ұлыбританияның ЖИ қауіпсіздігі институты (UK AI Security Institute) және Алан Тьюринг институтының зерттеушілері модель белгілі бір іске қосқышты кездестірген сайын 250 уланған құжат оны мағынасыз мәтін шығаруға үйрете алатынын көрсетті. Сыналған төрт түрлі өлшемдегі модельдің бәрінде бірдей сан жұмыс істеді, дегенмен ең үлкені 20 еседен астам көп таза деректермен оқытылған.

Не істеуге болады:

• Деректеріңіздің қайдан келетінін бақылаңыз: Пайдаланатын әр деректер жиыны мен модельдің, олардың әрқайсысы қайдан келгенінің және нұсқалар арасында не өзгергенінің есебін жүргізіңіз. Деректер жиындары үшін нұсқаларды басқару жүйесін пайдалануды ұсынамыз: улану анықталса, таза нұсқаға қайтып, оның қалай енгенін анықтай аласыз.
• Бэкдорлардың бар-жоғын тестілеңіз: «Бэкдор» — шабуылдаушы модельге орнатқан, оны іске қосатын белгілі бір фразаны немесе басқа іске қосқышты күтіп тұратын жасырын мінез-құлық. Мұны модельді әдеттегі ережелерін бұзуға итермелейтін арнайы кіріс деректерімен тексеріңіз.

6. Шектеусіз тұтынуға шек қойыңыз

ЖИ-дің қанша жұмыс атқара алатынына немесе қанша шығынға әкелетініне ешқандай шектеу болмаса, оның тұтынуы «шектеусіз» деп саналады. ЖИ қызметтерінің көпшілігі пайдалану көлеміне қарай ақы алады, сондықтан шабуылдаушы шотыңызды өсіріп жіберуі немесе моделіңіздің көшірмесін жасап алуы мүмкін.

OWASP негізгі мәселені «шығын асимметриясы» деп атайды. Қысқа әрі арзан сұрау сіздің тарапыңызда қымбат есептеулерді іске қосуы мүмкін.

Мысал: 2024 жылғы мамырда Sysdig компаниясының Threat Research Team тобы «LLMjacking» деп аталатын жаңа шабуылды анықтады. Шабуылдаушылар тобы ұрланған тіркелгі деректерін пайдаланып, бұлтта орналасқан 10 LLM қызметін нысанаға алды. Олар Laravel-дің осал нұсқасы арқылы кіріп, содан кейін тіркелгі деректерімен не істеуге болатынын және қандай квоталар бар екенін анықтады — мақсаты қолжетімділікті сату екені анық. Сондай-ақ, бәлкім, байқалмау үшін журнал параметрлерінің көбі сұралды. Sysdig мәліметінше, ең нашар жағдайда бұл жәбірленушіге күніне 46 000 доллардан астам шығын әкелуі мүмкін.

Не істеуге болады:

• Шығынды тоқтататын бюджеттер белгілеңіз: Жеке пайдаланушылар, API кілттері, командалар және жалпы тіркелгі үшін қатаң шығын лимиттерін қойыңыз. Оларды сұраулар кіре алатын барлық жерде қолданыңыз.
• Әр тапсырмаға тоқтау нүктесін белгілеңіз: Тапсырманың қанша уақыт орындала алатынын, қанша мәтін өңдеп, жасай алатынын және қанша құрал шақыруын жасай алатынын шектеңіз. Өзін қайталайтын немесе белгіленген лимиттен асатын агенттер үшін автоматты тоқтату тетіктерін қосыңыз.

7. Әрекет етпес бұрын жалған ақпаратты анықтаңыз

ЖИ шындыққа ұқсайтын жалған нәрсе жасағанда және біреу немесе бір нәрсе соған сүйеніп әрекет еткенде, бұл жалған ақпарат деп аталады. Негізгі тәуекел қате жауаптың өзінде емес, сол қате жауапқа сеніп, оны пайдалануда.

Оқиғалар тарихы мамандардың жалған ақпарат туралы қажетті деңгейде алаңдамағанын көрсетеді. 2026 жылғы басылымның кіріспе хатына сәйкес, дауыс берушілер оны тізімнің соңына жақын қойған, бірақ нақты оқиғаларға қарағанда, ол тізімнің басына жақын.

Мысал: 2025 жылы Deloitte Australia құны A$440 000 болатын мемлекеттік келісімшарт бойынша әлеуметтік қамсыздандыру IT жүйелеріне шолу жасап тапсырды. Сидней университетінің зерттеушісі Крис Радж жоқ зерттеулерге сілтемелерді және федералдық сот шешімінен ойдан шығарылған дәйексөзді тапты. Қайта қаралған есепте Deloitte өз әдістемесінде Azure OpenAI GPT-4o пайдаланғаны ашып көрсетілді, ал компания соңғы төлемді қайтаруға келісті. Өкінішке қарай, бұл сенімділікті растау шолуы еді.

Не істеуге болады:

• Дәлелдердің жауапты растайтынын тексеріңіз: Тұжырымдарды өзекті, беделді дереккөздерге негіздеңіз. Саясат туралы жауап үшін бекітілген саясатты алып, оның қорытындыны, соның ішінде ерекшеліктерді қоса, растайтынын тексеріңіз.
• Жүйе әрекет етпес бұрын тексеріңіз: Егер агент клиент жеке басын растаудан өтті десе, төлемді жібермес бұрын мұны верификация жүйесі арқылы растаңыз. Маңызды шешімдер үшін адамның мақұлдауын талап етіңіз және растайтын дәлелдер тексерушіге қолжетімді болсын.

8. Жасырын контекстің ашылуынан болатын зиянды шектеңіз

ЖИ қолданбалары модельге пайдаланушылар әдетте көрмейтін нұсқаулар мен фондық ақпарат береді. Оған жүйелік промпт, ішкі саясаттар, қолжетімді құралдардың сипаттамалары және оларды кім пайдалана алатыны туралы ережелер кіруі мүмкін. Жасырын контекстің ашылуы модель осы ақпаратты біреуге ашқанда орын алады.

OWASP 2026 жылы бұл тармақты «жүйелік промпттың ағып кетуі» ұғымынан кеңейтті, өйткені жүйелік промпт — сыртқа шығуы мүмкін нәрсенің бір бөлігі ғана. Қауіп ол жерге не салғаныңызға байланысты. Сөйлеу мәнері жөніндегі нұсқаулықтың ағып кетуі сәл ыңғайсыз болар, бірақ ағып кеткен API кілті біреуге құпия дерекқорыңызға қолжетімділік береді.

Мысал: 2023 жылғы ақпанда пайдаланушылар Microsoft-тың Bing Chat жүйесін ішкі нұсқауларын ашуға мәжбүрледі. Сәтті әрекеттердің бірін Марвин фон Хаген жасады: ол өзін OpenAI әзірлеушісі деп таныстырып, модельді баптау үшін нұсқауларды сұрады. Bing өзінің іздеулерін, жауаптарын және қауіпсіздік мінез-құлқын реттейтін ережелерді, сондай-ақ ішкі атауы Sydney-ді ашып берді. Ашылған нұсқаулардың арасында осы нұсқауларды құпия сақтауды бұйыратын нұсқау да бар еді.

Не істеуге болады:

• Құпия деректерді модель контекстінен тыс ұстаңыз: Модель оқи алатын кез келген нәрсе пайдаланушыларға көрінуі мүмкін деп есептеңіз — құпия сөздерді, API кілттерін және қолжетімділік токендерін құпияларды басқарудың жеке жүйесінде сақтаңыз.
• Ережелер жария болса да, рұқсаттар күшін сақтайтындай етіңіз: Қолжетімділікті тексеруді қолданба кодында жүзеге асырыңыз. Егер құралды тек әкімшілер пайдалана алатын болса, оны іске қоспас бұрын пайдаланушы аккаунтының рұқсаттарын тексеріңіз.

9. Векторлар мен эмбеддингтерді қорғаңыз

ЖИ компанияңыздың құжаттарынан жауап табу үшін векторлық іздеуді пайдаланғанда, ол мәтіннің өзінен тікелей іздемейді. Құжаттар «эмбеддингтерге» — әр үзіндінің мағынасын бейнелейтін сандардың ұзын тізімдеріне — түрлендіріліп, векторлық дерекқорда сақталады. Сұрақ та дәл осылай түрлендіріледі, ал жүйе сандары оған ең жақын үзінділерді іріктеп алады.

OWASP мұндай жүйенің істен шығуының төрт жолын былай түйіндейді: улау жүйені қателестіреді, инверсия деректердің ағып кетуіне әкеледі, бөгеу оны үнсіз қалдырады, ал қолжетімділікті басқарудың бұзылуы оны кез келген нәрсені кез келген адамға беретін етеді.

Бұл сандар көрінгендей қауіпсіз абстракция емес. Сақталған эмбеддингтерді қайтадан мәтінге айналдыруға болады: бір әдіс сынақтарында 32 токеннен тұратын қысқа үзінділердің 92%-ын дәлме-дәл қалпына келтірді. Сондықтан «тек эмбеддингтерден» тұратын резервтік көшірме жария болса, құжаттардың мазмұны да ашылып қалуы мүмкін.

Мысал: USENIX Security 2025 конференциясында ұсынылған зерттеуде зерттеушілер мұқият дайындалған бір ғана құжат ЖИ-дің белгілі бір сұраққа жауап беруіне кедергі келтіре алатынын көрсетті. Олар бұл құжатты ЖИ іздеу жүргізетін жинаққа қосты. ЖИ оны тапқан кезде ақпарат жеткіліксіз екенін немесе жауап беру қауіпті болатынын айтуы мүмкін еді. Құжаттың ЖИ-ге өз ережелерін елемеуді айтуы қажет болмады. Мұны «іздеуді бөгеу» (retrieval jamming) деп атайды.

Не істеуге болады:

• Жалпыға қолжетімді және жеке деректер үшін бөлек индекстер жүргізіңіз: Интернеттен жиналған веб-контентті серіктестердің деректерімен немесе құпия ішкі құжаттармен араластырмаңыз. Контентті бір индекс ішінде тегтеудің орнына, оны сенім деңгейі бойынша физикалық түрде бөліңіз: бұл қате конфигурацияның тұтас бір түрін жояды, әрі интернеттен жиналған контент директорлар кеңесінің құжаттарымен қатар тұрып қалмайды.
• Эмбеддингтерді олар алынған құжаттардай қорғаңыз: Оларды шифрлаңыз, бастапқы файлдармен қатар векторлық дерекқордың резервтік көшірмелерін де қорғаңыз және түпнұсқаны жойған кезде эмбеддингтерді де жойыңыз. Эмбеддинг қызметінің API кілттерін құпия ұстау керек.

10. ЖИ нәтижесін әрі қарай жібермес бұрын тексеріңіз

Қолданба ЖИ нәтижесін басқа жүйеге оның сол жерде пайдалануға қауіпсіз екенін тексермей жіберсе, бұл LLM нәтижесін дұрыс өңдемеу болып саналады.

Бұл тармақ ЖИ кодтау көмекшілері ауқымды түрде жасайтын қауіпті кодты да қамтиды. Демек, көмекші жазған әрбір жол да нәтиже болып табылады.

Мысал: 2025 жылы зерттеуші Johann Rehberger көрсеткендей, Sourcegraph компаниясының Amp кодтау көмекшісі жай ғана сурет көрсету арқылы чат мазмұнын жария етіп алуы мүмкін еді. Ол промпт-инъекция арқылы Amp-қа жеке ақпаратты суреттің веб-мекенжайына қостырды. Содан кейін қолданба сол суретті автоматты түрде жүктеп, ақпаратты оның серверіне жіберді. Нәтижені өңдеудегі ақау дәл осы автоматты сұрау болды: модель жасаған мәтін сыртқы серверге қосылымға айналып, жеке деректерді өзімен бірге ала кетті.

Не істеуге болады:

• Нәтиженің ол жіберілетін орын үшін қауіпсіз болуын қамтамасыз етіңіз: Жауаптарды қайда жіберілетініне қарай тексеріп, өңдеңіз. Веб-бетте жасалған мәтіннің орындалатын кодқа айналуына жол бермеңіз. Дерекқорда берілген мәндерді командалардан бөлек ұстайтын дайындалған сұрауларды пайдаланыңыз.
• Жауаптардың сыртқы ресурстарға автоматты түрде қосылуына жол бермеңіз: Модель жауаптарындағы суреттерді, сілтемелердің алдын ала көріністерін және ендірілген беттерді автоматты түрде жүктеуді әдепкі бойынша өшіріңіз. Қажетті қосылымдарды тек нақты мақұлданған мекенжайлармен шектеңіз.

Perplexity LLM-дерді қалай қорғайды?

Біз жоғарыда аталған әр тәуекел ерте ме, кеш пе іске асады деп есептейміз және ол орын алғанда көп зиян келтіре алмайтындай етіп жобалаймыз. Мұны қалай жасайтынымызды ақпараттық қауіпсіздік жөніндегі бас директорымыз (CISO) Kyle Polley жақында өткен семинарда түсіндірді.

• Агенттің өз компьютері болады және ол бастапқыда бос болады: Ноутбугыңызға орнатылған агент құралдары ондағы файлдарға, қолданбаларға және сақталған тіркелгі деректеріне қол жеткізе алады. Perplexity Computer керісінше жұмыс істейді. Әр тапсырма өзінің оқшауланған sandbox ортасында орындалады және Polley айтқандай, «әдепкі бойынша оның ешнәрсеге қолжетімділігі жоқ».
• Агент құпия сөздерді ешқашан көрмейді: Қосылған қызметтердің тіркелгі деректері sandbox-тан тыс сақталады. Агентке GitHub сияқты қызметке қосылу қажет болғанда, ол тіркелгі деректері қосылмаған сұрау жібереді. Шлюз мекенжай мен сұраудың күтілгендей екенін тексереді, содан кейін сұрау сыртқа шығар кезде тіркелгі деректерін қосады. Агент кілттерді алмай-ақ қосылымды пайдалана алады.
• Рұқсаттарыңыз сақталады, әрі оларды қатаңдата аласыз: OAuth арқылы жасалған қосылымдар қосылған қызметтегі қолжетімділік рұқсаттарыңызды сақтайды. Сіз бір нәрсені көре алмасаңыз, агентіңіз де оны көре алмайды.
• Әр веб-бет бөтен ретінде қарастырылады: Біз BrowseSafe құралын агенттік браузеріміз Comet үшін жасадық, өйткені біз сынаған құралдар нақты пайдалануда қажеттіліктерімізді өтемеді. Браузер веб-беттерді және басқа сыртқы контентті, соның ішінде электрондық хаттарды, промпт-инъекцияның бар-жоғына тексереді. Біз модельді де, деректер жинағын да ашық қолжетімділікке шығардық.
• Біз агентті және ол жұмыс істейтін машиналарды бақылаймыз: Numbat агенттің әрекет етуге шешім қабылдауы мен құралдың нақты іске қосылуы арасында тұрады. Numbat қолдау көрсетілетін кодтау агенттеріндегі әрекеттерді журналға жазады және бапталған саясаттарды бұзатын әрекеттерді олар орындалмай тұрып бұғаттай алады. Bumblebee ноутбуктердегі, серверлердегі және құрастыру конвейерлеріндегі бағдарламалық пакеттерді түгендеп, белгілі зиянды пакеттерді белгілейді. Екеуінің де бастапқы коды ашық.
• Модель провайдерлері деректеріңізді сақтамайды: Үшінші тарап LLM провайдерлерімен деректерді мүлдем сақтамау туралы келісімдеріміз бар. Enterprise әкімшілері Perplexity-нің өзіндегі деректерді сақтау мерзімін де 24 сағатқа дейін қысқарта алады.

Біз Numbat-ты алдын ала жасадық, оның себебін Polley бір сөйлеммен түйіндейді: «Агентке неғұрлым көп дербестік берсеңіз, тәуекел соғұрлым жоғары болады».

LLM қауіпсіздігі туралы жиі қойылатын сұрақтар

Ең қауіпсіз LLM қайсы?

Ешбір LLM қолданбаны өздігінен қауіпсіз ете алмайды — модельдер әлі де оқуы тиіс контентті орындауы тиіс нұсқаулар деп қате қабылдауы мүмкін. Стандартты сынақтарда мықты көрінетін қорғаныс тетіктері де қысым кезінде сыр беріп қалуы мүмкін.

Дұрысырақ сұрақ — сіздің пайдалану жағдайыңыз үшін қай конфигурация ең қауіпсіз. Бұл — шектеулі рұқсаттар, модельден алшақ сақталатын тіркелгі деректері, қауіпті әрекеттерді адамның мақұлдауы және қорғанысыңызды білетін адамдардың тестілеуі.

LLM осалдықтары дегеніміз не?

LLM осалдықтары — шабуылдаушының әрекетінен болсын, жүйенің өз қателіктерінен болсын, ЖИ жүйесін алдауға, деректердің ағып кетуіне немесе зиян келтіруге жол ашатын әлсіз тұстар.

Он негізгі тәуекел: промпт-инъекция, құпия ақпараттың жария болуы, шамадан тыс өкілеттік, жеткізу тізбегі, деректер мен модельді улау, шектеусіз тұтыну, жалған ақпарат, жасырын контекстің ашылуы, векторлар мен эмбеддингтердің осалдықтары және нәтижені дұрыс өңдемеу.

Жеке LLM қауіпсіз бе?

Кейбір жағдайларда бұл қауіпсізірек нұсқа, бірақ әдепкі бойынша емес. Модельді өз инфрақұрылымыңызда немесе бұлттық ортада іске қоссаңыз, деректерді өңдеуді көбірек бақылай аласыз. Алайда промпт-инъекциялардың, шамадан тыс өкілеттіктің, улаудың немесе жалған ақпараттың алдын автоматты түрде алатын тәсіл жоқ.

Модельді өзіңіз орналастырған кезде жүктеп алған модельге, соның ішінде жеткізу тізбегі тәуекелдеріне және оған қажетті инфрақұрылымға да өзіңіз жауап бересіз.