การเข้ารหัสกำหนดว่าใครอ่านข้อความระหว่างทางได้ ส่วนการควบคุมการเข้าถึงและการออกแบบเอเจนต์กำหนดว่าผู้รับทำอะไรได้หลังอ่านแล้ว
การโจมตีแบบแทรกคำสั่ง หรือ Prompt Injection ในแอปส่งข้อความเกิดขึ้นเมื่อข้อความหนึ่งชักจูงให้ผู้ช่วย AI เพิกเฉยต่อกฎหลักและทำตามคำขอที่ไม่ได้รับอนุญาต การเข้ารหัสจากต้นทางถึงปลายทางปกป้องข้อความระหว่างทาง แต่หากผู้ใช้อนุญาตให้บอตอ่านแชต หรืออุปกรณ์ติดมัลแวร์ การเข้ารหัสก็ไม่สามารถควบคุมพฤติกรรมของผู้รับที่ได้รับอนุญาตนั้นได้
ประเด็นสำคัญ
- การเข้ารหัสจากต้นทางถึงปลายทางป้องกันการอ่านข้อความระหว่างทาง ไม่ได้ป้องกันการใช้ข้อมูลผิดวัตถุประสงค์โดยผู้ช่วยเสมือนที่มีสิทธิ์เห็นข้อความหลังถอดรหัส
- การแทรกคำสั่งทางอ้อมอาจซ่อนอยู่ในข้อความส่วนตัว ไฟล์ คำบรรยาย หรือเนื้อหาที่อ้างมา และถูกตีความเป็นคำสั่งเมื่อผ่านการประมวลผล
- ความเสี่ยงที่ข้อมูลจะรั่วไหลจากเอเจนต์ AI เพิ่มขึ้นเมื่อเอเจนต์เข้าถึงแชต หน่วยความจำ เครื่องมือภายนอก และความสามารถในการส่งข้อมูลหรือดำเนินการได้พร้อมกัน
- การแยกข้อมูลออกจากคำสั่ง การจำกัดสิทธิ์ให้น้อยที่สุด การให้มนุษย์ยืนยัน และการจำกัดข้อมูลขาออกเป็นชั้นป้องกันสำคัญ แต่ไม่มีข้อใดรับประกันความปลอดภัยได้ทั้งหมดเพียงลำพัง
- ตามเอกสารของ Livara แชตโดยตรงและกลุ่มส่วนตัวที่เข้ากันได้จะมีการเข้ารหัสจากต้นทางถึงปลายทางเมื่อสถานะ E2EE เปิดใช้งานอยู่ ส่วนกลุ่มเก่าที่ไม่เข้ากันอาจอยู่นอกความคุ้มครองนี้ การป้องกันนี้ไม่ได้รับประกันพฤติกรรมของผู้ช่วยหลังได้รับข้อความ
การแทรกคำสั่งในแอปส่งข้อความทำงานอย่างไร?
Prompt Injection หรือ «การแทรกคำสั่ง» คือการที่ผู้โจมตีสร้างอินพุตให้โมเดลภาษายอมรับเป็นคำสั่งแทนที่จะเป็นข้อมูล และเบี่ยงเบนไปจากนโยบายหลัก แนวทางเรื่อง Prompt Injection ของ OWASP ระบุว่าอินพุตโดยตรงและเนื้อหาภายนอกเป็นช่องทางของความเสี่ยงนี้ ในระบบที่ใช้เอเจนต์ การเบี่ยงเบนคำตอบอาจลุกลามไปถึงการใช้เครื่องมือที่เชื่อมต่อโดยไม่พึงประสงค์
ในการโจมตีโดยตรง ผู้ใช้เป็นผู้บอกบอตให้ละทิ้งกฎก่อนหน้าเอง ส่วนการโจมตีทางอ้อมจะใส่คำสั่งอันตรายไว้ในเนื้อหาที่ผู้ช่วยอ่านเพื่อทำงานอื่น เช่น ข้อความที่ได้รับ ข้อความที่อ้างมา คำบรรยาย เอกสาร หรือผลลัพธ์จากเครื่องมือ ในกรณีหลัง ผู้โจมตีไม่จำเป็นต้องใช้บัญชีร่วมกับเอเจนต์ AI ขอเพียงเนื้อหาของตนไปถึงบริบทที่เอเจนต์ประมวลผล
ตัวอย่างเช่น ผู้ใช้ขอให้ผู้ช่วยสรุปข้อความใหม่ มีข้อความหนึ่งแอบอ้างว่าเป็น «คำสั่งระบบ» และขอให้เอเจนต์หยุดสรุป ดึงข้อมูลอื่นจากบริบท แล้วส่งไปยังปลายทางภายนอก สถานการณ์นี้ไม่ได้สำเร็จแน่นอน แต่ขึ้นอยู่กับโมเดล การออกแบบแอป สิทธิ์การเข้าถึง และการควบคุมข้อมูลขาออก อย่างไรก็ตาม แม้เป็นเพียงความเป็นไปได้ก็มีความสำคัญด้านความปลอดภัยสำหรับผู้ช่วยที่ใช้เครื่องมือได้
ต้องแยกความต่างระหว่างการบิดเบือนคำตอบของโมเดลกับการโจมตีเอเจนต์ที่ลงมือทำได้ คำตอบผิดอาจสร้างความรำคาญ แต่เอเจนต์ที่มีสิทธิ์ส่งข้อความ เรียกดูไฟล์ หรือเรียกใช้บริการ อาจเปลี่ยนการบิดเบือนแบบเดียวกันให้กลายเป็นการเปิดเผยข้อมูลหรือการกระทำที่ไม่ต้องการ
เหตุใดความปลอดภัยของแชตบอต AI จึงไม่ได้ขึ้นอยู่กับการเข้ารหัสเพียงอย่างเดียว?
ความปลอดภัยของแชตบอต AI ขึ้นอยู่กับห่วงโซ่ความไว้วางใจทั้งหมด ได้แก่ แอปส่งข้อความ อุปกรณ์ โมเดล หน่วยความจำ เครื่องมือ เซิร์ฟเวอร์ของผู้ให้บริการ และนโยบายสิทธิ์ การเข้ารหัสจากต้นทางถึงปลายทางครอบคลุมเพียงขอบเขตหนึ่ง คือป้องกันการอ่านเนื้อหาส่วนตัวระหว่างผู้ส่งกับผู้รับที่ได้รับอนุญาต
เมื่อข้อความมาถึงอุปกรณ์ที่ได้รับอนุญาต ข้อความจะถูกถอดรหัสเพื่อแสดงให้ผู้ใช้เห็น หากผู้ช่วยเข้าถึงข้อความบนอุปกรณ์เดียวกันหรือผ่านการเชื่อมต่อที่ได้รับอนุญาต ก็จะเห็นข้อมูลหลังถอดรหัสแล้ว ในมุมของโปรโตคอล บอตหรือแอปที่ได้รับสิทธิ์อาจเป็นผู้รับที่ชอบด้วยกติกา แต่ในมุมของผู้ใช้ ผู้รับรายเดียวกันนั้นอาจมีอำนาจมากเกินจำเป็น
สรุปความต่างได้ว่า การเข้ารหัสกำหนดว่าใครอ่านข้อความระหว่างทางได้ ส่วนการควบคุมการเข้าถึงและการออกแบบเอเจนต์กำหนดว่าผู้รับทำอะไรได้หลังอ่านแล้ว เพื่อทำความเข้าใจขอบเขตแรก คู่มือการเข้ารหัสจากต้นทางถึงปลายทางและสิ่งที่ไม่อยู่ในความคุ้มครองอธิบายว่า E2EE ไม่ใช่ทางแก้สำหรับมัลแวร์ ผู้รับที่ทรยศ หรือจอแสดงผลที่ถูกเจาะ
คำว่า «แอปส่งข้อความเข้ารหัสกับ AI» ก็ไม่ควรถูกตีความว่าปลอดภัยหรือไม่ปลอดภัยโดยอัตโนมัติ เอเจนต์ที่ทำงานบนเครื่อง ไม่มีหน่วยความจำถาวรและไม่มีเครื่องมือส่งข้อมูลออก มีระดับความเสี่ยงต่างจากบอตบนคลาวด์ที่เข้าถึงประวัติ ไฟล์ และบัญชีภายนอกได้ สถาปัตยกรรมและขอบเขตสิทธิ์เป็นตัวกำหนดผลลัพธ์
การให้ผู้ช่วย AI เข้าถึงแชตส่วนตัวสร้างความเสี่ยงอะไร?
การให้ผู้ช่วย AI เข้าถึงแชตส่วนตัวนำเนื้อหาที่เดิมมีเพียงมนุษย์ในบทสนทนาเห็น เข้าสู่ขอบเขตความไว้วางใจใหม่ ความเสี่ยงหลักคือผู้ช่วยอาจไม่เพียงอ่านข้อความ แต่ยังเก็บไว้ รวมกับข้อมูลอื่น หรือส่งออกผ่านอีกช่องทางหนึ่งได้
ก่อนเปิดใช้ความสามารถเช่นนี้ ต้องมีคำตอบชัดเจนสำหรับคำถามห้าข้อ:
- ผู้ช่วยอ่านบทสนทนา ไฟล์แนบ และช่วงเวลาใดบ้างอย่างแน่นอน?
- ประมวลผลบนอุปกรณ์หรือส่งเนื้อหาไปยังเซิร์ฟเวอร์อื่น?
- ผู้ให้บริการเก็บข้อมูลใดไว้ และนำไปใช้ฝึกโมเดลหรือไม่?
- เอเจนต์มีเครื่องมือใดสำหรับส่งข้อความ อัปโหลดไฟล์ ค้นหา หรือดำเนินการ?
- ทุกการกระทำที่อ่อนไหวต้องให้ผู้ใช้ยืนยันอย่างชัดแจ้งหรือไม่?
การให้สิทธิ์ «อ่านทุกแชต» กับความสามารถที่ต้องสรุปเพียงข้อความที่เลือกหนึ่งข้อความ เป็นการละเมิดหลักสิทธิ์น้อยที่สุด หลักนี้หมายถึงแต่ละส่วนควรได้รับการเข้าถึงเท่าที่จำเป็นต่อภารกิจปัจจุบันเท่านั้น การจำกัดสิทธิ์ไว้ที่หนึ่งข้อความ หนึ่งบทสนทนา และหนึ่งรอบการทำงานช่วยลดขอบเขตความเสียหาย แม้เนื้อหาในขอบเขตนั้นยังอาจมีการโจมตีแฝงอยู่
เมทาดาทาแยกจากเนื้อหา ตามเอกสารของ Livara จะมีการเก็บเมทาดาทาเพื่อการทำงาน เช่น ผู้ส่ง ปลายทาง และเวลาส่งถึง เพื่อใช้กำหนดเส้นทางและซิงก์ข้อมูล คู่มือเมทาดาทาของแอปส่งข้อความและข้อมูลที่มันเปิดเผยอธิบายขอบเขตนี้ นอกเหนือจากข้อความ ผู้ช่วยอาจอนุมานจากรูปแบบการติดต่อและเวลาสื่อสารได้ ดังนั้นนโยบายการเข้าถึงต้องคำนึงถึงทั้งสองส่วน
ข้อมูลรั่วไหลจากเอเจนต์ AI ผ่านช่องทางใดบ้าง?
ข้อมูลมักรั่วไหลจากเอเจนต์ AI เมื่อเอเจนต์เห็นเนื้อหาลับในบริบทของตน และมีวิธีส่งไปยังปลายทางอื่น การแทรกคำสั่งเพียงอย่างเดียวไม่ได้เคลื่อนย้ายข้อมูล การรั่วไหลขึ้นอยู่กับการประกอบกันของอินพุตอันตราย สิทธิ์เข้าถึงข้อมูล และช่องทางขาออก
ข้อความหรือไฟล์ขาออก
เอเจนต์อาจใส่ข้อมูลไว้ในคำตอบ ข้อความใหม่ ฉบับร่าง ไฟล์ หรือคำขอไปยังบริการภายนอก หากระบบส่งผลลัพธ์โดยไม่จำกัดหรือไม่ให้ผู้ใช้ยืนยัน ผู้โจมตีอาจพยายามแปลงข้อมูลลับให้มีรูปแบบที่ดูเป็นปกติ
หน่วยความจำระยะยาว
เอเจนต์บางตัวเก็บสรุปบทสนทนา ความชอบ หรือผลลัพธ์ก่อนหน้าไว้ใช้ภายหลัง คำสั่งอันตรายอาจพยายามใส่ข้อมูลลงในหน่วยความจำหรือเรียกคืนในเซสชันอื่น อายุหน่วยความจำที่สั้น การแยกผู้ใช้ และความสามารถในการดูและลบช่วยลดความเสี่ยง แต่ไม่ทำให้ข้อผิดพลาดของโมเดลหมดไป
การเรียกใช้เครื่องมือ
เอเจนต์ที่มีเครื่องมือสามารถค้นหา อ่านไฟล์ หรือทำการอื่นที่ได้รับอนุญาต การอ่านไฟล์ การส่งข้อความ และคำขอเครือข่ายต้องมีสิทธิ์แยกกัน แม้แต่การแสดงลิงก์โดยอัตโนมัติหรือโหลดทรัพยากรภายนอกในผลลัพธ์ ก็อาจสร้างทางออกให้ข้อมูลได้ การไม่มีปุ่ม «ส่ง» เพียงอย่างเดียวจึงไม่พอ
อุปกรณ์ที่ติดมัลแวร์
มัลแวร์ที่มีสิทธิ์เพียงพออาจเห็นข้อความบนหน้าจอ การแจ้งเตือน หน่วยความจำของแอป หรืออินพุตของผู้ใช้ ในกรณีนี้ผู้โจมตีไม่จำเป็นต้องถอดรหัสให้แตก แต่ใช้ประโยชน์จากจุดปลายทาง การป้องกันของระบบปฏิบัติการ การอัปเดต การควบคุมการเข้าถึง และการตรวจแอปที่ติดตั้งเป็นส่วนของการป้องกัน ไม่ใช่ความสามารถของโปรโตคอลส่งข้อความ
การเข้ารหัสของ Livara มีขอบเขตอย่างไรต่อภัยคุกคามนี้?
เอกสารความปลอดภัยของ Livara อธิบาย LVR1 สำหรับแชตโดยตรงและ LGS1 สำหรับกลุ่มส่วนตัวที่เข้ากันได้ กลุ่มเก่าที่ไม่เข้ากันอาจแสดงชัดว่าอยู่นอก E2EE จึงต้องตรวจสถานะของบทสนทนานั้น ช่องสาธารณะก็ไม่ได้อยู่ในขอบเขตแชตส่วนตัวแบบ E2EE
แม้ในบทสนทนา E2EE หากผู้ใช้มอบข้อความที่ถอดรหัสแล้วให้ผู้ช่วย การเข้ารหัสข้อความก็ไม่ควบคุมวัตถุประสงค์ของการประมวลผลภายหลัง การตรวจหมายเลขความปลอดภัยมีไว้ยืนยันกุญแจของผู้ติดต่อ ไม่ใช่ตรวจจับคำสั่งอันตรายในข้อความ บทความนี้กล่าวถึงความเสี่ยงประเภททั่วไป ไม่ได้ยืนยันว่ามีการเชื่อมต่อ AI ใดโดยเฉพาะใน Livara หรือว่าการเชื่อมต่อนั้นปลอดภัย
นี่คือภาพแนวคิด ไม่ใช่สถาปัตยกรรมของ Livara ที่ได้รับการตรวจยืนยัน แม่กุญแจในภาพไม่ได้พิสูจน์ว่าผู้ช่วยเข้าถึงข้อความที่เลือกไม่ได้
สถาปัตยกรรมแบบใดช่วยจำกัดการแทรกคำสั่งในแอปส่งข้อความ?
สถาปัตยกรรมที่ปลอดภัยต้องถือว่าข้อความขาเข้าเป็นข้อมูลที่ไม่น่าเชื่อถือ แม้มาจากผู้ติดต่อที่รู้จักและอยู่ในแชตเข้ารหัส การเข้ารหัสช่วยเสริมความแท้จริงของช่องทาง แต่ไม่ได้พิสูจน์ว่าเนื้อหาจากผู้ส่งปลอดภัยสำหรับการดำเนินการอัตโนมัติ
แยกข้อมูลออกจากคำสั่ง
แอปต้องแยกคำสั่งคงที่ของผู้พัฒนา คำขอที่ชัดแจ้งของผู้ใช้ และเนื้อหาที่อ่านจากแชตไว้คนละชั้น คำเตือนของ NCSC เรื่องการแทรกคำสั่ง เน้นว่าไม่ควรมองปัญหานี้เหมือน SQL Injection ที่จะมีทางแก้เด็ดขาดในลักษณะเดียวกัน การติดป้ายเนื้อหาว่าเป็น «ข้อมูลที่ไม่น่าเชื่อถือ» มีประโยชน์ แต่โมเดลภาษาไม่ได้รักษาขอบเขตทางความหมายนี้อย่างไร้ข้อผิดพลาดเสมอไป จึงต้องมีการควบคุมภายนอกโมเดลควบคู่กับการแยกชั้น
ลดอำนาจของเอเจนต์
เอเจนต์สรุปข้อความไม่จำเป็นต้องส่งข้อความอัตโนมัติหรืออ่านทุกไฟล์ เครื่องมือควรมีรายการอนุญาต ขอบเขตแคบ ข้อมูลรับรองแยกกัน และอายุสิทธิ์สั้น การอนุญาตครั้งเดียวสำหรับเนื้อหาที่เลือกดีกว่าการเข้าถึงถาวร เพราะลดทั้งโอกาสเข้าถึงโดยไม่ตั้งใจและขอบเขตข้อมูลที่อาจรั่วไหล
ตรวจผลลัพธ์ผ่านด่านที่ใช้กฎตายตัว
โมเดลไม่ควรตัดสินใจขั้นสุดท้ายเองว่าจะส่งข้อมูลอ่อนไหวหรือไม่ ชั้นที่ไม่สร้างเนื้อหาสามารถตรวจปลายทาง ชนิดข้อมูล ปริมาณผลลัพธ์ และการกระทำที่ร้องขอตามกฎตายตัว กฎเชิงโครงสร้างและรายการปลายทางที่อนุญาตต้องทำงานนอกโมเดล ส่วนการระบุข้อมูลลับทุกชนิดจากความหมายยังอาจผิดพลาดได้ ต้องมีบันทึกเหตุการณ์เท่าที่จำเป็น การแจ้งเตือน และความสามารถในการหยุดด้วย
ให้มนุษย์ยืนยันการกระทำที่อ่อนไหว
การอ่านฉบับร่างไม่เหมือนการส่ง การส่งข้อความ แชร์ไฟล์ เพิ่มสมาชิก เปลี่ยนการตั้งค่าบัญชี หรือโอนข้อมูลไปบริการภายนอกต้องมีตัวอย่างล่วงหน้าที่ชัดเจนและการยืนยันโดยเข้าใจผล การยืนยันที่คลุมเครือหรือถี่เกินไปทำให้คลิกตามความเคยชิน อินเทอร์เฟซจึงต้องแสดงข้อมูล ปลายทาง และผลที่จะเกิดขึ้นอย่างเจาะจง
รันเอเจนต์ในสภาพแวดล้อมจำกัด
การแยกกระบวนการ ปิดเครือข่ายเป็นค่าเริ่มต้น ใช้พื้นที่เก็บข้อมูลชั่วคราว และใช้ข้อมูลรับรองขอบเขตแคบช่วยจำกัดผลของความล้มเหลว มาตรการเหล่านี้ไม่ได้ขจัด Prompt Injection แต่ป้องกันไม่ให้คำตอบที่เบี่ยงเบนกลายเป็นการเข้าถึงอย่างกว้างขวางโดยตรง
ผู้ใช้และผู้ดูแลระบบควรทำอะไรเพื่อความปลอดภัยของแชตบอต AI?
ผู้ใช้ควรมองทุกการเชื่อมต่อ AI เป็นผู้รับรายใหม่ของข้อมูลส่วนตัว ผู้ดูแลระบบต้องตรวจการไหลของข้อมูลและการกระทำของเอเจนต์ก่อนนำไปใช้ และติดตามขณะทำงาน
สำหรับการใช้ส่วนตัว:
- เลือกเฉพาะข้อความหรือไฟล์ที่จำเป็น อย่าให้เข้าถึงประวัติทั้งหมด
- ตรวจสถานที่ประมวลผล ระยะเวลาเก็บรักษา การใช้ฝึกโมเดล และวิธีลบข้อมูล
- ปิดการส่งข้อความหรือไฟล์อัตโนมัติไว้ เว้นแต่มีความจำเป็นชัดเจน
- อัปเดตอุปกรณ์ เบราว์เซอร์ และแอปอยู่เสมอ และทบทวนสิทธิ์ที่อ่อนไหว
สำหรับองค์กร:
- จัดทำแบบจำลองภัยคุกคามที่แยกครอบคลุมผู้ส่งประสงค์ร้าย สมาชิกกลุ่มที่ทรยศ บริการโมเดล เครื่องมือภายนอก และอุปกรณ์ติดมัลแวร์
- บันทึกการเรียกเครื่องมือ การเปลี่ยนสิทธิ์ ปลายทางขาออก และการยืนยันของผู้ใช้ โดยใช้ข้อมูลอ่อนไหวให้น้อยที่สุดเท่าที่จำเป็น
- ทดสอบอินพุตที่มุ่งโจมตีในข้อความ เอกสาร ข้อความที่อ้างมา ภาพที่มีข้อความ และเนื้อหาที่ดึงมา
- กำหนดเพดานการกระทำ อัตราคำขอ ปลายทางที่อนุญาต และสวิตช์หยุดฉุกเฉินสำหรับเอเจนต์แต่ละตัว
- กำหนดให้หยุดอย่างปลอดภัยเป็นค่าเริ่มต้น หากนโยบายคลุมเครือ เอเจนต์ต้องหยุด ไม่ใช่เดา
ไม่มีรายการตรวจสอบใดสร้างความปลอดภัยได้ทั้งหมด ผลขึ้นอยู่กับการนำไปใช้ โมเดล การตั้งค่า พฤติกรรมผู้ใช้ และวิธีโจมตีที่เปลี่ยนไป เป้าหมายของการป้องกันที่ดีคือลดอำนาจ เปิดให้เห็นการเบี่ยงเบน และจำกัดความเสียหาย
แอปส่งข้อความเข้ารหัสกับ AI จะทำงานร่วมกันอย่างปลอดภัยได้หรือไม่?
ได้ แอปส่งข้อความเข้ารหัสกับ AI สามารถทำงานร่วมกันภายใต้ความเสี่ยงที่ควบคุมได้ หากผู้ช่วยมีสิทธิ์เข้าถึงน้อยที่สุดและไม่ทำสิ่งอ่อนไหวโดยไม่มีการยืนยัน อย่างไรก็ตาม การเชื่อมโมเดลใดก็ตามกับเนื้อหาส่วนตัวสร้างขอบเขตความไว้วางใจใหม่ และไม่ควรซ่อนประเด็นนี้ไว้ใต้ชื่อ E2EE
การออกแบบที่เสี่ยงน้อยกว่าจะคงการประมวลผลบนอุปกรณ์ให้มากที่สุด จำกัดบริบทตามการเลือกอย่างชัดแจ้งของผู้ใช้ ใช้หน่วยความจำอายุสั้น และแยกเครื่องมือส่งข้อมูลออก แต่การประมวลผลบนเครื่องก็ไม่ใช่การรับประกันเด็ดขาด อุปกรณ์ติดมัลแวร์ โมเดลไม่ปลอดภัย หรือสิทธิ์กว้างยังสร้างความเสี่ยงได้
ผู้ใช้ต้องเข้าใจได้ว่าข้อมูลใดไปถึงโมเดล โมเดลทำงานที่ไหน เก็บอะไรไว้นานเพียงใด และทำอะไรได้ หากผลิตภัณฑ์ไม่ตอบคำถามเหล่านี้ให้ชัดเจน ก็ไม่ควรสรุปความปลอดภัยอย่างแน่นอนจากคำอย่าง «AI ส่วนตัว»
เอกสารโปรโตคอลหรือการตรวจค่าแฮชของแอปให้ตรงกัน ไม่ใช่การทดสอบความปลอดภัยของผู้ช่วยที่เชื่อมต่อ ก่อนเปิดการเชื่อมต่อ ให้ตรวจสิทธิ์และเส้นทางข้อมูลของความสามารถนั้นแยกต่างหาก ผลทดสอบที่สำเร็จหนึ่งครั้งก็ไม่ได้ครอบคลุมอินพุตทั้งหมดในอนาคตด้วยตัวมันเอง
คำถามที่พบบ่อย
การเข้ารหัสจากต้นทางถึงปลายทางหยุด Prompt Injection ได้หรือไม่?
ไม่ได้ การเข้ารหัสจากต้นทางถึงปลายทางซ่อนข้อความจากตัวกลางระหว่างผู้ส่งกับผู้รับที่ได้รับอนุญาต หากบอตที่ได้รับสิทธิ์ แอปบนอุปกรณ์ หรือมัลแวร์เข้าถึงข้อความที่ถอดรหัสแล้ว ก็ประมวลผลข้อความนั้นได้ การจำกัด Prompt Injection ต้องจำกัดสิทธิ์ เครื่องมือ หน่วยความจำ และข้อมูลขาออกของเอเจนต์
การใช้ AI สรุปแชตส่วนตัวอันตรายหรือไม่?
ความเสี่ยงขึ้นอยู่กับสถาปัตยกรรม การสรุปข้อความที่เลือกหนึ่งข้อความบนเครื่อง โดยไม่มีหน่วยความจำและเครื่องมือส่งข้อมูลออก มีขอบเขตความเสี่ยงน้อยกว่าบอตคลาวด์ที่เข้าถึงทุกแชตอย่างถาวร ก่อนใช้ควรตรวจสถานที่ประมวลผล การเก็บข้อมูล ขอบเขตสิทธิ์ และความสามารถส่งอัตโนมัติ
ข้อความจากผู้ติดต่อที่รู้จักอาจมี Prompt Injection ได้หรือไม่?
ได้ ความเชื่อถือในตัวตนของผู้ส่งไม่เท่ากับความเชื่อถือในเนื้อหาทั้งหมดของเขา บัญชีอาจถูกยึด หรือเขาอาจส่งต่อข้อความอันตรายโดยไม่ตั้งใจ เนื้อหาทุกอย่างที่เอเจนต์อ่านต้องถือเป็นข้อมูลที่ไม่น่าเชื่อถือ แม้อยู่ในบทสนทนาที่รับรองความแท้จริงและเข้ารหัสแล้ว
LVR1 และ LGS1 ซ่อนข้อมูลจากผู้ช่วย AI หรือไม่?
ในบทสนทนาที่ได้รับการปกป้องด้วย LVR1 หรือ LGS1 จริงและมี E2EE เปิดใช้งาน เป้าหมายของโปรโตคอลเหล่านี้คือซ่อนเนื้อหาจากตัวกลางที่ไม่มีกุญแจ หากผู้ใช้หรือแอปอนุญาตให้ผู้ช่วยอ่านข้อความหลังถอดรหัส โปรโตคอลเหล่านี้จะไม่ปิดกั้นการเข้าถึงที่ได้รับอนุญาตนั้น จึงต้องประเมินความปลอดภัยของผู้ช่วยแยกจากความปลอดภัยในการส่งข้อความ
ขั้นแรกในการลดการรั่วไหลของข้อมูลจากเอเจนต์ AI คืออะไร?
เริ่มจากลดขอบเขตการเข้าถึงของเอเจนต์ ให้เฉพาะข้อความที่เลือก เฉพาะรอบนั้น และไม่สามารถส่งอัตโนมัติได้ จากนั้นเพิ่มตัวอย่างล่วงหน้าและการยืนยันจากมนุษย์สำหรับการกระทำที่อ่อนไหว จำกัดปลายทางขาออก และบันทึกการเรียกเครื่องมือ ชั้นป้องกันเหล่านี้ลดความเสี่ยง แต่ไม่รับประกันเด็ดขาด
