ความปลอดภัย LLM ไม่ใช่แค่เรื่องการบล็อก prompt ที่ไม่ปลอดภัยอีกต่อไป เมื่อ LLM กลายเป็นส่วนหนึ่งของเวิร์กโฟลว์ agentic มันอาจดึงเอกสาร, เรียก API, อัปเดตระเบียน หรือทริกเกอร์กระบวนการธุรกิจ นั่นเปลี่ยนโมเดลความปลอดภัยจาก “ปกป้องแชท” เป็น “ปกป้องระบบของการกระทำรอบโมเดล”
หากทีมของคุณกำลังวางแผน agentic AI ในการผลิต ที่กว้างขึ้น ความปลอดภัย LLM ควรถูกปฏิบัติเป็น release gate ไม่ใช่ checklist สุดท้าย สำหรับทีม EU/US นั่นหมายถึงการคิดเกี่ยวกับ prompt injection, การเข้าถึงเครื่องมือที่ปลอดภัย, ที่อยู่ข้อมูล, การตรวจสอบย้อนได้, การกำกับดูแลโดยมนุษย์, การทดสอบ และการตรวจสอบการผลิตก่อนเปิดตัว
ความเสี่ยงไม่ใช่ทางทฤษฎีอีกต่อไป Stanford HAI’s 2025 AI Index รายงานเหตุการณ์ที่เกี่ยวข้องกับ AI 233 ครั้งในปี 2024 สูงเป็นประวัติการณ์และเพิ่ม 56.4% จากปี 2023 รายงานต้นทุนการละเมิดข้อมูลปี 2025 ของ IBM ยังพบว่า 13% ขององค์กรรายงานการละเมิดที่เกี่ยวข้องกับโมเดลหรือแอปพลิเคชัน AI ในบรรดาที่ถูกโจมตี 97% ขาดการควบคุมการเข้าถึง AI ที่เหมาะสม
คู่มือนี้แยกการควบคุมที่ปฏิบัติได้ที่ทีมต้องเพื่อปล่อย agent ที่ขับเคลื่อนด้วย LLM อย่างปลอดภัย
ข้อความสำคัญ
- ความปลอดภัย LLM ครอบคลุม prompt, เครื่องมือ, ข้อมูล, logs, มนุษย์, ผู้ให้บริการ และการตรวจสอบ
- Agentic AI เพิ่มความเสี่ยงความปลอดภัยเพราะมันสามารถดำเนินการ ไม่ใช่แค่สร้างข้อความ
- Prompt injection ต้องการการป้องกันเป็นชั้น ไม่ใช่ system prompt ที่แข็งแกร่งกว่าเพียงอย่างเดียว
- secure tool calling ขึ้นอยู่กับสิทธิ์น้อยที่สุด, การตรวจสอบ, sandboxing และ audit logs
- ที่อยู่ข้อมูลต้องถูกออกแบบเข้าไปในสถาปัตยกรรมสำหรับการปรับใช้ EU/US
- การควบคุม HITL ควรเป็นตามความเสี่ยง, ตรวจสอบย้อนได้ และปฏิบัติได้จริงในการดำเนินงาน
- การทดสอบและการตรวจสอบต้องดำเนินต่อหลังการปล่อยสู่การผลิต
ความปลอดภัย LLM หมายถึงอะไรสำหรับ Agentic AI
ความปลอดภัย LLM กว้างกว่าความปลอดภัย prompt
ความปลอดภัย LLM เป็นแนวปฏิบัติของการปกป้องระบบที่ขับเคลื่อนด้วย LLM จากการรั่วไหลของข้อมูล, prompt injection, การใช้เครื่องมือโดยไม่ได้รับอนุญาต, ผลลัพธ์ที่ไม่ปลอดภัย และความล้มเหลวในการปฏิบัติตามข้อกำหนด
สำหรับแชทบอทแบบง่าย ความปลอดภัยอาจมุ่งเน้นที่ prompt, ผลลัพธ์ และข้อมูลผู้ใช้เป็นหลัก สำหรับระบบ agentic AI ขอบเขตกว้างกว่า ระบบอาจรวมถึง:
- โมเดลหนึ่งหรือหลายโมเดล
- System prompt และนโยบาย
- RAG pipeline, ระบบ agentic RAG และ vector database
- LLM gateway สำหรับ multi-provider routing, fallback และ centralized governance
- API และเครื่องมือธุรกิจ
- หน่วยความจำหรือบริบทเซสชัน
- ระบบ logs และการตรวจสอบ
- เวิร์กโฟลว์การอนุมัติโดยมนุษย์
- ผู้ให้บริการโมเดลหรือโครงสร้างพื้นฐานของบุคคลที่สาม
แอปพลิเคชัน LLM ที่ปลอดภัยไม่ใช่แค่ prompt ที่ปลอดภัย แต่เป็นสถาปัตยกรรมที่ปลอดภัยรอบโมเดล
ทำไมระบบ agentic ยกระดับความเสี่ยง
Agentic AI เปลี่ยนโปรไฟล์ความเสี่ยงเพราะโมเดลสามารถมีอิทธิพลต่อการกระทำ แทนที่จะตอบคำถามเพียงอย่างเดียว agent อาจ:
- ค้นหาเอกสารภายใน
- เรียก CRM API
- อัปเดตตั๋ว
- ทริกเกอร์อีเมล
- สร้างโค้ด
- วิเคราะห์ระเบียนลูกค้า
- ส่งข้อมูลระหว่างเครื่องมือ
- แนะนำหรือดำเนินการขั้นตอนเวิร์กโฟลว์
นั่นหมายความว่าคำสั่งที่ไม่ดี, ผลลัพธ์การดึงที่ไม่ปลอดภัย, สิทธิ์มากเกินไป หรือชั้นการตรวจสอบที่อ่อนแอสามารถสร้างผลกระทบการดำเนินงานจริง โหมดความล้มเหลวไม่ใช่แค่ “คำตอบผิด” อีกต่อไป มันสามารถกลายเป็น “การกระทำผิดถูกดำเนินการ”
เป้าหมายความปลอดภัยสำหรับ LLM agent ในการผลิต
สำหรับ LLM agent ในการผลิต เป้าหมายความปลอดภัยควรชัดเจน อย่างน้อยทีมควรมุ่งที่:
- ป้องกันการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต
- ป้องกันการรั่วไหลของข้อมูลที่ละเอียดอ่อน
- ป้องกันการใช้เครื่องมือที่ไม่ปลอดภัยหรือไม่ได้รับอนุญาต
- รักษา audit logs สำหรับการกระทำสำคัญ
- ใช้การอนุมัติโดยมนุษย์สำหรับเวิร์กโฟลว์ที่มีความเสี่ยงสูง
- ตรวจจับพฤติกรรมผิดปกติตั้งแต่เนิ่น ๆ
- สนับสนุนการตอบสนองเหตุการณ์และ rollback
- ทำให้การเปลี่ยนแปลงโมเดล, prompt และเครื่องมือตรวจสอบย้อนได้
เป้าหมายเหล่านี้ช่วยให้ทีมความปลอดภัย, ผลิตภัณฑ์ และวิศวกรรมประเมินว่า agent พร้อมสำหรับการผลิตหรือไม่
โมเดลภัยคุกคาม: ที่ที่ LLM Agent ล้มเหลวในการผลิต
การสร้างโมเดลภัยคุกคามให้ทีมวิธีปฏิบัติในการทำความเข้าใจว่า LLM agent สามารถล้มเหลวอย่างไรก่อนที่ความล้มเหลวเหล่านั้นจะส่งผลกระทบต่อลูกค้า, พนักงาน หรือข้อมูลที่กำกับ
รายงานปี 2025 ของ IBM พบว่า 60% ของเหตุการณ์ความปลอดภัยที่เกี่ยวข้องกับ AI นำไปสู่ข้อมูลที่ถูกโจมตี และ 31% ก่อให้เกิดการรบกวนการดำเนินงาน สำหรับ agentic AI ตัวเลขเหล่านั้นสำคัญเพราะ agent ที่ถูกโจมตีสามารถส่งผลกระทบทั้งการเปิดเผยข้อมูลและความต่อเนื่องของกระบวนการธุรกิจ
ความเสี่ยงด้านการรักษาความลับ
ความเสี่ยงด้านการรักษาความลับเกิดขึ้นเมื่อข้อมูลที่ละเอียดอ่อนถูกเปิดเผยต่อผู้ใช้, เครื่องมือ, ผู้ให้บริการ, log หรือระบบ downstream ที่ผิด
ตัวอย่างทั่วไปรวมถึง:
- PII รวมอยู่ใน prompt โดยไม่จำเป็น
- Secrets หรือข้อมูลรับรองปรากฏใน logs
- การดึง RAG เปิดเผยเอกสารที่ผู้ใช้ไม่ควรเข้าถึง
- ผลลัพธ์โมเดลเปิดเผยคำสั่งระบบที่ซ่อนอยู่
- การตั้งค่าผู้ให้บริการเก็บ prompt ที่ละเอียดอ่อนนานกว่าที่คาด
- ข้อมูลภายในถูกส่งไปยังบริการภายนอกโดยไม่มีการอนุมัติชัดเจน
การควบคุมปฏิบัติเริ่มจากการจำแนกข้อมูล ทีมต้องรู้ว่าข้อมูลใดที่ agent สามารถเข้าถึง, ที่ที่ข้อมูลนั้นถูกประมวลผล และใครสามารถเห็นผลลัพธ์
ความเสี่ยงด้านความสมบูรณ์
ความเสี่ยงด้านความสมบูรณ์เกิดขึ้นเมื่อพฤติกรรม, การให้เหตุผล หรือการกระทำของ agent ถูกจัดการ
ในระบบ LLM ความเสี่ยงความสมบูรณ์มักปรากฏเป็น prompt injection ในระบบ agentic มันสามารถไปไกลกว่านั้น:
- เอกสารที่เป็นอันตรายบอก agent ให้เพิกเฉยคำสั่งก่อนหน้า
- การตอบสนองของเครื่องมือมีข้อความที่โมเดลปฏิบัติเป็นคำสั่งใหม่
- ผู้ใช้หลอก agent ให้เรียกฟังก์ชันที่ไม่ได้รับอนุญาต
- agent แก้ไขระเบียนตามข้อมูลที่ไม่ได้รับการยืนยัน
- ผลลัพธ์ RAG เปลี่ยนเส้นทางการตัดสินใจของ agent
การควบคุมความสมบูรณ์ควรมุ่งเน้นการแยกคำสั่งที่เชื่อถือได้จากเนื้อหาที่ไม่น่าเชื่อถือ, การตรวจสอบ tool calls และการใช้การตรวจสอบนโยบายก่อนการกระทำที่ละเอียดอ่อน
ความเสี่ยงด้านความพร้อมใช้งานและต้นทุน
LLM agent ยังสามารถสร้างปัญหาความพร้อมใช้งานและต้นทุน ตัวอย่างเช่น:
- agent เข้าสู่ลูปซ้ำ
- tool calls เพิ่มขึ้นอย่างไม่คาดคิด
- การใช้ token เติบโตเกินงบประมาณ
- โมเดลหรือผู้ให้บริการล่มทำลายเวิร์กโฟลว์
- input ที่ผิดรูปแบบทำให้ลองใหม่ซ้ำ
- ขั้นตอน latency สูงบล็อกกระบวนการธุรกิจ
นี่บางครั้งเรียก “denial of wallet” เมื่อการใช้โมเดลมากเกินไปสร้างต้นทุนที่ไม่คาดคิด agent ในการผลิตต้องการ rate limits, timeouts, retry limits, การควบคุมงบประมาณ และการแจ้งเตือน
ความเสี่ยงด้านการปฏิบัติตามข้อกำหนด
สำหรับการปรับใช้ EU/US ความเสี่ยงการปฏิบัติตามข้อกำหนดมักมาจากการจัดการข้อมูลที่ไม่ชัดเจนและการกำกับดูแลที่อ่อนแอ
ตัวอย่างรวมถึง:
- ไม่มีเอกสารกระแสข้อมูล
- ภูมิภาคการประมวลผลไม่ชัดเจน
- การตั้งค่าการเก็บรักษาสำหรับ prompt และ logs ที่อ่อนแอ
- ไม่มี audit trail สำหรับการกระทำที่มีความเสี่ยงสูง
- ไม่มีการกำกับดูแลโดยมนุษย์สำหรับเวิร์กโฟลว์ที่ละเอียดอ่อน
- ไม่มีการตรวจสอบผู้ให้บริการ/subprocessor
- ไม่มีแผนตอบสนองเหตุการณ์สำหรับความล้มเหลวที่เกี่ยวข้องกับ AI
ทีมความปลอดภัยและการปฏิบัติตามข้อกำหนดควรตรวจสอบความเสี่ยงเหล่านี้ก่อนเปิดตัว ไม่ใช่หลังจาก agent ฝังในเวิร์กโฟลว์ธุรกิจแล้ว
การควบคุม Prompt Injection และ Indirect Injection
Direct prompt injection
Direct prompt injection เกิดขึ้นเมื่อผู้ใช้พยายามจัดการคำสั่งของโมเดลโดยเจตนา ผู้ใช้อาจขอให้โมเดลเพิกเฉยกฎระบบ, เปิดเผยบริบทที่ซ่อนอยู่, ข้ามนโยบาย หรือดำเนินการนอกขอบเขตที่อนุญาต
สำหรับแชทบอทพื้นฐาน direct injection อาจส่งผลให้ได้คำตอบที่ไม่ปลอดภัยหรือไม่ถูกต้อง สำหรับ AI agent มันอาจนำไปสู่การใช้เครื่องมือผิด, การเปิดเผยข้อมูล หรือการดำเนินการเวิร์กโฟลว์โดยไม่ได้รับอนุญาต
OWASP ระบุPrompt Injection เป็นความเสี่ยงแอปพลิเคชัน LLM สูงสุดใน OWASP Top 10 for LLM Applications นั่นคือเหตุผลที่การทดสอบ injection ควรเป็นส่วนหนึ่งของกระบวนการปล่อยรุ่นสำหรับเวิร์กโฟลว์ LLM ใด ที่จัดการข้อมูลที่ละเอียดอ่อนหรือการกระทำธุรกิจ
Indirect prompt injection
Indirect prompt injection เกิดขึ้นเมื่อคำสั่งที่เป็นอันตรายถูกซ่อนอยู่ในเนื้อหาที่ agent อ่าน เนื้อหานี้อาจมาจาก:
- หน้าเว็บ
- อีเมล
- ไฟล์ที่อัปโหลด
- ตั๋ว
- บันทึกแชท
- ผลลัพธ์ RAG
- การตอบสนองของเครื่องมือ
- เอกสารที่แชร์
นี่สำคัญอย่างยิ่งสำหรับ agentic AI เพราะ agent มักบริโภคเนื้อหาภายนอกหรือกึ่งน่าเชื่อถือก่อนตัดสินใจว่าจะทำอะไรต่อ
ทำไม indirect injection เป็นอันตรายสำหรับ agent
Indirect injection เป็นอันตรายเพราะคำสั่งที่เป็นอันตรายไม่ได้มาจากผู้ใช้โดยตรง มันปรากฏในข้อมูลที่ agent ถูกขอให้ประมวลผล
ตัวอย่างเช่น agent อาจอ่านตั๋วสนับสนุนที่มีคำสั่งที่ซ่อนอยู่บอกให้เปิดเผยนโยบายภายใน, เปลี่ยนฟิลด์ลำดับความสำคัญ หรือเรียกเครื่องมืออื่น หากระบบปฏิบัติต่อเนื้อหาที่ดึงมาเป็นคำสั่งที่เชื่อถือได้ agent อาจปฏิบัติตาม
หลักการหลักง่าย ๆ: เนื้อหาภายนอกควรถูกปฏิบัติเป็นข้อมูล ไม่ใช่อำนาจ
การควบคุมการป้องกัน
การบรรเทา prompt injection ควรใช้การควบคุมเป็นชั้น:
- แยกคำสั่งระบบจากเนื้อหาผู้ใช้และเครื่องมือ
- ปฏิบัติต่อเอกสารที่ดึงมาเป็นข้อมูลที่ไม่น่าเชื่อถือ
- ใช้ tool allowlists แทนการเข้าถึงเครื่องมือแบบเปิด
- ตรวจสอบอาร์กิวเมนต์เครื่องมือฝั่งเซิร์ฟเวอร์
- ต้องการผลลัพธ์ที่มีโครงสร้างสำหรับ tool calls
- เพิ่มการตรวจสอบนโยบายก่อนการกระทำที่ละเอียดอ่อน
- จำกัดสิทธิ์ของ agent ตามบทบาทและเวิร์กโฟลว์
- ฆ่าเชื้อหรือแยกเนื้อหาภายนอกก่อนใช้
- เพิ่มประตูอนุมัติสำหรับการกระทำที่มีผลกระทบสูง
- ตรวจสอบรูปแบบ prompt ที่น่าสงสัยและความพยายามที่ถูกบล็อก
ไม่มีการควบคุมเดียวที่เพียงพอ system prompt ที่แข็งแกร่งช่วย แต่ไม่ควรเป็นขอบเขตความปลอดภัยเดียว
สิ่งที่ไม่ควรพึ่งพาเพียงอย่างเดียว
ทีมควรหลีกเลี่ยงการพึ่งพาเพียง:
- system prompt ทั่วไป “อย่าทำลายกฎ”
- ตัวกรองคำสำคัญ
- การตรวจสอบด้วยมือโดยไม่มี logs
- การตั้งค่าความปลอดภัยโมเดลเดียว
- เชื่อถือเนื้อหา RAG ทั้งหมด
- ให้ agent สิทธิ์ API กว้าง
- สมมติว่าผู้ใช้จะไม่ลอง input ฝ่ายตรงข้าม
ความปลอดภัย LLM ควรสมมติว่า prompt, เนื้อหาที่ดึง และผลลัพธ์เครื่องมือสามารถถูกจัดการได้
Secure Tool Calling และการเข้าถึงสิทธิ์น้อยที่สุด
ทำไม tool calling เปลี่ยนโมเดลความปลอดภัย
Tool calling เป็นหนึ่งในความแตกต่างที่ใหญ่ที่สุดระหว่างแชทบอท LLM ปกติและระบบ agentic AI
แชทบอทผลิตข้อความ agent ที่มีเครื่องมือสามารถสร้าง side effects มันอาจค้นหาฐานข้อมูล, ส่งอีเมล, อัปเดตฟิลด์ CRM, สร้างตั๋วสนับสนุน, รันสคริปต์ หรือทริกเกอร์เวิร์กโฟลว์ภายใน
นั่นหมายความว่าผลลัพธ์โมเดลกลายเป็นการกระทำระบบที่เป็นไปได้ การควบคุมความปลอดภัยต้องปกป้องชั้นการกระทำ ไม่ใช่แค่ชั้นข้อความ
ความเสี่ยง tool-calling ทั่วไปในการผลิต
ความเสี่ยงทั่วไปรวมถึง:
- agent เรียกเครื่องมือที่ไม่ควรเข้าถึง
- agent ส่งข้อมูลที่ละเอียดอ่อนไปยังเครื่องมือที่ผิด
- agent ใช้เครื่องมือที่ถูกต้องด้วยอาร์กิวเมนต์ที่ไม่ปลอดภัย
- agent ทำซ้ำ tool calls และสร้างปัญหาต้นทุนหรือความพร้อมใช้งาน
- การตอบสนองของเครื่องมือมีคำสั่งที่เป็นอันตราย
- เครื่องมือมีสิทธิ์กว้างกว่าที่เวิร์กโฟลว์ต้องการ
- Secrets เปิดเผยต่อโมเดลผ่าน prompt หรือผลลัพธ์เครื่องมือ
- การกระทำของเครื่องมือไม่สามารถย้อนกลับไปยังผู้ใช้, agent หรือการอนุมัติ
OWASP ยังเน้นExcessive Agency เป็นความเสี่ยงแอปพลิเคชัน LLM หลัก โดยเฉพาะสำหรับระบบที่สามารถเรียกเครื่องมือหรือโต้ตอบกับระบบภายนอก ปัญหามักมีรากจากฟังก์ชันการทำงานมากเกินไป, สิทธิ์มากเกินไป หรืออิสระมากเกินไป นั่นแมปโดยตรงไปยัง agent ในการผลิตที่มีการเข้าถึงเครื่องมือกว้าง
การเข้าถึงสิทธิ์น้อยที่สุดสำหรับ LLM agent
สิทธิ์น้อยที่สุดหมายความว่า agent ควรมีเฉพาะสิทธิ์ที่ต้องการสำหรับงานเฉพาะ
ตัวอย่างเช่น agent ที่ร่างการตอบสนับสนุนลูกค้าอาจต้องการสิทธิ์อ่านประวัติตั๋ว แต่อาจไม่ต้องการสิทธิ์ออกเงินคืน, ลบบัญชี หรือเปลี่ยนระเบียนการเรียกเก็บเงิน หากการกระทำมีความเสี่ยงสูง agent ควรร่างหรือแนะนำ ในขณะที่มนุษย์อนุมัติ
โมเดลสิทธิ์น้อยที่สุดปฏิบัติควรกำหนด:
- เครื่องมือใดที่ agent สามารถใช้
- การดำเนินการใดที่อนุญาต
- ขอบเขตข้อมูลใดที่อนุญาต
- ผู้ใช้หรือบทบาทใดที่สามารถทริกเกอร์เวิร์กโฟลว์
- การกระทำใดที่ต้องการอนุมัติ
- การกระทำใดที่ถูกบล็อกทั้งหมด
agent แต่ละตัวควรมี service identity ของตัวเองเมื่อเป็นไปได้ หลีกเลี่ยงการให้ agent การเข้าถึงกว้างผ่านข้อมูลรับรอง admin ที่ใช้ร่วมกัน
Tool allowlists, scopes และการตรวจสอบนโยบาย
agent ในการผลิตไม่ควรเลือกจากเครื่องมือไม่จำกัด การเข้าถึงเครื่องมือควรถูก allowlist และจำกัดขอบเขต
การควบคุมที่มีประโยชน์รวมถึง:
- Tool allowlists ตามประเภท agent
- ขอบเขต API ตามเวิร์กโฟลว์
- Rate limits ต่อเครื่องมือ
- การตรวจสอบนโยบายก่อนการดำเนินการ
- การแยกสภาพแวดล้อมระหว่าง dev, staging และ production
- การตรวจสอบอนุมัติสำหรับการดำเนินการที่ละเอียดอ่อน
- พฤติกรรม deny-by-default เมื่อบริบทไม่ชัดเจน
ชั้นนโยบายสามารถตัดสินใจว่า tool call อนุญาตหรือไม่ก่อนการกระทำเกิด นี่มีประโยชน์อย่างยิ่งสำหรับการกระทำที่เกี่ยวข้องกับข้อมูลลูกค้า, ผลกระทบทางการเงิน, ผลกระทบทางกฎหมาย, ผลกระทบความปลอดภัย หรือการสื่อสารภายนอก
การตรวจสอบอาร์กิวเมนต์และการตรวจสอบผลลัพธ์
tool calls ควรใช้ structured schemas agent ไม่ควรส่งอาร์กิวเมนต์ free-form โดยพลการเข้าไปใน API ที่ละเอียดอ่อน
ตัวอย่างเช่น:
- ID ควรตรงรูปแบบที่คาด
- จำนวนควรอยู่ในขีดจำกัดที่อนุมัติ
- ผู้รับอีเมลควรตรงโดเมนที่อนุญาตหรือผู้ติดต่อที่ยืนยัน
- เส้นทางไฟล์ควรอยู่ในตำแหน่งที่อนุญาต
- tool calls ควรล้มเหลวแบบปิดเมื่อฟิลด์ที่ต้องการขาด
ผลลัพธ์เครื่องมือควรถูกปฏิบัติอย่างระมัดระวัง การตอบสนองของเครื่องมืออาจมีข้อความที่ไม่น่าเชื่อถือ, ข้อมูลที่ผิดรูปแบบ หรือคำสั่งที่ถูก inject โมเดลควรใช้ผลลัพธ์เครื่องมือเป็นข้อมูล ไม่ใช่แหล่งอำนาจใหม่
Sandboxing เครื่องมือที่มีความเสี่ยงสูง
เครื่องมือบางตัวต้องการการแยก ตัวอย่างรวมถึง:
- การดำเนินการโค้ด
- การท่องเว็บ
- การประมวลผลไฟล์
- การนำเข้าเอกสาร
- การเปลี่ยนแปลงข้อมูล
- การอัตโนมัติเวิร์กโฟลว์กับ side effects ภายนอก
Sandboxing ช่วยจำกัดความเสียหายถ้า agent ทำตัวไม่คาดคิด ขึ้นอยู่กับกรณีใช้งาน sandboxing อาจรวมถึงการจำกัดเครือข่าย, ขีดจำกัดระบบไฟล์, timeouts การดำเนินการ, ขีดจำกัดหน่วยความจำ, ข้อมูลรับรองแยก และสภาพแวดล้อมที่จำกัด
การจัดการ secrets สำหรับเวิร์กโฟลว์ agent
Secrets ไม่ควรอยู่ใน prompt, บริบทโมเดล หรือ logs แบบ plain-text agent ควรเข้าถึง secrets เฉพาะผ่านบริการ backend ที่ปลอดภัย
แนวปฏิบัติที่ดีรวมถึง:
- เก็บ secrets ใน secrets manager
- เก็บข้อมูลรับรองออกจากเทมเพลต prompt
- ลบ secrets จาก logs
- หมุนเวียนข้อมูลรับรองเป็นประจำ
- ใช้ token อายุสั้นเมื่อเป็นไปได้
- แยกข้อมูลรับรองตามสภาพแวดล้อม
- หลีกเลี่ยงการเปิดเผย raw API key ต่อผลลัพธ์โมเดลหรือการตอบสนองเครื่องมือ
โมเดลควรร้องขอการกระทำ แต่ backend ควรบังคับการอนุญาตและดำเนินการปฏิบัติการที่ปลอดภัย
Audit logging สำหรับ tool calls
tool call สำคัญทุกครั้งควรถูกบันทึก logs ควรช่วยตอบ:
- ผู้ใช้ใดทริกเกอร์เวิร์กโฟลว์?
- agent ใดตัดสินใจ?
- เครื่องมือใดถูกเรียก?
- การกระทำใดถูกร้องขอ?
- การกระทำได้รับอนุมัติหรือไม่?
- ผลลัพธ์คืออะไร?
- มีข้อมูลที่ละเอียดอ่อนใด ๆ เกี่ยวข้องหรือไม่?
- การกระทำถูกบล็อก, ลองใหม่ หรือย้อนกลับหรือไม่?
สำหรับสภาพแวดล้อมองค์กร EU/US การตรวจสอบย้อนได้มักสำคัญเท่าการป้องกัน หากสิ่งใดผิดพลาด องค์กรต้องการสร้างใหม่สิ่งที่เกิดขึ้น
ที่อยู่ข้อมูลและความเป็นส่วนตัวสำหรับการปรับใช้ EU/US
เริ่มจากแผนที่ข้อมูล
ที่อยู่ข้อมูลเริ่มจากการทำความเข้าใจกระแสข้อมูล ก่อนเลือกผู้ให้บริการโมเดลหรือสถาปัตยกรรม ทีมควรจับแผนที่:
- ข้อมูลใดเข้าสู่ prompt
- ข้อมูลใดถูกดึงจากระบบภายใน
- ข้อมูลใดถูกส่งไปยังผู้ให้บริการโมเดล
- ข้อมูลใดถูกฝังใน vector database
- ข้อมูลใดถูกบันทึก
- ข้อมูลถูกเก็บรักษานานเท่าใด
- ภูมิภาคใดประมวลผลหรือจัดเก็บแต่ละส่วนประกอบ
- ผู้ให้บริการหรือ subprocessor ใดเกี่ยวข้อง
โดยไม่มีแผนที่ข้อมูล การตรวจสอบความปลอดภัยและการปฏิบัติตามข้อกำหนดกลายเป็นการเดา
IBM ยังรายงานว่า 63% ขององค์กรที่ถูกละเมิดขาดนโยบายการกำกับดูแล AI หรือยังพัฒนาอยู่ สำหรับการปรับใช้ EU/US ช่องว่างการกำกับดูแลนั้นมักปรากฏเป็นกระแสข้อมูลที่ไม่ชัดเจน, การตัดสินใจการเก็บรักษาที่อ่อนแอ, การตรวจสอบผู้ให้บริการไม่สมบูรณ์ หรือการควบคุมที่ขาดรอบ shadow AI
ข้อพิจารณา EU
สำหรับการปรับใช้ EU ทีมมักต้องพิจารณาหลักการความเป็นส่วนตัว เช่น การลดข้อมูลให้น้อยที่สุด, การจำกัดวัตถุประสงค์, การควบคุมการเข้าถึง, การเก็บรักษา และการตรวจสอบการถ่ายโอนข้ามพรมแดน ภาระผูกพันเฉพาะขึ้นอยู่กับองค์กร, กรณีใช้งาน, ประเภทข้อมูล และพื้นฐานทางกฎหมาย
คำถามสถาปัตยกรรมปฏิบัติรวมถึง:
- ข้อมูลที่ละเอียดอ่อนสามารถลดให้น้อยที่สุดก่อนสร้าง prompt หรือไม่?
- inference สามารถกำหนดภูมิภาคได้หรือไม่?
- logs ถูกจัดเก็บในภูมิภาคที่ถูกต้องหรือไม่?
- embeddings ถูกพิจารณาละเอียดอ่อนในกรณีใช้งานนี้หรือไม่?
- ข้อมูลลูกค้าสามารถยกเว้นจากการฝึกของผู้ให้บริการได้หรือไม่?
- การตั้งค่าการลบและการเก็บรักษาสามารถกำหนดค่าได้หรือไม่?
การตีความกฎหมายควรถูกตรวจสอบโดยที่ปรึกษาที่มีคุณสมบัติเหมาะสมก่อนการตัดสินใจเผยแพร่หรือนำไปใช้
ข้อพิจารณา US
การปรับใช้ US อาจเกี่ยวข้องกับความคาดหวังเฉพาะภาคขึ้นอยู่กับอุตสาหกรรม สุขภาพ, การเงิน, การศึกษา, ภาครัฐ และสภาพแวดล้อม SaaS องค์กรมักมีความคาดหวังที่เข้มงวดขึ้นรอบการควบคุมการเข้าถึง, audit logs, การเก็บรักษา และการจัดการความเสี่ยงผู้ให้บริการ
แม้เมื่อกฎระเบียบไม่กล่าวถึง LLM อย่างชัดเจน ผู้ซื้ออาจคาดหวังการควบคุมความปลอดภัยที่สอดคล้องกับเฟรมเวิร์กองค์กร เช่น SOC 2 หรือ ISO/IEC 27001
รูปแบบสถาปัตยกรรมสำหรับระบบ LLM ที่ละเอียดอ่อนต่อที่อยู่ข้อมูล
รูปแบบทั่วไปรวมถึง:
- endpoint โมเดลเฉพาะภูมิภาค
- vector store เฉพาะภูมิภาค
- เครือข่ายส่วนตัวเมื่อมี
- คีย์การเข้ารหัสที่ลูกค้าจัดการ
- การปกปิดข้อมูลก่อนการเรียกโมเดล
- การตรวจจับ PII ก่อนสร้าง prompt
- สภาพแวดล้อม EU และ US แยก
- หน้าต่างการเก็บรักษาสั้นสำหรับ prompt และผลลัพธ์
- ชั้น logging ที่แยก metadata การดำเนินงานจากเนื้อหาที่ละเอียดอ่อน
- การควบคุมการเข้าถึงบน embeddings และเอกสารที่ดึง
เป้าหมายคือลดการเคลื่อนย้ายข้อมูลที่ไม่จำเป็นและทำให้การเคลื่อนย้ายข้อมูลที่หลีกเลี่ยงไม่ได้มองเห็น, ควบคุม และมีเอกสาร
Checklist การตรวจสอบผู้ให้บริการอย่างละเอียด
ก่อนใช้ผู้ให้บริการ LLM หรือผู้ให้บริการโครงสร้างพื้นฐาน AI ทีมควรถาม:
- ข้อมูลถูกประมวลผลที่ไหน?
- ข้อมูลถูกจัดเก็บที่ไหน?
- ข้อมูลลูกค้าถูกใช้ฝึกหรือไม่?
- การควบคุมการเก็บรักษาใดที่มี?
- subprocessor ใดเกี่ยวข้อง?
- การควบคุมความปลอดภัยระดับองค์กรได้รับการสนับสนุนหรือไม่?
- audit logs มีหรือไม่?
- ข้อมูลสามารถลบได้ตามคำขอหรือไม่?
- ตัวเลือกเครือข่ายส่วนตัวหรือกำหนดภูมิภาคมีหรือไม่?
- เกิดอะไรขึ้นระหว่างการตอบสนองเหตุการณ์?
การตั้งค่าผู้ให้บริการสามารถเปลี่ยนท่าทียืนความปลอดภัยของระบบ LLM อย่างมีนัยสำคัญ ควรถูกตรวจสอบก่อนใช้ในการผลิต
การควบคุม HITL: การกำกับดูแลโดยมนุษย์โดยไม่ฆ่าความเร็ว
HITL ควรเป็นตามความเสี่ยง
Human-in-the-loop ไม่ได้หมายความว่าการกระทำของ agent ทุกอันต้องการการอนุมัติด้วยมือ นั่นจะทำให้เวิร์กโฟลว์ส่วนใหญ่ช้าเกินไป ยังไม่ได้หมายความว่าการกระทำทุกอันควรเป็นอัตโนมัติ
แนวทางที่เหมาะสมคือตามความเสี่ยง การกระทำที่มีความเสี่ยงต่ำสามารถถูกบันทึกและตรวจสอบ การกระทำที่มีความเสี่ยงปานกลางอาจต้องการการสุ่ม, การตรวจสอบตามกฎ หรือการอนุมัติภายใต้เงื่อนไขบางอย่าง การกระทำที่มีความเสี่ยงสูงควรต้องการการตรวจสอบโดยมนุษย์อย่างชัดเจน
ชั้นความเสี่ยงที่แนะนำ
| ชั้นความเสี่ยง | ตัวอย่างการกระทำของ agent | การควบคุมที่แนะนำ |
|---|---|---|
| ต่ำ | ร่างสรุปภายใน | บันทึกเท่านั้น |
| ปานกลาง | อัปเดตฟิลด์ CRM ที่ไม่สำคัญ | การตรวจสอบตามกฎหรือการตรวจสอบสุ่ม |
| สูง | ส่งข้อความต่อลูกค้า | ต้องการการอนุมัติโดยมนุษย์ |
| วิกฤต | การชำระเงิน, การลบบัญชี, การกระทำที่มีผลกระทบทางกฎหมาย/ความปลอดภัย | การอนุมัติโดยมนุษย์บวกการควบคุมทุติยภูมิ |
โครงสร้างนี้ให้ทีมรักษาความเร็วในขณะที่ยังควบคุมการตัดสินใจที่มีผลกระทบสูง
การควบคุมที่ทำให้ HITL ตรวจสอบย้อนได้
เวิร์กโฟลว์ HITL ที่มีประโยชน์ควรจับ:
- ตัวตนผู้ตรวจสอบ
- การตัดสินใจอนุมัติหรือปฏิเสธ
- เหตุผลของการตัดสินใจ
- คำแนะนำ agent ดั้งเดิม
- การกระทำสุดท้ายที่ดำเนินการ
- สถานะก่อน/หลังเมื่อเกี่ยวข้อง
- การประทับเวลา
- เส้นทางการเลื่อนระดับ
- ตัวเลือก rollback
โดยไม่มีบันทึกเหล่านี้ HITL อาจช่วยในการดำเนินงานแต่ล้มเหลวในการสนับสนุน audit หรือการตรวจสอบเหตุการณ์
เมื่อใดควรเพิ่ม kill switch
kill switch ให้ทีมหยุด agent หรือปิดการกระทำเครื่องมือเฉพาะอย่างรวดเร็ว
ทีมควรพิจารณา kill switch สำหรับกรณี เช่น:
- ปริมาณ tool call ที่ไม่คาดคิด
- การตรวจสอบล้มเหลวซ้ำ
- ความพยายาม injection ที่น่าสงสัย
- การเปิดเผยข้อมูลที่ละเอียดอ่อน
- ต้นทุนเพิ่มขึ้น
- โมเดล/ผู้ให้บริการล่ม
- การตัดสินใจความมั่นใจต่ำซ้ำ
- การร้องเรียนผู้ใช้ที่ผิดปกติหรือการเลื่อนระดับสนับสนุน
kill switch ควรถูกทดสอบก่อนเปิดตัว ไม่ควรมีอยู่เพียงเป็นการควบคุมทางทฤษฎี
การทดสอบและการตรวจสอบ LLM Agent ก่อนการผลิต
QA แบบดั้งเดิมไม่เพียงพอ
QA แบบดั้งเดิมสมมติพฤติกรรมที่กำหนดได้เป็นหลัก LLM agent แตกต่าง ผลลัพธ์อาจผันแปร, เส้นทางการให้เหตุผลอาจเปลี่ยน และการกระทำอาจขึ้นอยู่กับข้อมูลที่ดึง, การตอบสนองเครื่องมือ, บริบทผู้ใช้ และการตั้งค่าโมเดล
นั่นหมายความว่าการทดสอบ agent ต้องรวมทั้งการประเมินฟังก์ชันและความปลอดภัย เวิร์กโฟลว์สามารถผ่านเทสต์ happy-path และยังล้มเหลวภายใต้ input ฝ่ายตรงข้าม, เอกสารผิดปกติ, การตอบสนองเครื่องมือผิดรูปแบบ หรือกรณีขอบเขตสิทธิ์
ประเภทเทสต์หลัก
แผนเทสต์ที่พร้อมสำหรับการผลิตควรรวม:
- เทสต์ความสำเร็จของงาน
- เทสต์ prompt injection
- เทสต์ indirect injection
- เทสต์สิทธิ์เครื่องมือ
- เทสต์การตรวจสอบอาร์กิวเมนต์เครื่องมือ
- เทสต์การรั่วไหลของข้อมูล
- เทสต์การเข้าถึงการดึง RAG
- เทสต์เวิร์กโฟลว์ HITL
- เทสต์ regression
- เทสต์ต้นทุนและ latency
- เทสต์โหมดความล้มเหลว
- เทสต์ rollback และ kill-switch
เทสต์ความปลอดภัยควรรวมเวิร์กโฟลว์ธุรกิจจริง ไม่ใช่แค่ prompt ประดิษฐ์
สร้าง evaluation harness
evaluation harness ช่วยทีมทดสอบ agent อย่างสม่ำเสมอก่อนปล่อยรุ่น ควรรวม:
- ชุดเคสเทสต์ที่มีเวอร์ชัน
- ผลลัพธ์ที่คาดหวังหรือเกณฑ์การให้คะแนน
- ตัวอย่างฝ่ายตรงข้าม
- งานผู้ใช้จริง
- สถานการณ์การใช้เครื่องมือ
- การตรวจสอบการละเมิดนโยบาย
- การติดตาม regression ข้ามการเปลี่ยนแปลงโมเดลหรือ prompt
- รายงานที่สามารถตรวจสอบโดยทีมวิศวกรรม, ความปลอดภัย และผลิตภัณฑ์
harness ควรรันก่อนการปล่อยรุ่นสำคัญและเมื่อใดก็ตามที่ prompt, เครื่องมือ, โมเดล, ตรรกะการดึง หรือกฎนโยบายเปลี่ยนแปลง
สัญญาณการตรวจสอบที่ต้องกำหนดก่อนเปิดตัว
การตรวจสอบควรถูกออกแบบก่อน agent ออนไลน์ สัญญาณที่มีประโยชน์รวมถึง:
- ความถี่ tool call
- การตรวจสอบล้มเหลว
- การกระทำที่ถูกบล็อก
- อัตราการอนุมัติและปฏิเสธ HITL
- การลองใหม่ซ้ำ
- ความผิดปกติของ token และต้นทุน
- การเพิ่มขึ้นของ latency
- การตรวจจับข้อมูลที่ละเอียดอ่อน
- รูปแบบ prompt ที่น่าสงสัย
- การเข้าถึงข้อมูลที่ไม่คาดคิด
- การร้องเรียนผู้ใช้
- ความพยายามละเมิดนโยบาย
สัญญาณเหล่านี้ควรป้อนการแจ้งเตือน, แดชบอร์ด และเวิร์กโฟลว์การตอบสนองเหตุการณ์
การตรวจสอบการผลิตหลังปล่อยรุ่น
การทดสอบไม่จบที่การเปิดตัว LLM agent สามารถ drift เมื่อข้อมูล, เครื่องมือ, prompt, โมเดล และพฤติกรรมผู้ใช้เปลี่ยนแปลง
มุมมองวงจรชีวิตนี้สอดคล้องกับ NIST AI Risk Management Framework ซึ่งจัดงานความเสี่ยง AI รอบกำกับดูแล, จับแผนที่, วัด และจัดการ สำหรับ LLM agent นั่นหมายความว่าทีมควรจับแผนที่ความเสี่ยงก่อนการปรับใช้, วัดพฤติกรรมผ่านการประเมินและการตรวจสอบ และจัดการความล้มเหลวผ่านการแจ้งเตือน, เส้นทาง rollback และการตอบสนองเหตุการณ์
หลังปล่อยรุ่น ทีมควรตรวจสอบ:
- agent ยังบรรลุเป้าหมายความสำเร็จของงานหรือไม่
- การบล็อกความปลอดภัยเพิ่มขึ้นหรือไม่
- ผู้ตรวจสอบ HITL ล้มล้าง agent บ่อยหรือไม่
- รูปแบบต้นทุนคงที่หรือไม่
- ผู้ใช้ค้นพบโหมดความล้มเหลวใหม่หรือไม่
- การเปลี่ยนแปลงโมเดลหรือผู้ให้บริการใด ๆ ส่งผลกระทบพฤติกรรมหรือไม่
การตรวจสอบการผลิตเปลี่ยนความปลอดภัย LLM จาก checklist ครั้งเดียวเป็นแนวปฏิบัติการดำเนินงานอย่างต่อเนื่อง
Checklist ความปลอดภัย LLM สำหรับการปล่อยอย่างปลอดภัย
การควบคุมสถาปัตยกรรม
ก่อนเปิดตัว ยืนยัน:
- กระแสข้อมูลถูกจับแผนที่
- คลาสข้อมูลที่ละเอียดอ่อนถูกระบุ
- สิทธิ์เครื่องมือมีเอกสาร
- การควบคุมการเข้าถึง RAG ถูกทดสอบ
- การตั้งค่าโมเดลและผู้ให้บริการถูกตรวจสอบ
- การตั้งค่าภูมิภาคและการเก็บรักษาได้รับการยืนยัน
- Secrets อยู่นอก prompt และ logs
- สภาพแวดล้อมถูกแยก
การควบคุมความปลอดภัย
ยืนยัน:
- การป้องกัน prompt injection ถูกทดสอบ
- กรณี indirect injection รวมในการประเมิน
- tool allowlists ถูกบังคับ
- อาร์กิวเมนต์เครื่องมือถูกตรวจสอบฝั่งเซิร์ฟเวอร์
- ผลลัพธ์เครื่องมือถูกปฏิบัติเป็นข้อมูลที่ไม่น่าเชื่อถือ
- การเข้าถึงสิทธิ์น้อยที่สุดถูกใช้
- การกระทำที่มีความเสี่ยงสูงถูก gated
- audit logs เปิดใช้งาน
- rate limits และ timeouts ถูกกำหนดค่า
การควบคุมการปฏิบัติตามข้อกำหนด
ยืนยัน:
- การเก็บรักษาข้อมูลมีเอกสาร
- การตรวจสอบผู้ให้บริการ/subprocessor เสร็จสิ้น
- นโยบายการกำกับดูแลโดยมนุษย์ถูกกำหนด
- เวิร์กโฟลว์ที่มีความเสี่ยงสูงตรวจสอบย้อนได้
- การควบคุมการเข้าถึงเป็นตามบทบาท
- ขั้นตอนการตอบสนองเหตุการณ์มีเอกสาร
- กระบวนการลบและการเข้าถึงข้อมูลเข้าใจ
- ทีมกฎหมายและการปฏิบัติตามข้อกำหนดได้ตรวจสอบข้อกำหนดที่เกี่ยวข้อง
การควบคุมการปล่อยรุ่น
ยืนยัน:
- ชุดประเมินผ่าน
- เทสต์ regression เสร็จสมบูรณ์
- เคสเทสต์ความปลอดภัยถูกตรวจสอบ
- การแจ้งเตือนการตรวจสอบถูกกำหนดค่า
- เส้นทาง rollback ถูกทดสอบ
- kill switch ถูกทดสอบ
- เจ้าของหลังปล่อยรุ่นถูกมอบหมาย
- รอบการตรวจสอบถูกกำหนดเวลา
การปล่อยที่ปลอดภัยไม่ใช่แค่หลักชี้วัดทางเทคนิค แต่เป็นความมุ่งมั่นในการดำเนินงาน
HDWEBSOFT ช่วยทีมรักษาความปลอดภัยระบบ LLM และ Agentic AI อย่างไร
การปล่อย agent ที่ขับเคลื่อนด้วย LLM อย่างปลอดภัยต้องการทั้งวิศวกรรม AI และการคิดด้านความปลอดภัย ทีมต้องออกแบบเวิร์กโฟลว์, รวมเครื่องมือ, ปกป้องข้อมูล, ทดสอบพฤติกรรม และตรวจสอบระบบการผลิตโดยไม่ชะลอการส่งมอบโดยไม่จำเป็น
HDWEBSOFT ช่วยทีมวางแผน, สร้าง และรักษาความปลอดภัยระบบ AI ด้วยการสนับสนุนวิศวกรรมปฏิบัติ หากองค์กรของคุณกำลังเตรียมการปล่อย LLM หรือ agentic AI ทีมของเราสามารถสนับสนุนการออกแบบสถาปัตยกรรม, การใช้เวิร์กโฟลว์ AI, การรวมเครื่องมือ, การตรวจสอบความปลอดภัย และความพร้อมการผลิต
สำรวจ บริการพัฒนา AI ของเราสำหรับการใช้ AI ที่ปลอดภัยและ บริการความปลอดภัยไซเบอร์ ของเราสำหรับการประเมินความปลอดภัย, การตรวจสอบความเสี่ยง และการควบคุมการผลิตที่แข็งแกร่งขึ้น
บทสรุป
ความปลอดภัย LLM ไม่ใช่ prompt เดียว, นโยบายเดียว หรือ checklist เดียว สำหรับ agentic AI ต้องครอบคลุมระบบทั้งหมด: prompt, ข้อมูลที่ดึง, เครื่องมือ, สิทธิ์, logs, การอนุมัติโดยมนุษย์, การทดสอบ และการตรวจสอบการผลิต
ทีมที่ปล่อยอย่างปลอดภัยจะเป็นทีมที่ปฏิบัติต่อความปลอดภัยเป็นส่วนหนึ่งของสถาปัตยกรรมตั้งแต่เริ่มต้น การควบคุม prompt injection, การเข้าถึงเครื่องมือสิทธิ์น้อยที่สุด, การวางแผนที่อยู่ข้อมูล, เวิร์กโฟลว์ HITL และการประเมินอย่างต่อเนื่องทำงานร่วมกันเพื่อลดความเสี่ยง
สำหรับสภาพแวดล้อมการผลิต EU/US เป้าหมายไม่ใช่แค่ทำให้ agent มีประโยชน์ เป้าหมายคือทำให้มันควบคุมได้, ตรวจสอบย้อนได้, ทนทาน และปลอดภัยพอที่จะดำเนินงานในเวิร์กโฟลว์ธุรกิจจริง
FAQ
ความปลอดภัย LLM คืออะไร?
ความปลอดภัย LLM เป็นแนวปฏิบัติของการปกป้องระบบที่ขับเคลื่อนด้วย LLM จาก prompt injection, การรั่วไหลของข้อมูล, การใช้เครื่องมือโดยไม่ได้รับอนุญาต, ผลลัพธ์ที่ไม่ปลอดภัย และความล้มเหลวในการปฏิบัติตามข้อกำหนด สำหรับ agentic AI ยังรวมถึงสิทธิ์เครื่องมือ, audit logs, เวิร์กโฟลว์ HITL, การทดสอบ และการตรวจสอบ
ทำไมความปลอดภัย LLM ยากขึ้นสำหรับ AI agent?
ความปลอดภัย LLM ยากขึ้นสำหรับ AI agent เพราะ agent สามารถดำเนินการได้ พวกเขาอาจดึงเอกสาร, เรียก API, อัปเดตระบบ หรือทริกเกอร์เวิร์กโฟลว์ นั่นหมายความว่าความปลอดภัยต้องปกป้องไม่เพียงผลลัพธ์โมเดล แต่ยังรวมถึงเครื่องมือและข้อมูลที่เชื่อมต่อกับ agent
คุณป้องกัน prompt injection ใน LLM agent อย่างไร?
การป้องกัน prompt injection ต้องการการควบคุมเป็นชั้น ทีมควรแยกคำสั่งที่เชื่อถือได้จากเนื้อหาที่ไม่น่าเชื่อถือ, ตรวจสอบ tool calls, ใช้การเข้าถึงสิทธิ์น้อยที่สุด, ปฏิบัติต่อเนื้อหาที่ดึงมาเป็นข้อมูล, เพิ่มการตรวจสอบนโยบาย, ตรวจสอบรูปแบบที่น่าสงสัย และทดสอบกับกรณีฝ่ายตรงข้าม
indirect prompt injection คืออะไร?
indirect prompt injection เกิดขึ้นเมื่อคำสั่งที่เป็นอันตรายถูกซ่อนอยู่ในเนื้อหาที่ agent อ่าน เช่น หน้าเว็บ, อีเมล, เอกสาร, ตั๋วสนับสนุน, PDF หรือผลลัพธ์ RAG agent อาจปฏิบัติต่อเนื้อหานั้นเป็นคำสั่ง เว้นแต่ระบบถูกออกแบบให้แยกและตรวจสอบ
คุณรักษาความปลอดภัย tool calling สำหรับ LLM agent อย่างไร?
secure tool calling ต้องการการเข้าถึงสิทธิ์น้อยที่สุด, API ที่จำกัดขอบเขต, tool allowlists, structured schemas, การตรวจสอบอาร์กิวเมนต์ฝั่งเซิร์ฟเวอร์, การตรวจสอบผลลัพธ์, rate limits, sandboxing สำหรับเครื่องมือที่มีความเสี่ยงสูง, การจัดการ secrets และ audit logging สำหรับการกระทำของเครื่องมือ
ที่อยู่ข้อมูลส่งผลต่อแอปพลิเคชัน LLM อย่างไร?
ที่อยู่ข้อมูลส่งผลต่อที่ที่ prompt, เอกสารที่ดึง, embeddings, ผลลัพธ์ และ logs ถูกประมวลผลและจัดเก็บ การปรับใช้ EU/US ควรจับแผนที่กระแสข้อมูล, ตรวจสอบการตั้งค่าผู้ให้บริการ, กำหนดค่าการเก็บรักษา และเลือกรูปแบบสถาปัตยกรรมที่ตรงกับข้อกำหนดความเป็นส่วนตัวและการปฏิบัติตามข้อกำหนด
ทีมควรทดสอบอะไรก่อนปรับใช้ LLM agent?
ทีมควรทดสอบความสำเร็จของงาน, ความต้านทาน prompt injection, สถานการณ์ indirect injection, สิทธิ์เครื่องมือ, การรั่วไหลของข้อมูล, การควบคุมการเข้าถึง RAG, เวิร์กโฟลว์การอนุมัติ HITL, พฤติกรรม regression, การแจ้งเตือนการตรวจสอบ, latency, พฤติกรรมต้นทุน, เส้นทาง rollback และพฤติกรรม kill-switch
