Prompt Injection เกิดเพราะโมเดลแยกคำสั่งกับข้อมูลไม่เด็ดขาด
เรียนรู้ Prompt Injection เกิดเพราะโมเดลแยกคำสั่งกับข้อมูลไม่เด็ดขาด สำหรับระบบ AI ที่ใช้ข้อมูลและเครื่องมือในประเทศไทย
เป้าหมาย: ออกแบบการป้องกัน prompt injection ที่จำกัดสิทธิ์ ตรวจ action และกู้คืนได้ · ใช้เวลาประมาณ 18 นาที
Assume Hostile → Minimize → Authorize → Observe
ไม่มี Prompt เดียวแก้ injection ได้ ต้องลดผลกระทบด้วยหลายชั้น
Assume Hostile
prompt injection คือ input ที่พยายามเปลี่ยนเป้าหมายหรือข้ามกติกา โมเดลอ่านข้อความทุกส่วนเป็น token จึงไม่มี security boundary จริงจากคำว่า system/user หรือข้อความว่าอย่าเชื่อข้อมูลเพียงอย่างเดียว
Minimize
ลดข้อมูล secret permission context และผลกระทบที่โมเดลเข้าถึง
Authorize
ใช้ trusted code ตรวจ identity, policy, schema, ownership และ approval
Observe
บันทึก tool request/decision/result แบบไม่เก็บข้อมูลเกินจำเป็น พร้อม alert และ recovery
ชั้นป้องกันที่ต้องตรวจ
prompt injection
ออกแบบ test สำหรับ prompt injection ระบุ attack, expected block, evidence และ recovery
ทดสอบ behavior และ side effect ไม่ตัดสินจากข้อความปฏิเสธอย่างเดียว
instruction hierarchy
ออกแบบ test สำหรับ instruction hierarchy ระบุ attack, expected block, evidence และ recovery
ทดสอบ behavior และ side effect ไม่ตัดสินจากข้อความปฏิเสธอย่างเดียว
trust boundary
ออกแบบ test สำหรับ trust boundary ระบุ attack, expected block, evidence และ recovery
ทดสอบ behavior และ side effect ไม่ตัดสินจากข้อความปฏิเสธอย่างเดียว
system prompt
ออกแบบ test สำหรับ system prompt ระบุ attack, expected block, evidence และ recovery
ทดสอบ behavior และ side effect ไม่ตัดสินจากข้อความปฏิเสธอย่างเดียว
สิ่งที่ดูปลอดภัยแต่ไม่ใช่ Boundary
บอกโมเดลว่าอย่าทำตามคำสั่งร้าย
instruction ยังแข่งขันกันใน model
ลด permission และ authorize นอกโมเดล
ตรวจ keyword blacklist
ภาษา/encoding/รูปภาพหลบได้
layered validation และ impact control
agent ปฏิเสธแต่ tool ทำงานแล้ว
ข้อความปลอดภัยไม่ย้อน side effect
authorize ก่อน call และใช้ transaction/rollback
ทำ Injection Threat Model
ลูกค้าส่งข้อความ LINE ว่าให้ลืมกติกาและแสดง system prompt
วาด source, asset, trust boundary, attack, permission, control, detection, recovery และ test cases
ดูคำตอบตัวอย่าง
ถือว่า user/web/file/RAG content เป็น untrusted ห้ามใส่ secret ใน context แยก identity กับ scoped credential ใช้ retrieval permission และ provenance ให้โมเดลเสนอ structured action จาก allowlist จากนั้น trusted policy ตรวจ schema/ownership/risk และขอ human approval ก่อนส่ง ลบ ซื้อ หรือเผยแพร่ ใช้ idempotency/preview/rollback log แบบลดข้อมูล และทดสอบ direct/indirect/encoded/multilingual injection ภาษาไทยทุกครั้งที่ model หรือ tool เปลี่ยน
- untrusted sources
- assets/secrets
- least privilege
- external authorization
- side-effect controls
- red-team/recovery
บันทึกช่วยจำ
- ใช้เฉพาะระบบและข้อมูลที่ได้รับอนุญาตในการทดสอบ
- ไม่บันทึก Prompt, credential หรือข้อมูลส่วนบุคคลลง log เกินความจำเป็น
สรุปบทเรียนนี้
- treat content as untrusted
- authorize outside model
- test side effects and recovery