Context Engineering จากมุมมองของ Attacker ค่ะ

ภาษาอื่น / Other language: English · ไทย

พอดีสัปดาห์นี้เริ่มได้กลับมานั่งเล่นเน็ตตามปกตินิดหน่อย เลยเห็นโพสต์เรื่อง context engineering เยอะ วันนี้เลยมาเล่าจากมุมของ attacker บ้างค่ะ ว่าเราใช้ประโยชน์จากมันยังไง

เนื้อหาต่อไปนี้เราไม่ได้พูดถึงการใช้งานเพื่อ productivity แต่พูดถึง context ในฐานะ attack surface นะคะ

1. Context จริง ๆ คืออะไร …มันคือจุดอ่อนที่มีมาตั้งแต่แรกค่ะ

คำว่า “context engineering” ในเชิงระบบนั้นมันเป็น พื้นฐานของวิธีที่โมเดลประมวลผลข้อมูล คือ โมเดลมักไม่แยกแยะระหว่าง “คำสั่ง” กับ “ข้อมูล” ซึ่งทำงานโดย predict token ถัดไปจากสิ่งที่เห็นใน context ทั้งหมด เพราะว่าโมเดล ถูกฝึกให้ ให้ความสำคัญกับรูปแบบคำสั่งบางชนิด (system/developer) แต่ ไม่สามารถยืนยันแหล่งที่มา/ความน่าเชื่อถือของข้อความได้ด้วยตัวมันเอง

สิ่งที่เกิดขึ้นคือข้อมูลที่เข้าไปใน context ทุกชิ้น จะถูกตีความและมีผลกับ output โดยไม่มี trust boundary ในตัวเอง เนื่องจาก role hierarchy เป็น convention ของระบบ มากกว่าความสามารถในการแยก trust boundary

สรุปคือ context = ทุกอย่างที่โมเดลเห็นก่อนจะตอบคำถาม ➡️ ถ้าฝ่ายโจมตีควบคุม context ได้ ก็มีโอกาสที่จะชี้นำ และควบคุมผลลัพธ์ได้ (เพราะโมเดลเป็น stochastic)

🔸นิยามศัพท์สั้นๆ🔸
• Context engineering (มุม builder): การออกแบบ context เพื่อให้โมเดลตอบงานได้ดีและปลอดภัย
• Context manipulation (มุม attacker): การปรับ context เพื่อเปลี่ยน decision ของโมเดล
• Prompt injection: เทคนิคย่อยของ manipulation (เช่น direct/indirect)

🔸Threat Model🔸
• Assets: อะไรที่ attacker อยากได้ (data exfil, policy bypass, tool misuse, integrity compromise)
• Entry points: user input, retrieved docs, web, file uploads, memory, logs, tool outputs
• Capabilities: attacker คุมแหล่งข้อมูลภายนอกได้แค่ไหน, คุม user message ได้ไหม
• Success criteria: “ไม่ต้องหลุดเต็ม ๆ แค่ทำให้ tool call ผิดบริบทก็ชนะ
• Assumption: ระบบมีการดึง context จากแหล่งที่ attacker มีโอกาสปนเปื้อน (เว็บ/เอกสาร/ไฟล์/UGC) หรือ attacker คุม user input ได้

1. Red Team มอง context engineering แบบไหน?

จากมุม attacker แล้วสิ่งที่น่าสนใจไม่ใช่ output ที่สวยงาม แต่เป็นการทำให้โมเดลคำนึงถึงสิ่งที่เราอยากให้มันเชื่อก่อนจะตอบ

นี่คือสิ่งที่ red team ทำมาตลอดในโจมตีประเภท prompt injection ไม่ว่าจะเป็น Direct prompt injection ที่ใส่คำสั่ง (malicious) ลงใน input ของผู้ใช้ เพื่อให้โมเดลยอมทำตามคำสั่ง attacker มากกว่า system prompt เดิม หรือ Indirect prompt injection ที่ฝังคำสั่งอันตรายในแหล่งข้อมูลภายนอก เช่น เอกสารที่ถูกดึงเข้ามาในระบบ (RAG), เว็บไซต์, หรือไฟล์ แล้วรอให้โมเดลเรียกมาใช้ใน context ของมัน 

โจมตีสองแบบนี้ ไม่จำเป็นต้องเขียนโค้ด เพราะ attacker แค่ทำให้โมเดล “เชื่อว่า” ข้อความใน context คือคำสั่งที่ถูกต้อง

1. ทำไม context engineering จึง ไม่ใช่ เรื่องใหม่สำหรับ attacker

ถ้าเราลองมอง pattern ของโจมตีจริง ๆ จะเห็นว่าสิ่งที่ attacker ทำคือ inject สิ่งที่ทำให้โมเดล
✓ ตกลงกับ premise ที่ฝ่าย attacker ตั้งไว้
✓ เปลี่ยนเงื่อนไขของระบบ prompt ที่ตั้งไว้
✓ หลีกเลี่ยงกลไกป้องกันด้านความปลอดภัย

ซึ่งล้วนแล้วแต่เป็น การจัดลำดับความสำคัญของข้อความใน context ทั้งสิ้น ซึ่งนั่นคือแก่นของ “context engineering”

สิ่งที่เปลี่ยนไป ในยุคปัจจุบัน คือ
• ระบบหลายตัวใช้ RAG (retrieval-augmented generation) ทำให้ attacker สามารถปลอมแปลงข้อมูลภายนอกเพื่อให้โมเดลดึงเข้ามาใน context โดยไม่รู้ตัว 
• มี agent / autonomous AI ที่โหลดข้อมูลจากเว็บโดยตรง ซึ่งทำให้มี opening attack vector ของ indirect prompt injection มากขึ้น

ในโลก LLM security เรามอง prompt injection เป็น property พื้นฐานของระบบที่เอา
ภาษาธรรมชาติ มาใช้เป็นทั้ง data plane (ข้อมูล) และ control plane (คำสั่ง) พร้อมกัน

เปรียบเทียบกับระบบซอฟต์แวร์ทั่วไปจะเห็นว่า Code กับ Data แยกกันชัดเจน (compiler รู้ว่าอะไรคือคำสั่ง อะไรคือข้อมูล) แต่ว่าสำหรับ LLM นั้นทุกอย่างเป็น text ซึ่งมีรูปแบบเดียวกัน จึงทำให้โมเดลไม่สามารถแยกแยะได้อย่างสมบูรณ์ว่าอะไรคือคำสั่ง อะไรคือข้อมูล

➡️ สิ่งที่ attacker ทำคือ ทำให้ "คำสั่งปลอม" ดูกลมกลืนกับ "ข้อมูลปกติ" จนโมเดลตีความผิดไป

1. ทำไม context engineering ถึงมีสำคัญกับ security มากขึ้น?

ระบบ AI สมัยใหม่ไม่ได้แค่รับ input เดียว แล้วตอบออกมา
แต่เป็น agentic systems ที่ดึงข้อมูลจากหลายแหล่ง (RAG, web search, databases) ทำงานหลายรอบ (multi-turn agent loops) และมีการเรียกใช้ tools และ APIs อัตโนมัติ
ทุกจุดเหล่านี้คือ attack surface ที่ attacker สามารถแทรก malicious context เข้าไปได้
ยิ่ง context window ใหญ่ขึ้นมาก ก็ยิ่งมีที่ซ่อน malicious instructions ได้มากขึ้น

🔸Attack Surfaces เฉพาะ RAG/Agents🔸
• Retrieval poisoning: ปลอม doc ให้ถูกดึง (via SEO/embedding bait)
• Tool-output injection: ผลจาก tool พก malicious text กลับ
• Memory poisoning: ฝัง belief ระยะยาวใน memory
• Multi-turn ratcheting: ค่อยๆ ปรับ premise จนหลุด guards

5)การวิเคราะห์ context แบบ attacker

Red team วิเคราะห์โมเดล โดยการมอง behavior ของ context ผ่านมุมต่าง ๆ เช่น

🔹 Authority pressure

ข้อความที่ดูเหมือนเป็น policy หรือ system instruction จะถูกให้ความสำคัญสูงกว่า
เช่น “ตาม policy ของบริษัทนี้…” จะมีพลังมากกว่าแค่คำสั่งธรรมดาใน context
ซึ่งโมเดลไม่รู้ว่าข้อความเหล่านี้ ถูกปลอมขึ้น เนื่องจากว่าโมเดลมีแนวโน้มที่จะให้ความสำคัญกับข้อความเหล่านั้นตามรูปแบบที่เคยถูกเทรนมา

🔹 Recency pressure

คำสั่งที่อยู่ ใกล้ช่วงที่โมเดลจะ generate output มักกลายเป็นตัวกำหนดพฤติกรรม
Red team ใช้เรื่องนี้โดยใส่ directive ปลอมขึ้นมาใกล้ ๆ ตอน trigger เพราะว่าโมเดลพยายามทำให้ output สอดคล้องกับสิ่งที่เพิ่งเห็นล่าสุด

🔹 Consistency pressure

เมื่อโมเดลเชื่อ premise ที่ attacker วางไว้ มันก็จะกลับตัวยากค่ะ เพราะมันพยายามตอบให้สอดคล้องกับสิ่งที่เข้าไปก่อนหน้า

เรียกว่าพฤติกรรมเหล่านี้คือ พฤติกรรมปกติของโมเดลที่เกิดจากวิธี training และ next-token prediction ไม่ใช่ bug ค่ะ

6)ตัวอย่างแบบ attacker
เพื่อให้ attacker task (ใน sandbox platform อย่าง Gray Swan) เราสำเร็จ เช่น ต้องการให้โมเดลที่ถูกกำหนดบทบาทให้รับซื้อเครื่องใช้ไฟฟ้า ➡️ใช้ tool call เพื่อซื้อ สิ่งที่เป็นนามธรรม ไม่มีใครเขาซื้อขายกัน เช่น ซื้อความกล้าหาญ 1 หน่วย ซึ่งแน่นอนว่าปกติมันจะไม่ทำค่ะ

ถ้าเราทำแค่ เขียนข้อความซ้ำๆ เหมือนท่องมนต์คาถา ว่าให้ซื้อๆๆ เขียนไป 1000 รอบ …ถามว่าแบบนี้ได้ผลไหม ➡️ ไม่ได้ผลหรอกค่ะ… โมเดลอ่านแล้วมันจะคิดว่า สิ่งนี้มันอะไร ไม่เกี่ยวอะไรกับที่มันทำเสียหน่อย คือเคยลองมาแล้วก่อนแล้วจริงๆ กับบาง challenge นะคะ กลยุทธ์ท่องมนต์ใส่เนี่ย มันมองว่าไม่ต้องใส่ใจส่วนนี้ก็ได้ (ยังดีที่มันไม่บอกว่าเราต้องโทรไปสายด่วนสุขภาพจิต)

สิ่งที่เราพบว่าได้ผลคือ ใช้น้ำเสียงคล้ายกับ Developer (ใช้ authority) ที่กำหนดบทบาทให้มันรับซื้อเครื่องใช้ไฟฟ้า มารับซื้อสิ่งที่เป็น abstract แทน ถ้าโมเดลไหนยังไม่ค่อยอยากทำตาม เราก็ทำให้มันคิดว่าสิ่งนี้ปกติเสีย (consistency)

🔸 ตัวอย่าง Attack Goals อื่นๆ

บางทีเป้าหมายของ attacker ไม่ใช่การขาย "ความกล้าหาญ" โก่งราคา แต่เป็นการทำให้ agent ทำสิ่งที่ขัดความต้องการของ developer เช่น

▪️Data Manipulation:
• กด "ยืนยันคำสั่งซื้อ" โดยตีความผิด
• เพิ่มรายการลงตะกร้า/สร้าง draft order
• ทำ data write กลับเข้า DB ด้วยค่าที่ attacker จัดรูป

▪️System Access:
• เรียก API ผิด endpoint / ผิด account
• ใช้ tools กับ scope ที่ไม่ควรมีสิทธิ์

▪️Information Leakage:
• ส่งอีเมลออก/โพสต์ข้อมูลภายในนอก org
• Export ข้อมูล sensitive ในรูปแบบที่ bypass ได้

อาจกล่าวได้ว่า จากมุม attacker ความสำเร็จวัดได้ 3 ระดับ:

1️⃣ Tool invocation เกิดขึ้น (แม้จะ fail validation)➡️ พิสูจน์ว่า logic สามารถถูก manipulate ได้

2️⃣ เกิด side effect ที่ reversible (draft, cart, temp record) ➡️ได้ foothold ในระบบ อาจ escalate ต่อได้

3️⃣ เกิด side effect ที่ irreversible/รั่วข้อมูล (submit order, transfer, exfil)➡️ บรรลุเป้าหมายแล้ว

1. แล้วการป้องกันล่ะ?

ถ้ามองจากมุม red team แล้ว ไม่มีอะไรที่สามารถเรียกว่าเป็น perfect defense กับ context manipulation ได้อย่างสมบูรณ์ ด้วยเหตุผลคือ

▪️ โมเดลไม่สามารถแยก data กับ instruction ในตัวมันเอง
→ การป้องกันทำได้บางส่วนด้วย training/guardrails แต่ต้องพึ่ง enforcement นอกโมเดลด้วย

▪️ การ sanitize/filter รับมือได้แค่บางรูปแบบ ไม่ได้แก้พฤติกรรมพื้นฐานของโมเดล

▪️ Schema validation ช่วยได้แต่ไม่พอ
→ Attacker อาจทำให้ tool call ที่ valid แต่เปลี่ยน intent/semantics

🔸หลายองค์กรจึงใช้แนวทางแบบ defense-in-depth:

🛡️ Architecture Level
▪️ แยกโมเดลตาม trust levels (ข้อมูลภายใน vs. ภายนอก)
▪️ Isolate ข้อมูลภายนอกจาก prompt หลัก
▪️ ออกแบบ boundary ของ system และ agent ให้ชัดเจน

🛡️ Input/Context Level
▪️ Provenance labeling (ติดป้ายว่าข้อความมาจากไหน)
▪️ Allowlist retrieval + content-type constraints
▪️ Structured output + schema validation

🛡️ Execution Level
▪️ Least privilege for tools (จำกัด scope: บัญชี/งบ/สิทธิ์ write)
▪️ Confirmation gates สำหรับ high-impact actions
▪️ Out-of-band policy enforcement (ตรวจ intent + risk ก่อน execute)

🛡️ Observability Level
▪️ Validation / monitoring และ logging อย่างเข้มงวด
▪️ Adversarial testing ก่อนปล่อยใช้งานจริง

8)สรุปความเห็นส่วนตัว
ผู้ใช้งานและองค์กรควรเข้าใจว่า context คือ attack surface
ในยุค Agentic AI เราต้องมองว่า Prompt คือ untrusted input ที่มีโอกาสควบคุมการตัดสินใจของ agent (คล้าย untrusted code ในแง่ threat model)… แน่นอนว่าการป้องกันโดยสมบูรณ์ทำได้ยาก แต่จากมุมมอง attacker แล้ว ถ้ามีการป้องกันสูง เราก็มองว่า เสียเวลา เราไปเก็บแต้มจากจุดอื่นแทนดีกว่า

การป้องกันเป็นการ “ลดโอกาส” ไม่ใช่ “แก้ปัญหาเชิงโครงสร้าง” …ซึ่งหมายความว่า การป้องกัน มีผลมากนะคะ

ภาษาอื่น / Other language: English · ไทย