จำลองภัยคุกคาม (Threat Model): agent คือ attack surface ใหม่

จบสามคอร์สที่ผ่านมา คุณถือ agent Order ของจริงมาแล้วครบสามชั้น คอร์สที่ 15 ให้ agent ความสามารถ — model claude-opus-4-8 (ใช้เป็นตัวอย่าง ณ 2026-07 — id เลื่อนไหวตามเวลา) บวก tool สามตัว getOrder / getDeliveryStatus / issueRefund บวก loop ที่ป้อนผลของ tool กลับเข้า model จนงานเสร็จ คอร์สที่ 16 ให้ ความรู้ — retrieval, memory, การจัดงบ token, compaction คอร์สที่ 17 ทำให้มัน รอดจากอุบัติเหตุ — retry, timeout, idempotency, stop policy แบบประกอบ

ทั้งสามคอร์สนั้นมีสมมติฐานเงียบๆ ร่วมกันข้อหนึ่งที่ไม่มีบทไหนพูดออกมาตรงๆ: ผู้ใช้ให้ความร่วมมือ และสภาพแวดล้อมเป็นมิตร #17 รักษา agent จากความล้มเหลว โดยบังเอิญ — ลูกค้าดับเบิลคลิก, tool timeout, model ตอบเพี้ยน คอร์สนี้ลบสมมติฐานนั้นทิ้ง แล้วถามคำถามที่ไม่มีคอร์สก่อนหน้าถาม — จะเกิดอะไรขึ้นเมื่อมีคน ตั้งใจ พังมัน? คนที่พยายาม hijack, jailbreak, ดูดข้อมูลออก หรือ abuse agent Order นี่คือ attack surface ใหม่ทั้งผืน และเราจะรักษามันด้วย defense-in-depth

📦 code ตัวอย่าง

คอร์สนี้ต่อยอด agent Order ตัวเดิมจากคอร์ส #15 (พร้อม context layer จาก #16 และ resilient runtime จาก #17) — repo kaen-food-ordering (กำลังจัดทำ) #18 ไม่เพิ่ม tool หรือ store ใหม่ แต่ห่อ ชั้น guard คร่อมมัน บทนี้เป็นบทวางกรอบความคิด (threat model) — ยัง ไม่มี code รันได้ code guard ของจริงเริ่มที่บท4 (บท2–3 สาธิตรูปแบบการโจมตีก่อน) ทุกกติกา API ฝั่งแชตจาก #15 ยังยึดเดิมทุกข้อ และบทนี้ตั้ง precedent ของ honesty spine กับ 🔗 callout อ้างอิงต้นทางไว้ให้ทุกบทหลังจากนี้เดินตาม

agent Order คือ attack surface ใหม่ — เพราะมันครบสามอย่างพอดี

Threat Model คือการวิเคราะห์อย่างเป็นระบบว่า ใคร อาจโจมตี ที่ จุดไหน และด้วย วิธีใด — ไม่ใช่การท่อง checklist ให้ผ่าน audit ก้าวแรกของ threat model คือถามว่าทำไม agent ตัวนี้ถึงน่าโจมตีตั้งแต่แรก

Simon Willison ตั้งชื่อสูตรอันตรายนี้ไว้ว่า Lethal Trifecta — agent กลายเป็นเป้าหมายจริงจังเมื่อมันมีครบสามขา (S10, verbatim):

“Access to your private data… Exposure to untrusted content… The ability to externally communicate in a way that could be used to steal your data.”

map สามขานี้ลงบน agent Order ที่คุณสร้างมาเองกับมือ แล้วจะเห็นว่ามันมีครบทุกขา:

ขาที่ 1 — private data: getOrder / getDeliveryStatus อ่านข้อมูลลูกค้าจริง (ที่อยู่ เบอร์โทร ยอดเงิน ประวัติออเดอร์)
ขาที่ 2 — untrusted content: ทุก byte ที่ getOrder คืนมา — โดยเฉพาะ field อย่าง note ของออเดอร์ — เป็นเนื้อหาที่ ผู้อื่นแก้ได้ agent #16 ยังดึง memory/retrieval เข้ามาเป็น context อีก ทุกอย่างนี้คือ content ที่ model ไม่ได้เป็นคนต้นเรื่อง
ขาที่ 3 — ส่งออกได้: issueRefund (และ outbound call ใดๆ) คือช่องทางลงมือทำจริงและส่งข้อมูลออก

Willison พูดต่อว่าเมื่อครบสามขา “an attacker can easily trick it into accessing your private data and sending it to that attacker.” agent Order ไม่ได้แค่ อาจ มีช่องโหว่ — มันถือครบทั้งสามขาของสูตรที่อันตรายที่สุดตั้งแต่วันแรกที่มันรันได้ นี่คือเหตุผลว่าทำไม threat model ถึงต้องมาก่อน guard สักตัว

แผนที่ภัย: OWASP LLM Top 10 (2025)

พอรู้ว่า agent เป็นเป้า เราต้องมี แผนที่ ว่าจะถูกโจมตีในรูปแบบไหนบ้าง แผนที่ที่เป็นแกนของทั้งคอร์สคือ OWASP LLM Top 10 — รายการ 10 ความเสี่ยงสำหรับ app LLM ฉบับปี 2025 (S1) บทนี้จะ ไม่ สอนครบทั้งสิบแบบเจาะลึก — มันเป็น threat-model lesson ไม่ใช่ compliance recital เราแค่กางแผนที่แล้วชี้ว่าคอร์สจะสร้างการรักษาต่อข้อไหน

ห้าข้อที่ load-bearing (คอร์สนี้สร้าง guard ต่อโดยตรง):

LLM01 Prompt Injection — input เปลี่ยนพฤติกรรม model ในทางที่ไม่ตั้งใจ (บท2/3/4)
LLM02 Sensitive Information Disclosure — agent ทำ PII หรือข้อมูลลูกค้าคนอื่นรั่ว (บท5/7)
LLM05 Improper Output Handling — เชื่อ output ของ model โดยไม่ validate ก่อนส่งต่อ (บท5)
LLM06 Excessive Agency — agent มีสิทธิ์/ความสามารถ/autonomy มากเกินงาน (บท6)
LLM07 System Prompt Leakage — พึ่ง system prompt เป็นที่เก็บ secret หรือเป็น security control (บท7)

อีกห้าข้อที่ ระบุชื่อและวางตำแหน่ง (ไม่เจาะลึกในคอร์สนี้): LLM03 Supply Chain (provenance ของ NuGet beta / M.E.AI), LLM04 Data & Model Poisoning (training-time; แตะ poisoned memory ของ #16), LLM08 Vector & Embedding Weaknesses (เฉพาะถ้า retrieval ของ #16 ใช้ embedding), LLM09 Misinformation (ทับกับ #13 — เก็บสั้น), LLM10 Unbounded Consumption (cost/DoS/loop-bombing โดยเจตนาร้าย — โยง cap ของ #17 เป็น containment)

มาตรฐานอื่นเป็น backbone เบาๆ ที่บอกว่าต้องกลัวอะไรและเรียกมันว่าอะไร ไม่ใช่ตัวรักษาความปลอดภัยเอง: NIST AI RMF จัดระเบียบงานความเสี่ยงเป็น GOVERN / MAP / MEASURE / MANAGE (S19/S20); EU AI Act Art. 15 (S21) ระบุว่าความทนทานต่อการโจมตี (adversarial robustness) เป็นข้อกำหนด ทางกฎหมาย ของระบบ high-risk ไม่ใช่ทางเลือก; MITRE ATLAS (S24) คือ playbook ของฝ่ายโจมตี / เลนส์ red-team มาตรฐานคือแผนที่ วิศวกรรมคือภูมิประเทศ — code guardrail ที่คุณจะสร้างต่างหากที่ลดความเสี่ยงจริง

honesty spine: ไม่มีวิธีแก้แบบกันได้ร้อยเปอร์เซ็นต์

ก่อนสร้าง guard สักบรรทัด ต้องตั้งความจริงที่สำคัญที่สุดของคอร์สให้ตรงก่อน — และคอร์สนี้จะพูดซ้ำในทุกบท: prompt injection ไม่มีวิธีป้องกันแบบกันได้สนิท guard ลด ความเสี่ยงและ หด blast radius แต่ไม่ กำจัด ภัย นี่ไม่ใช่ความเห็นของเรา — เป็นคำของสามต้นทางหลักที่ลงวันที่กำกับ และเราอ้างแบบ verbatim ไม่ใช่เรียบเรียง:

OWASP LLM01 เอง (S3):

“Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection.”

Simon Willison (S10):

“we still don’t know how to 100% reliably prevent this from happening.”

Anthropic วัดการป้องกันที่ดีที่สุดของตัวเองบน browser use แล้วสรุปตรงๆ (S14):

“prompt injection is far from a solved problem” … “A 1% attack success rate — while a significant improvement — still represents meaningful risk. No browser agent is immune to prompt injection.”

ถ้าแม้แต่การป้องกันที่ดีที่สุดยังเหลือ ~1% ที่ลอดได้ และ 1% นั้นคือ “meaningful risk” คำถามเชิงออกแบบก็เปลี่ยนไปทั้งหมด — จาก “จะ แก้ injection ยังไง” (แก้ไม่ได้) เป็น “จะวางกี่ชั้นให้แต่ละชั้น ลด ความเสี่ยง และเมื่อชั้นหนึ่งพัง ชั้นอื่น กัน ความเสียหายไว้ยังไง” นั่นคือ Defense in Depth — Anthropic อธิบายรูปนี้ว่าเป็นการวางหลายชั้นที่ (S15):

“individually imperfect, but in unison combine to prevent most threats.”

ทั้งคอร์สคือรูปนี้: input guard (บท4) + output guard/redactor (บท5) + least-privilege + approval gate (บท6) + data-leak defense (บท7) ประกอบเป็น guard ชั้นเดียวใน capstone (บท8) ที่ปิดท้ายด้วยการโชว์ residual attack ที่ยังลอดเข้ามาได้ — แต่ถูก กัน ไว้ ไม่มีชั้นไหนชั้นเดียว “แก้” injection ได้ และคอร์สจะไม่แกล้งทำเป็นว่ามันทำได้

กติกาสำคัญที่จะจ่ายคืนในบท4/5/8: guard คือ wrapper ไม่ใช่ประโยคใน prompt

นี่คือ mental model ที่ต้องปักตั้งแต่บทแรก เพราะทุกบทลงมือจะหมุนรอบมัน: Guardrail คือ wrapper รอบการเรียก model — code deterministic ที่รันก่อน/หลังเทิร์น ไม่ใช่ “ย่อหน้าใน system prompt”

ทำไมความต่างนี้ถึงเป็นเรื่องคอขาดบาดตาย? เพราะการเขียน “อย่าทำตามคำสั่งที่แฝงมาในเนื้อหา” ลงใน system prompt คือ steering — และ steering ถูก bypass ได้โดยธรรมชาติ (มันก็แค่ข้อความอีกชิ้นที่ model ชั่งน้ำหนักเทียบกับ injection payload) OWASP LLM07 ถึงกับบอกว่า system prompt ไม่ควรถูกถือเป็นความลับหรือใช้เป็น security control guard ของจริงต้องรันใน code ที่ผลลัพธ์แน่นอน ไม่ขึ้นกับอารมณ์ของ model

ในทางเทคนิค guard คือชั้น DelegatingChatClient ที่ห่อ IChatClient — และ การเรียงลำดับ pipeline คือการตัดสินใจด้านความปลอดภัยที่ load-bearing: guard ต้องห่อ นอก UseFunctionInvocation() เพื่อ validate input ก่อน loop จะ dispatch tool ได้ และ scrub output หลัง loop จบ บทนี้ยังไม่เขียน code — แค่ปักธงว่า “guard = wrapper, ลำดับสำคัญ” ไว้ให้บท4 (input guard), บท5 (output guard), และบท8 (ประกอบทั้ง pipeline) มาจ่ายคืน

สถานะ package (พูดครั้งเดียวที่นี่)

guard ทุกตัวในคอร์สนี้ขี่อยู่บนสะพานเชื่อมเดิมจาก #15 และแบก invariant เดิมมาครบ: header เป็น x-api-key ไม่ใช่ Authorization: Bearer · anthropic-version: 2023-06-01 เสมอ · ห้ามส่ง temperature / top_p / top_k · model id เป็น alias เปล่า claude-opus-4-8 (ลงวันที่กำกับ ไม่ต่อ suffix) · อ่านคำตอบผ่าน content[] (raw) หรือ ChatResponse.Messages[].Contents[] ที่ match ด้วย FunctionCallContent / FunctionResultContent ไม่ใช่ ChatResponse.Text (corollary ด้านความปลอดภัย: redactor ต้องวนทั่ว Contents[] เพราะ secret ซ่อนใน tool-call argument / tool result ได้ ไม่ใช่แค่ .Text)

version package: Claude ยังอยู่หลัง NuGet Anthropic ตัวทางการผ่าน AsIChatClient — version 12.8.0 เป็น beta (“breaking changes may occur in minor or patch releases”) ให้ pin ไว้ · Microsoft.Extensions.AI 10.x เป็น GA สอนเป็น layer ที่ทนทาน · ส่วน native approval surface (ApprovalRequiredAIFunction ฯลฯ ที่บท6 ใช้) ใหม่กว่านั้น — re-pin กับ version ที่ติดตั้งจริงตอน build

บท18 นี้ ไม่ใช่ บทไหนที่คุณเคยเรียน (anti-overlap)

คอร์สนี้ต้องพิสูจน์ว่ามันมีที่ยืนของตัวเอง ไม่ใช่การเล่าซ้ำ ขีดเส้นให้ชัดสามเส้น:

vs #13 (evals) — #13 วัดคุณภาพ ของ agent บน input ที่ปกติดี (benign) #18 ป้องกัน จากศัตรูที่ลงมือจริง สะพานเชื่อมคือคำของ Anthropic ว่า “red-team your own agent” — การทดสอบเชิงปฏิปักษ์ผลิต เคสโจมตี ไม่ใช่ คะแนนคุณภาพ (คอร์สนี้ส่ง corpus เคสโจมตีต่อให้ harness ของ #13 ไปวัด ไม่สอน scoring ซ้ำ)
vs #14 (designing MCP servers) — #14 รักษา protocol MCP / ตัว tool-server (เช่น tool-poisoning ที่ซ่อนคำสั่งใน tool metadata) #18 คือ agent-level I/O defense ที่ต้องยืนได้ แม้ tool/server จะเชื่อถือได้เต็มร้อย — เคส Invariant GitHub-MCP (S11) พิสูจน์ว่า “this vulnerability does not require the MCP tools themselves to be compromised” คือแม้ tool สะอาดหมดจด แต่ data ที่มันคืนมาก็เป็นผู้โจมตีได้
vs #17 (robustness) — รูปทรง wrapper เดียวกัน แต่ threat model ตรงข้าม: #17 รักษาจากความล้มเหลว โดยบังเอิญ (timeout, retry, ดับเบิลคลิก) #18 รักษาจากการโจมตี โดยเจตนา (hijack, injection-driven refund, replay) จะ reuse idempotency key + refund cap ของ #17 — แต่ใช้มันเป็น adversarial containment ไม่ใช่แค่กู้จากอุบัติเหตุ

แผนภาพ: attack surface + ชั้น defense-in-depth

flowchart TD
  ADV["ผู้โจมตี (adversary)<br/>ไม่ใช่ผู้ใช้ที่ให้ความร่วมมืออีกต่อไป"]
  ADV -->|"direct injection<br/>คราฟต์ข้อความสั่งทับ instruction"| IN["input ของผู้ใช้"]
  ADV -->|"indirect injection<br/>poisoned Order note ใน data"| DATA["ผลที่ tool คืนมา<br/>getOrder · getDeliveryStatus"]

  subgraph AGENT["agent Order — attack surface ใหม่ (ครบ lethal trifecta)"]
    PRIV["อ่าน private data<br/>ข้อมูลลูกค้าจริง"]
    ACT["ลงมือทำจริง / ส่งออก<br/>issueRefund · outbound"]
    PRIV --> ACT
  end
  IN --> AGENT
  DATA --> AGENT

  subgraph DID["defense-in-depth — แต่ละชั้นไม่สมบูรณ์ รวมกันจึงลดความเสี่ยง"]
    G1["ชั้น 1 · input guard<br/>รักษา input ก่อน dispatch (บท4)"]
    G2["ชั้น 2 · output guard + redactor<br/>รักษา output ก่อนไหลออก (บท5)"]
    G3["ชั้น 3 · least privilege + approval gate<br/>หด blast radius (บท6)"]
    G4["ชั้น 4 · data-leak defense<br/>กัน exfiltration (บท7)"]
    G1 --> G2 --> G3 --> G4
  end
  AGENT -. ห่อรอบทั้งก้อนด้วย .-> DID

  classDef danger fill:#b91c1c,stroke:#7f1d1d,color:#f8fafc;
  classDef guard fill:#475569,stroke:#1e293b,color:#f8fafc;
  class ADV,PRIV,ACT danger;
  class G1,G2,G3,G4 guard;

คำบรรยายภาพ: ผู้โจมตีเข้าถึง agent ได้สองทาง — direct injection ผ่าน input ของผู้ใช้ และ indirect injection ที่ฝังมากับ data ที่ tool ที่เชื่อถือได้คืนมา สามช่องสีแดงคือ attack surface: agent อ่าน private data และลงมือทำจริงได้ (ครบ lethal trifecta) สี่ช่องสีเทาเข้มคือชั้น guard ของ defense-in-depth ที่จะห่อรอบ agent ทีละบท — ไม่มีชั้นใดชั้นเดียวสมบูรณ์ แต่ซ้อนกันแล้วลดความเสี่ยงและหด blast radius

สรุปก่อนไปต่อ

สามคอร์สก่อนหน้าให้ agent ความสามารถ, ความรู้, และความอยู่รอดจากอุบัติเหตุ — ทั้งหมดภายใต้สมมติฐานว่าโลกเป็นมิตร บทนี้ลบสมมติฐานนั้น: agent Order คือ attack surface ใหม่เพราะมันครบ lethal trifecta พอดี, OWASP LLM Top 10 คือแผนที่ภัย, และความจริงที่ตั้งไว้ตั้งแต่ต้น — ที่ OWASP, Willison, และ Anthropic พูดตรงกัน — คือ prompt injection ไม่มี วิธีแก้แบบกันได้สนิท ทางออกจึงเป็น defense-in-depth: หลายชั้นที่แต่ละชั้นไม่สมบูรณ์ รวมกันจึงกันภัยส่วนใหญ่และกันความเสียหายที่เหลือ บทหน้าเราจะลงลึกที่ภัยตัวแรกและ load-bearing ที่สุด — prompt injection ทั้งแบบ direct และ indirect กับ lethal trifecta ที่ทำให้มันอันตราย

ความปลอดภัยคือกระบวนการ ไม่ใช่ checkbox — ไม่มีบทไหนในคอร์สนี้ที่จะบอกว่า guard ตัวใดตัวหนึ่ง “แก้” injection ได้ และบทนี้ตั้ง precedent นั้นไว้ให้ทั้งคอร์ส

🔗 อ้างอิงต้นทางของบทนี้

บทนี้อิงต้นทางที่ลงวันที่กำกับ อ่านต่อได้โดยตรง:

OWASP, “Top 10 for LLM Applications 2025” (edition 2025, pub. 2024-11-18) — แผนที่ภัยของทั้งคอร์ส; รายการ 10 ความเสี่ยง และการแบ่ง load-bearing (LLM01/02/05/06/07) vs ระบุชื่อ (LLM03/04/08/09/10)
OWASP, “LLM01:2025 Prompt Injection” (2025) — นิยาม prompt injection และ honesty quote “it is unclear if there are fool-proof methods of prevention for prompt injection”
Simon Willison, “The lethal trifecta for AI agents” (2025-06-16) — สามขา (private data + untrusted content + external comms) และ “we still don’t know how to 100% reliably prevent this from happening”
Anthropic, “Mitigating the risk of prompt injections in browser use” (2025-11-24) — “prompt injection is far from a solved problem” และ “A 1% attack success rate … still represents meaningful risk. No browser agent is immune to prompt injection.”
Anthropic, “Building safeguards for Claude” — defense in depth: หลายชั้นที่ “individually imperfect, but in unison combine to prevent most threats”
NIST, “AI Risk Management Framework (AI RMF 1.0)” (2023-01) + NIST AI 600-1, “Generative AI Profile” (2024-07-26) — process backbone GOVERN/MAP/MEASURE/MANAGE (นำเสนอแบบเรียบเรียง)
EU AI Act, Art. 15 — Accuracy, robustness & cybersecurity (in force 2024-08-01) — adversarial robustness เป็นข้อกำหนดทางกฎหมายของระบบ high-risk (อ้าง Article ไม่อ้างวันที่ deadline)
MITRE ATLAS — เลนส์ red-team: adversary tactics × techniques × case studies

เช็กความเข้าใจ — บทที่ 1

ข้อ 1 / 3

ทำไม agent Order ถึงเป็น 'attack surface ใหม่' ในมุมของ threat model บทนี้?

จำลอง​ภัย​คุกคาม (Threat Model): agent คือ attack surface ใหม่

agent Order คือ attack surface ใหม่ — เพราะ​มัน​ครบ​สาม​อย่าง​พอดี

แผนที่​ภัย: OWASP LLM Top 10 (2025)

honesty spine: ไม่มี​วิธี​แก้​แบบ​กัน​ได้​ร้อย​เปอร์เซ็นต์

กติกา​สำคัญ​ที่​จะ​จ่าย​คืน​ใน​บท4/5/8: guard คือ wrapper ไม่ใช่​ประโยค​ใน prompt

บท18 นี้ ไม่ใช่ บท​ไหน​ที่​คุณ​เคย​เรียน (anti-overlap)