พูดง่ายๆ: AI Security Review คือการตรวจอย่างเป็นระบบว่ามีอะไรผิดพลาดได้บ้าง เมื่อ LLM (Large Language Model) ถูกฝังอยู่ใน Workflow ของลูกค้าหรืองานการเงิน — ก่อนที่ Feature นั้นจะเปิดใช้จริง ครอบคลุมว่า Attacker จะ Manipulate โมเดลผ่าน Input ที่สร้างมาพิเศษได้อย่างไร ข้อมูล Sensitive จะรั่วออกทาง Output ได้ยังไง Retrieval Pipeline ที่โดน Compromise จะ Poison สิ่งที่โมเดลเชื่อได้ยังไง และ Agent ที่ใช้ Tool จะมี Blast Radius กว้างแค่ไหน — กว้างกว่าที่ทีม Product ตั้งใจไว้มาก ถ้าทำก่อน Launch งานนี้ควบคุมได้ ถ้าทำหลังเกิด Incident งานนี้คือการ Crisis Response
ทีมที่ข้ามขั้นตอนนี้ไปไม่ได้ประมาท แค่เร่งรีบและมี Deadline จริง แต่ปัญหาคือ LLM Risk ไม่ทำงานเหมือน Application Security แบบเดิม Pentest ที่ตรวจ SQL Injection, Authentication Bypass และ OWASP Top 10 Web จะไม่เจอ Prompt Injection Path, Jailbreak Surface หรือช่องรั่วข้อมูลผ่าน Retrieval Pipeline Threat Model เปลี่ยนจริง ตั้งแต่ Feature เริ่ม Generate ภาษา — กระบวนการตรวจสอบต้องตามทัน
Threat Model เปลี่ยนยังไงเมื่อ Feature ใช้ LLM
Application Security แบบเดิมสมมติว่า Code ที่ Ship ทำสิ่งที่เขียนไว้ แต่ LLM Feature ไม่ใช่แบบนั้น — มัน Generate พฤติกรรมตอน Inference ตาม Input ที่ไม่สามารถ Enumerate ล่วงหน้าได้ครบ ความเปลี่ยนแปลงนี้สร้างความเสี่ยง 4 ประเภทที่ Software ปกติไม่มี: หนึ่ง — Prompt Injection: Attacker ใส่คำสั่งใน Input เพื่อ Override System Prompt ที่ดูปลอดภัยใน Code Review; สอง — Jailbreak: Attacker สร้าง Input แบบวนซ้ำจนโมเดลละเมิด Constraint ของตัวเอง — ส่งข้อมูลภายใน หรือแอบอ้างตัวตน; สาม — Sensitive Output Disclosure: โมเดลเผย PII, ข้อมูลจาก Training Data หรือเอกสารที่ Retrieve มา — บางครั้งจาก Query ที่ไม่ได้ตั้งใจโจมตีเลย; สี่ — Supply Chain Risk ที่ระดับโมเดลและ Runtime: ถ้า Feature พึ่ง Third-party Model Endpoint หรือ Open-weight Model ที่ Host เอง คุณรับ Security Posture ของ Dependency นั้นมาด้วย
OWASP LLM Top 10 ใช้ยังไงในทางปฏิบัติ
OWASP LLM Top 10 คือรายชื่อ 10 ความเสี่ยงด้านความปลอดภัยที่วิกฤตที่สุดสำหรับแอป LLM — รักษาโดย Community ไม่ใช่ Compliance Checklist แต่เป็นการ Enumerate Attack Class ที่โดน Exploit จริงใน Production 5 ประเภทที่เจอบ่อยที่สุดและต้องตรวจก่อน Launch:
- LLM01 — Prompt Injection: Attacker ฝัง Instruction ใน User Input เพื่อ Override System Prompt — Direct Injection มาทาง User Turn; Indirect Injection มาผ่าน Content ที่ RAG (Retrieval-Augmented Generation) Pipeline ดึงมา เช่น เอกสาร, หน้าเว็บ หรือ Record ฐานข้อมูล
- LLM02 — Insecure Output Handling: Output โมเดลไหลเข้า Component ปลายทาง — HTML ที่ Render, SQL Query, Shell Command, API Call — โดยไม่ Sanitise โมเดลที่สร้าง SQL หรือ JavaScript ที่ดูสมจริงปลอดภัยก็ต่อเมื่อ Output นั้นถูกมองว่าเป็น Untrusted Input
- LLM06 — Sensitive Information Disclosure: โมเดลเผย PII, รายละเอียดระบบภายใน, Credential หรือเนื้อหา Proprietary จาก Training Data หรือเอกสารใน Context — บางครั้งจาก Query ธรรมดาที่ไม่ได้โจมตี
- LLM08 — Excessive Agency: โมเดลเข้าถึง Tool หรือ API มากกว่าที่งานต้องการจริง เมื่อ Agent อ่าน Email, เขียน Database และ Trigger Webhook ได้ใน Session เดียว — Injection สำเร็จครั้งเดียวต่อ Capability เหล่านั้นได้ทั้งหมด
- LLM03/LLM09 — Training Data Poisoning / Misinformation: สำหรับทีมที่ใช้ Fine-tuning หรือ RAG — ความสมบูรณ์ของข้อมูลที่โมเดลเรียนรู้หรือ Retrieve มาคือขอบเขตความปลอดภัย Data หรือ Corpus ที่โดน Poison ทำให้ Output ผิดอย่างเป็นระบบใน Workflow ที่สำคัญ
Indirect Prompt Injection — Pattern ที่ทีม Engineering พลาดบ่อยที่สุด
Direct Prompt Injection ทีมส่วนใหญ่รู้แล้วและมี Mitigation บ้าง Indirect Prompt Injection คือ Pattern ที่พลาดบ่อยกว่า — และป้องกันยากกว่า เพราะคำสั่ง Malicious ไม่ได้มาจาก User แต่มาจาก Content ที่แอปดึงมาแทน RAG Pipeline ดึงเอกสารจาก Knowledge Base, Inbox Email, CRM หรือ Web Search Result เอกสารเหล่านั้นสามารถมีข้อความ Adversarial ที่เมื่ออยู่ใน Context Window โมเดลจะสั่งให้ทำสิ่งที่ User ไม่ได้ขอ — ส่งข้อมูลออก Endpoint ภายนอก, สรุปเอกสารผิดชิ้น หรือสร้าง Response ที่ Social-engineer คนถัดไปใน Workflow
การแก้ไม่ใช่หยุดใช้ RAG แต่คือ: มอง Content ที่ Retrieve มาทั้งหมดเป็น Untrusted; ทำ Allowlisting Source การ Retrieve; ออกแบบ Output Pipeline ให้ยืนยัน Action ของโมเดลกับ Request ของ User ก่อน Execute
Tool Use และ Agent — Blast Radius กว้างแค่ไหน
Blast Radius ขยายตาม Tool Access โดยตรง Agent ที่เข้าถึงได้แค่ Knowledge Base อ่านอย่างเดียวมี Blast Radius จำกัด แต่ Agent ที่อ่านไฟล์, เรียก Internal API, ส่ง Email และเขียน Database ได้ — Blast Radius ครอบ Writable Surface ทั้งองค์กร หลักการ Least Privilege ใช้กับ Model Permission เหมือนกับ User Account และ Service Role: โมเดลควรมีสิทธิ์เท่าที่งานนั้นต้องการจริง ไม่มากกว่านั้น
ก่อน Launch: Map ทุก Tool ที่ Agent เรียกได้, ขอบเขต Data สูงสุดที่เข้าถึงได้ผ่านแต่ละ Tool และ Action Chain ที่แย่ที่สุดที่ Instruction ที่โดน Inject อาจ Trigger Human-in-the-Loop เป็น Security Control — ไม่ใช่ UX Compromise: Action ที่ผลกระทบสูง เช่น เขียน Production Data, ส่งการสื่อสารภายนอก หรือทำ Transaction ทางการเงิน — ต้องมี Human Confirm ที่ข้ามโดย Output โมเดลไม่ได้
Eval-in-CI — ผลลัพธ์ปฏิบัติของ Review
Review ครั้งเดียวก่อน Launch ดีกว่าไม่ทำ แต่ยังไม่พอ Threat Model ของ LLM Feature เปลี่ยนทุกครั้งที่ System Prompt เปลี่ยน, Model Version อัปเดต, เพิ่ม Retrieval Source ใหม่ หรือต่อ Tool ใหม่ ผลจาก Review ก่อน Launch ควรแปลงเป็น Adversarial Test Case — Payload เฉพาะ, Edge-case Input, Injection Attempt — ที่รันอัตโนมัติใน CI ทุกครั้งที่มีการเปลี่ยนแปลงที่เกี่ยวข้อง
นี่คือ Eval-in-CI: มอง Adversarial Evaluation เป็น Gating Test ไม่ใช่ Audit เป็นรอบ Eval ที่ Fail บล็อก Merge, Eval ที่ Pass ให้หลักฐานที่เป็นเอกสารว่าการเปลี่ยนแปลงนั้นไม่ทำให้ Security Property ของ Feature แย่ลง
ทีมที่ Catch Regression ใน CI Ship Model Update ได้ทุกสัปดาห์โดยไม่มีปัญหา — ทีมที่ไม่มีระบบนี้เจอปัญหาครั้งแรกจากคำร้องเรียนของลูกค้า
Governance: ISO 27001 ISMS และ ISO/IEC 42001 ในฐานะ Extension สำหรับ AI
ผล Review ต้องอยู่ที่ไหนสักแห่งที่ Audit ได้ ISO 27001 กำหนดกรอบ ISMS (Information Security Management System) — Framework สำหรับระบุ จัดการ และติดตาม Information Security Risk ทั่วองค์กร ผล AI Security Review คือ Risk Record: ต้องมี Owner, การตัดสินใจ Treatment, หลักฐานการแก้ไข และวันที่ Re-assess องค์กรที่มี ISMS อยู่แล้วจัดการเหล่านี้เหมือน Finding อื่นทุกอย่าง — เข้า Risk Register, ดูแลภายใต้ Risk-treatment Plan, เก็บหลักฐานสำหรับ Audit
ISO/IEC 42001 คือ Extension เฉพาะ AI ของ Framework นั้น — เพิ่ม Control สำหรับ AI Risk Management, AI Lifecycle Governance และภาระด้านเอกสารที่ Regulator เริ่มกำหนด ถ้าองค์กรกำลังเดินไปทาง ISO/IEC 42001 — Review ก่อน Launch คือจุดเริ่มต้นที่เป็นธรรมชาติ: Threat Model และผล Adversarial Test เป็น Core Artefact สำหรับ Technical File ที่ทั้ง ISO/IEC 42001 และ EU AI Act High-Risk Requirement คาดหวัง
บริบท Compliance ระดับโลก
สำหรับทีมในไทย สิงคโปร์ อินโดนีเซีย มาเลเซีย และเวียดนาม — ภาพ Compliance ที่ซ้อนอยู่บน Security Review ชัดเจน: PDPA บังคับแจ้ง Breach ภายใน 72 ชม. — ทำไม่ทันถ้าไม่มี Incident Response Document และ Log ที่ Audit ได้ไว้ล่วงหน้า MAS TRM ของสิงคโปร์กำหนดให้ Financial Services มี Continuous Monitoring ที่เป็นเอกสาร EU AI Act มี Extraterritorial Reach — ครอบ System ใดก็ตามที่ให้บริการผู้ใช้ใน EU หรือมีผลต่อชาว EU โดยไม่สนว่าโมเดลรันที่ไหน สำหรับแอป High-Risk ภายใต้ Annex III — Technical File ที่มีเอกสาร Risk Assessment, ผลการทดสอบ และขั้นตอน Monitoring เป็นข้อกำหนดก่อน Launch ไม่ใช่ Audit Item หลัง Launch
MITRE ATLAS — Framework Adversarial Threat สำหรับ AI และ Machine Learning System เฉพาะทาง รักษาเป็น Complement ของ MITRE ATT&CK — ให้ Taxonomy สำหรับ Document Attack Technique ในรูปแบบที่ Regulator และทีม Enterprise Security อ้างอิงไขว้ได้
Checklist ปฏิบัติสำหรับสัปดาห์ก่อน Launch
ไม่ใช่ Security Programme ที่ครบถ้วน — แต่คือขั้นต่ำที่ทีมที่ Ship AI Feature เข้า Production Workflow ควร Confirm ได้ก่อนเปิด:
- Threat Model เป็นลายลักษณ์อักษร ครอบคลุม: Prompt Injection (ทั้ง Direct และ Indirect), Sensitive Output, Tool Use Blast Radius, ความสมบูรณ์ของ Retrieval Pipeline และ Model Supply Chain — ไม่ใช่แค่อยู่ในหัว
- System Prompt และ Logic การจัดการ Output ผ่าน Review สำหรับ Injection Path แล้ว Content ที่ Retrieve มาถูกมองเป็น Untrusted; Output ที่ไหลเข้า Code Execution, Database Write หรือ External Call ถูก Sanitise และ Validate
- Agent Tool Permission Scope อยู่ในระดับ Task-minimum; Action ที่ผลกระทบสูงต้องมี Human-in-the-Loop Confirm; Tool Definition ผ่าน Review เทียบ OWASP LLM08 (Excessive Agency) แล้ว
- Adversarial Test Case มีอยู่และรันใน CI: ขั้นต่ำคือ Direct Injection Attempt ใส่ System Prompt, Indirect Injection ผ่าน Retrieval Pipeline และ Jailbreak Pattern ที่รู้จักสำหรับโมเดลและงานนั้น — Fail บล็อก Merge
- Finding เป็นเอกสารและอยู่ใน Risk Register: การตัดสินใจ Treatment — Accept, Mitigate หรือ Transfer — มี Owner และวันเป้าหมาย ถ้ามี ISO 27001 ISMS อยู่แล้วคือ Risk Record มาตรฐาน ถ้าไม่มี — นี่คือจุดเริ่มต้น
ทำก่อน Ship — ไม่ใช่หลัง Incident แรก
คำแนะนำเชิงปฏิบัติสำหรับทีม Engineering ง่ายมาก: Pre-launch AI Security Review ใช้เวลาไม่กี่วัน Post-incident Response — พร้อมภาระแจ้งเตือนภายใต้ PDPA, การขอหลักฐานจาก Sector Regulator และความเสียหายต่อชื่อเสียงของ AI Feature ที่ลูกค้าใช้ — ใช้เวลาหลายเดือน ต้นทุนต่างกันมาก ทีมที่ Ship LLM Feature เข้า Workflow การเงินและสาธารณสุขรายงานตรงกันว่า Review พบปัญหาที่ทั้งทีม Engineering และทีม Product ไม่ได้คาด เพราะ Failure Mode ไม่ใช่สิ่งที่คนที่คุ้นกับ Software ปกติจะนึกถึงตามธรรมชาติ Threat Model ต่างกันจริง — และวิธีเดียวที่จะรู้ว่ามันหน้าตาอย่างไรสำหรับ Feature ของคุณ คือต้องตรวจดู
HarmonyX ช่วยได้ยังไง
บริการ AI Security & LLM Risk Review ของ HarmonyX รัน Scope ทั้งหมดที่อธิบายใน Post นี้กับ Application จริงของคุณ — Threat Model เทียบ OWASP LLM Top 10 และ MITRE ATLAS, Adversarial Red-team Testing พร้อม Payload ที่ Reproducible, Eval-in-CI Suite ส่งมอบให้ทีม และ Finding ที่เป็นเอกสารภายใต้ ISO 27001 ISMS ของเราสำหรับความพร้อม Audit ถ้าทีมกำลังอยู่ในช่วงสัปดาห์สุดท้ายก่อน Launch หรือ Ship ไปแล้วและต้องการปิดช่องว่าง — ติดต่อมาคุยได้ที่ harmonyx.co/services/ai-security
