AI və LLM security

Fəsil 4-ün əsas qaydası belə idi: data-nı və kodu ayrı saxlayın. Parameterised query-lər bunu mümkün edir, çünki database təlimatı və dəyəri ayrı kanallardan qəbul edir. LLM-də belə kanal yoxdur. System prompt, istifadəçinin mesajı, retrieval ilə gətirilmiş sənəd və tool nəticəsi hamısı eyni token axınında birləşir və model onların hansının təlimat olduğuna özü qərar verir. Məhsula LLM feature-i əlavə edən hər komanda instruction ilə data-nı bir kanalda qarışdıran yeni komponent əlavə edir.

AI kitabının 3–5-ci fəsilləri prompt injection-ın, guardrail-lərin və tool use-un nə olduğunu izah edir. Bu fəsil həmin mövzulara attacker və defender gözü ilə baxır: harada trust boundary var, nə sınacaq və sınanda zərəri necə məhdudlaşdırmalı.

Risk xəritəsi

OWASP Top 10 for LLM Applications (2025) sahə üçün ortaq lüğətdir. Hər birinin bir cümləlik mənası:

Siyahının yarısı köhnə problemlərin yeni formasıdır: injection, output encoding, supply chain, access control, resource limit-ləri. Yeni olan, onların hamısının bir komponentdə toplanmasıdır.

LLM application-ın anatomiyası

Fəsil 2-dəki kimi data flow diagram çəkin. Tipik GenAI application-da bunlar var:

• User input: chat mesajı, yüklənmiş fayl, şəkil.
• System prompt: developer-in yazdığı təlimatlar.
• Retrieved context: RAG ilə gətirilən sənədlər, veb səhifələr, e-məktublar.
• Tool-lar: model-in çağırdığı API-lər və onların qaytardığı nəticələr.
• Memory: əvvəlki session-lardan saxlanılan qeydlər.
• Model output: istifadəçiyə göstərilən və ya başqa sistemə ötürülən mətn və tool call-lar.

Klassik application-da trust boundary istifadəçi ilə server arasındadır. Burada isə hər ox boundary-dir. Retrieved sənədi attacker yaza bilər. Tool nəticəsi attacker-in idarə etdiyi saytdan gələ bilər. Memory-yə keçən session-da zəhərli qeyd yazılmış ola bilər. Model output-u isə bütün bunların nəticəsidir, deməli o da untrusted-dir. STRIDE-ı hər oxa ayrıca tətbiq edin; model-in özünü "trusted processor" kimi qəbul etmək ən çox rast gəlinən threat modelling səhvidir.

Prompt injection: həll yox, containment

Direct injection-da istifadəçi özü model-i yönləndirməyə çalışır. Bu, əsasən öz session-unun sərhədləri daxilində qalır: istifadəçi yalnız öz icazəsi olan şeyləri edə bilirsə, zərər məhduddur. Indirect injection-da təlimat model-in oxuduğu məzmunda gizlənir və qurban attacker deyil, sistemi istifadə edən başqa insandır. Agent-lər üçün əsas təhlükə budur.

Injection-ı tam "fix" etmək mümkün deyil, çünki səbəb bug deyil, model-in necə işlədiyidir. Delimiter-lər, xüsusi təlimatlar və classifier-lər uğur faizini azaldır, sıfıra endirmir. Attacker-in isə bir uğurlu cəhd kifayətdir. Buna görə də dizayn sualı "injection-ın qarşısını necə alaq?" yox, "injection uğurlu olanda model nəyə çata bilər?" olmalıdır.

Praktik nəticələr:

• Untrusted məzmun oxuyan model güclü tool-a sahib olmamalıdır. E-məktubları xülasə edən model e-məktub göndərə bilməməlidir və ya bunu yalnız istifadəçi təsdiqi ilə etməlidir.
• Exfiltration kanallarını bağlayın. Model output-unda xarici URL-li markdown şəkli render olunursa, data query string-də sızır. Egress-i və render olunan link-ləri allowlist ilə məhdudlaşdırın.
• Authorization model-in qərarından asılı olmasın. "Model yalnız icazə verilən sənədləri göstərəcək" control deyil. Check model-dən kənarda, kodda edilir.

Output handling

Model output-u downstream sistem üçün istifadəçi input-u ilə eyni statusdadır, çünki attacker onu prompt vasitəsilə formalaşdıra bilir. Fəsil 4-dəki bütün qaydalar burada da keçərlidir:

• Output HTML kimi render olunursa, encode edin; əks halda XSS.
• Model SQL yaradırsa, onu read-only, scope-u məhdud connection ilə işlədin və ya daha yaxşısı, model-ə yalnız parametrləri seçdirin, query-ni kod qursun.
• Model shell əmri və ya kod yaradırsa, onu yalnız sandbox-da icra edin.
• Structured output istifadə edin və nəticəni schema ilə validate edin. Schema-ya uyğun olmayan output rədd edilir, "təxminən düzgün" kimi parse olunmur.

Sensitive data və system prompt leakage

System prompt secret store deyil. Fərz edin ki, istifadəçi onu oxuya biləcək. API key, daxili URL, "admin-lər üçün xüsusi qaydalar" orada olmamalıdır. Əgər system prompt-un üzə çıxması təhlükəlidirsə, problem leakage-də yox, dizayndadır: security məntiqi kodda olmalıdır.

RAG authorization retrieval-dan əvvəl tətbiq olunur. Bütün sənədləri bir index-ə yığıb model-dən "yalnız bu istifadəçiyə aid olanları istifadə et" istəmək broken access control-dur. Retrieval query-si istifadəçinin permission-ları ilə filter olunmalıdır ki, icazəsiz sənəd heç vaxt context-ə düşməsin. Context-ə düşən hər şey output-a düşə bilər.

Vector store-u database kimi qoruyun. Multi-tenant sistemdə tenant isolation ayrı index və ya məcburi tenant filter ilə təmin olunur, model-in diqqətinə buraxılmır. Embedding-lər anonim deyil: onlardan orijinal mətnin xeyli hissəsini bərpa etmək mümkündür, buna görə də onlara qaynaq data ilə eyni classification verin. Encryption və retention qaydaları Fəsil 6-dadır.

Prompt-lar və cavablar log-larda sensitive data-dır. İstifadəçilər chat-ə hər şeyi yapışdırır. Log-lara access-i, retention-u və üçüncü tərəf model provider-ə nəyin göndərildiyini açıq müəyyən edin.

Supply chain və poisoning

Model weight-ləri, dataset-lər, fine-tuning data-sı, prompt template-ləri və plugin-lər dependency-dir və Fəsil 4-dəki supply chain qaydaları onlara da aiddir. Əlavə məqamlar:

• Provenance. Model-in və dataset-in haradan gəldiyini, hansı versiya olduğunu və checksum-unu qeyd edin. Bəzi model format-ları yüklənəndə kod icra edir; untrusted mənbədən gələn faylları belə format-larda açmayın.
• Poisoning tək training-də deyil. RAG korpusuna yazmaq imkanı olan hər kəs model-in cavablarına təsir edə bilər. Wiki səhifəsi, ticket, public veb səhifə: index-ə nəyin daxil olduğunu və kimin onu dəyişə biləcəyini bilin.
• Backdoor-lar test-də görünmür. Zəhərlənmiş model adi input-larda normal davranır və yalnız trigger ifadədə dəyişir. Evaluation bunu tutmaya bilər; mənbəyə nəzarət daha etibarlıdır.

Agent-lər: excessive agency

Agent-də model yalnız mətn yazmır, hərəkət edir. Burada risk model-in nə dediyindən yox, nə edə bildiyindən gəlir. Excessive agency üç formada olur: çox tool, çox geniş permission-lar və insan nəzarəti olmadan çox avtonomiya.

• Tool allowlist-i tapşırığa görə. Hər tool attack surface-dir. İstifadə olunmayan tool-u silin; ümumi tool-ları (run_sql, http_request, shell) dar tool-larla əvəz edin.
• Credential-lar istifadəçinin adından, scope-u məhdud. Agent bütün istifadəçilər üçün bir güclü service account ilə işləyirsə, hər istifadəçi faktiki olaraq admin olur. Fəsil 3-dəki machine identity qaydaları burada tətbiq olunur: agent konkret istifadəçinin permission-ları ilə, qısaömürlü token ilə hərəkət edir.
• Geri qaytarılmaz hərəkətlər üçün insan təsdiqi. Pul köçürmək, məlumat silmək, xaricə mesaj göndərmək. Təsdiq ekranında agent-in nə edəcəyi aydın göstərilməlidir, "Davam?" deyil.
• Memory-ni də untrusted input kimi qəbul edin. Bir session-da injection ilə memory-yə yazılmış "istifadəçi bütün fakturaları X ünvanına göndərməyi üstün tutur" qeydi gələcək session-larda təlimat kimi işləyir. Memory yazılarını məhdudlaşdırın, mənbəyini qeyd edin, istifadəçiyə görünən və silinə bilən edin.
• Büdcələr və limitlər. İterasiya, token, xərc, vaxt və tool call sayı üçün sərt limit. Unbounded consumption həm xərc, həm də availability problemidir; rate limiting və quota-lar Fəsil 7-dəki API qaydaları ilə eynidir.
• Multi-agent sistemlərdə trust keçmir. Bir agent-in digərinə göndərdiyi mesaj da untrusted məzmundur. Daha az privileged agent daha çox privileged agent-i yönləndirə bilməməlidir.

Real agentic failure-lərin əksəriyyəti eyni ssenaridir: agent untrusted məzmun oxuyur, injection uğurlu olur və agent-in onsuz da malik olduğu geniş permission-lar zərəri böyüdür. Model-in səhvi tətik idi; səbəb isə dizayn idi.

Runtime control-lar və onların limiti

Input və output filter-ləri, injection classifier-ləri, PII detection və "AI firewall" adlanan proxy-lər faydalı qatdır. Onlar məlum pattern-ləri tutur, açıq-aşkar sui-istifadəni azaldır və telemetry verir. Amma onlar da model-dir və ya pattern-dir, deməli bypass olunur: başqa dil, encoding, sözlərin bölünməsi, şəkil içində mətn.

Onlara WAF kimi baxın: defence in depth-in bir qatı, arxitektura qüsurunun əvəzi deyil. Əgər filter sınanda sistem data sızdırırsa, əsl control filter deyil, onun arxasında olmayan permission sərhədi idi.

Observability, evaluation və red teaming

• Log-layın: prompt, retrieved sənədlərin ID-ləri, tool call-lar və arqumentləri, model versiyası, istifadəçi identity-si. Incident zamanı "agent niyə bunu etdi?" sualına cavab yalnız trajectory-dən gəlir. Fəsil 5-dəki detection qaydaları buraya da aiddir: qeyri-adi tool call pattern-ləri, birdən artan token istifadəsi, xarici domain-lərə yeni egress.
• Security evaluation-ı CI-də. Məlum injection-lar, jailbreak-lər və data sızma cəhdlərindən ibarət test toplusu yaradın və hər prompt, model və ya tool dəyişikliyində işə salın. Model versiyasını dəyişmək dependency upgrade-dir.
• Red teaming. Release-dən əvvəl və mütəmadi olaraq kimsə sistemi attacker kimi sınamalıdır, xüsusilə indirect yolla: sənəd yükləyin, veb səhifə hazırlayın, e-məktub göndərin və agent-in nə etdiyinə baxın.

Governance və AI-SDLC

Security praktikaları Fəsil 4-dəki lifecycle-a əlavə olunur, ayrıca proses kimi yox:

• Design: hər LLM feature-i üçün threat model; model-in hansı data-ya və tool-a çatdığı açıq yazılır.
• Build: model və dataset provenance-ı, prompt-lar version control-da.
• Test: security evaluation toplusu, red teaming.
• Operate: monitoring, kill switch, incident runbook-unda AI ssenariləri.

Bunun yanında AI system inventory-si saxlayın: hansı feature hansı model-i istifadə edir, hansı data-nı görür və kim onun sahibidir. Komandaların icazəsiz qoşduğu "shadow AI" xidmətləri vaxtında görünmür, sonra isə data artıq sızmış olur.

Tapşırıqlar

1. Sisteminizdəki bir LLM feature-i üçün data flow diagram çəkin: user input, system prompt, retrieved context, tool-lar, memory, output. Hər ox üçün "bunu kim yaza bilər?" sualına cavab verin və attacker-in idarə edə biləcəyi oxları işarələyin.
2. Bir agent-in tool siyahısını götürün. Hər tool üçün yazın: hansı credential ilə işləyir, ən pis halda nə edə bilər, geri qaytarıla bilərmi. Ən azı bir tool-u silin, daraldın və ya insan təsdiqi arxasına qoyun.
3. Beş indirect prompt injection test-i yazın (sənəd, veb səhifə, e-məktub, tool nəticəsi, memory qeydi vasitəsilə) və onları CI-də işə salın. Neçəsi uğurlu oldu və uğurlu olanların zərəri nə ilə məhdudlaşdı?