คำตอบเผยแพร่แล้ว13 แหล่งที่มา
ข้ออ้างข้อมูล 6TB ชี้ LLM Router อาจกลายเป็นจุดรวมความลับขององค์กร
Chaofan Shou อ้างว่าข้อมูลการเรียกใช้โมเดลราว 6TB จาก LLM Router ในจีนมี SSH key, การตั้งค่า VPN, ข้อมูล Alibaba Cloud และ GitLab token ซึ่งอ้างว่าเชื่อมโยงกับบริษัท 19 แห่งและหน่วยงานภาครัฐ/เกี่ยวข้องกับภาครัฐ 7 แห่ง LLM Router ที่เห็นข้อความคำขอและคำตอบแบบ plaintext อาจเก็บ prompt, บริบทของเอเจนต์ และพารามิเตอร์เร...
เผยแพร่โดยแก้ไขด้วย GPT-5.6 Terraรูปภาพสร้างด้วย GPT Image 2
คำตอบการวิจัย
ประเด็นสำคัญ
- Chaofan Shou อ้างว่าข้อมูลการเรียกใช้โมเดลราว 6TB จาก LLM Router ในจีนมี SSH key, การตั้งค่า VPN, ข้อมูล Alibaba Cloud และ GitLab token ซึ่งอ้างว่าเชื่อมโยงกับบริษัท 19 แห่งและหน่วยงานภาครัฐ/เกี่ยวข้องกับภาครัฐ 7 แห่ง
- LLM Router ที่เห็นข้อความคำขอและคำตอบแบบ plaintext อาจเก็บ prompt, บริบทของเอเจนต์ และพารามิเตอร์เรียกเครื่องมือ ซึ่งอาจรวมถึงความลับที่นักพัฒนาใส่เข้าไป
- ยังไม่มีหลักฐานยืนยันอิสระถึงที่มาหรือความครบถ้วนของชุดข้อมูล ความใช้ได้จริงของข้อมูลรับรอง การบุกรุกสำเร็จ หรือคำยืนยันอย่างเป็นทางการจากองค์กรที่ถูกเอ่ยชื่อ
AI พรอมต์
openai.comCreate a landscape editorial hero image for this Studio Global article: What did security researcher Chaofan Shou, co-founder of Fuzzland, claim after purchasing roughly 6TB of model-invocation logs from a Chines. Article summary: Shou’s account is a serious supply-chain-risk allegation, not a verified breach report. He said that about 6 TB of “Fable” model-invocation data bought from a leading Chinese LLM router contained secrets sufficient to ac. Topic tags: general, general web, user generated, academic. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, char
ข้ออ้างของ Chaofan Shou นักวิจัยด้านความปลอดภัยและผู้ร่วมก่อตั้ง Fuzzland ทำให้ความเสี่ยงที่มักถูกมองข้ามของห่วงโซ่อุปทาน AI กลับมาเป็นประเด็นสำคัญ นั่นคือผู้ให้บริการตัวกลางที่อยู่ระหว่างแอปพลิเคชันกับผู้ให้บริการโมเดลภาษา หรือ LLM Router/Relay/Proxy
Shou ระบุในโพสต์สาธารณะว่า เขาซื้อข้อมูลการเรียกใช้โมเดลชื่อ “Fable” ปริมาณราว 6TB จาก LLM Router รายใหญ่ของจีน และพบข้อมูลรับรองที่อาจใช้เข้าถึงระบบของหน่วยงานภาครัฐหรือที่เกี่ยวข้องกับภาครัฐในจีน/กลุ่ม CIS 7 แห่ง และบริษัทจีนขนาดใหญ่ 19 แห่ง โดยยกชื่อ Huawei, Xiaomi, NIO และ MiniMax เป็นตัวอย่าง 11
อย่างไรก็ดี นี่คือ ข้ออ้างที่ยังไม่ได้รับการยืนยันอิสระ ไม่ใช่รายงานการรั่วไหลที่ได้รับการพิสูจน์แล้ว และไม่ได้หมายความว่าองค์กรที่ถูกเอ่ยชื่อถูกเจาะระบบจริง
เขาอ้างว่าพบอะไรในล็อก
ตามคำกล่าวของ Shou และรายงานที่ตามมา ชุดข้อมูลดังกล่าวมีข้อมูลอ่อนไหวที่ผู้ใช้ส่งผ่านตัวกลาง เช่น
ข้อมูลประเภทนี้อาจสร้างผลกระทบรุนแรงได้ หากยังใช้งานได้จริง ระบุเจ้าของได้ถูกต้อง และมีสิทธิ์เข้าถึงในวงกว้าง แต่ข้อมูลสาธารณะที่มีอยู่ยังไม่พิสูจน์ว่าความลับเหล่านี้ใช้ได้ในเวลาที่ได้มา ถูกเพิกถอนแล้วหรือไม่ หรือให้สิทธิ์เข้าถึงได้ตามที่ Shou อ้างหรือไม่
เหตุใด LLM Router จึงอาจกลายเป็นจุดรวมข้อมูลรับรอง
LLM Router คือบริการที่คั่นกลางระหว่างแอปหรือ AI agent กับผู้ให้บริการโมเดลต้นทาง หน้าที่อาจเป็นการส่งต่อคำขอ เลือกโมเดล หรือกระจายทราฟฟิกไปยังหลายผู้ให้บริการ แต่การออกแบบลักษณะนี้อาจทำให้ตัวกลางมองเห็น payload ทั้งคำขอและคำตอบในรูปแบบข้อความปกติ รวมถึง prompt, บริบทของ agent, อาร์กิวเมนต์ในการเรียกเครื่องมือ และผลลัพธ์จากโมเดล
งานวิจัย Your Agent Is Mine ซึ่ง Shou เป็นผู้ร่วมเขียน อธิบายว่า Router เหล่านี้ทำหน้าที่เป็น application-layer proxy ที่เข้าถึง JSON ระหว่างส่งได้แบบ plaintext และระบบนิเวศปัจจุบันยังไม่มีการบังคับใช้การตรวจสอบความถูกต้องเชิงเข้ารหัสระหว่างไคลเอนต์กับโมเดลต้นทาง 27
จุดเสี่ยงจึงตรงไปตรงมา: นักพัฒนาอาจส่ง private key, ไฟล์ .env, cloud key, โปรไฟล์ VPN หรือค่าคอนฟิกสำหรับ deploy เข้าไปในบริบทของ AI coding agent เพื่อให้ช่วยวิเคราะห์หรือทำงานอัตโนมัติ หาก agent นั้นส่งคำขอผ่าน Relay ภายนอก ความลับดังกล่าวก็อาจผ่านไปถึงผู้ให้บริการตัวกลางด้วย
ความเสี่ยงไม่ได้จำกัดอยู่ที่ผู้ให้บริการ Router ตั้งใจเก็บข้อมูลเท่านั้น การเก็บล็อกมากเกินไป การควบคุมสิทธิ์ที่อ่อนแอ การถูกเจาะ หรือการส่งต่อข้อมูลล็อกให้บุคคลอื่น ล้วนเปลี่ยนประวัติ prompt ให้เป็นคลังข้อมูลรับรองที่นำไปใช้ซ้ำได้
ไม่ใช่แค่แอบดูข้อมูล แต่มีความเสี่ยงต่อการแก้ไขคำสั่ง
ข้ออ้างชุดข้อมูล 6TB สอดคล้องกับความกังวลเชิงสถาปัตยกรรมที่กว้างกว่า แม้จะยังไม่พิสูจน์ว่า Router ที่ Shou กล่าวถึงกระทำผิดก็ตาม
ใน Your Agent Is Mine นักวิจัยศึกษาการโจมตีผ่านตัวกลางที่เป็นอันตรายต่อห่วงโซ่อุปทานของ LLM agent โดยชี้ว่า Router ที่มองเห็นทราฟฟิกอาจไม่ได้ทำได้เพียงเก็บข้อมูล แต่ยังอาจแก้ไขคำตอบของโมเดลหรือเนื้อหา tool call ก่อนที่ agent จะนำไปปฏิบัติได้ 27
สำหรับทีมที่ใช้งาน agent แบบกึ่งอัตโนมัติหรืออัตโนมัติเต็มรูปแบบ ประเด็นนี้แยกได้เป็น 3 ด้าน
- การเปิดเผยแบบรับข้อมูล: ความลับที่อยู่ใน prompt, trace หรืออาร์กิวเมนต์ของเครื่องมืออาจถูกบันทึกไว้ในล็อก Router
- การดัดแปลงแบบรุก: ตัวกลางอาจพยายามเขียนคำตอบหรือ tool call ใหม่ จนเปลี่ยนสิ่งที่ agent ทำต่อไป
- การนำข้อมูลรับรองไปใช้ผิดวัตถุประสงค์: เส้นทางที่ถูกโจมตีหรือมีเจตนาร้ายอาจเปิดเผยข้อมูลรับรองในบริบทของ agent หรือชักจูงวิธีที่ agent ใช้ข้อมูลเหล่านั้น
งานวิจัยนี้ยืนยันว่าพื้นผิวการโจมตีของการทำ LLM routing ผ่านบุคคลที่สามมีอยู่จริง แต่ไม่ได้ยืนยันแหล่งที่มา ความครบถ้วน หรือเนื้อหาของชุดข้อมูล 6TB ในข้ออ้างภายหลัง 27
สิ่งที่ยังไม่ยืนยัน
เส้นแบ่งด้านหลักฐานต้องชัดเจน ข้อมูลสาธารณะยังไม่ยืนยันโดยอิสระว่า
- ชุดข้อมูลราว 6TB เป็นของจริง ครบถ้วน และมาจาก Router ตามที่อ้างหรือไม่
- ผู้ดำเนินการ Relay คือใคร หรือขายข้อมูลโดยรู้เห็น หรือเป็นเหยื่อของการขโมยข้อมูลจากภายนอก
- เก็บข้อมูลเมื่อใด นานเพียงใด และจัดการข้อมูลอย่างไร
- ข้อมูลรับรองยังใช้งานได้ ระบุถึงองค์กรที่เอ่ยชื่อได้ถูกต้อง และมีสิทธิ์เพียงพอต่อการเข้าถึงที่กล่าวอ้างหรือไม่
- Shou ใช้ข้อมูลรับรองเหล่านั้น เข้าถึงระบบ หรือเกิดการบุกรุกสำเร็จจริงหรือไม่
- Huawei, Xiaomi, NIO, MiniMax, หน่วยงานที่เกี่ยวข้อง หรือผู้ให้บริการ Relay มีคำยืนยันหรือคำชี้แจงอย่างเป็นทางการหรือไม่
11
3
ดังนั้น คำว่า “เชื่อมโยงกับ” ในกรณีนี้ควรตีความว่า ถูกอ้างว่าปรากฏอยู่ในชุดข้อมูล ไม่ใช่การยืนยันว่าองค์กรใดองค์กรหนึ่งเกิดเหตุข้อมูลรั่วหรือถูกเจาะระบบ
องค์กรที่ใช้ LLM Proxy ควรทำอะไรตอนนี้
บทเรียนเชิงปฏิบัติไม่ได้ขึ้นอยู่กับว่าข้ออ้างชุดข้อมูลนี้จะได้รับการยืนยันในท้ายที่สุดหรือไม่ เพราะตัวกลางภายนอกทุกแห่งที่รับส่งทราฟฟิกของ agent ควรถูกประเมินว่าเป็นส่วนหนึ่งของขอบเขตความปลอดภัยที่มีสิทธิ์สูง
1. อย่าใส่ความลับใน prompt หรือบริบทของ agent
ห้ามวาง private key, ไฟล์ VPN, cloud access key, access token, ไฟล์ .env หรือคอนฟิกระบบ production ลงใน prompt ควรมีการตรวจจับและบล็อกหรือปกปิดข้อมูลลับฝั่งไคลเอนต์หรือ internal gateway ก่อนคำขอออกนอกองค์กร
2. ใช้สิทธิ์ระยะสั้นและจำกัดขอบเขต
ให้เครื่องมือรับข้อมูลรับรองที่จำกัดสิทธิ์และหมดอายุ โดยดึงมาเมื่อจำเป็นจาก secrets manager หรือระบบ workload identity แทนการใส่คีย์ที่ใช้ซ้ำได้ลงในประวัติสนทนา โทเค็นอายุสั้นที่มีสิทธิ์น้อยช่วยจำกัดความเสียหายได้หาก trace หรือ Router log รั่วไหล
3. หมุนเวียนข้อมูลรับรองเมื่อสงสัยว่าผ่าน Proxy ที่เสี่ยง
ทำบัญชีรายชื่อ Relay และ Proxy ที่นักพัฒนา, coding assistant และ agent ใช้งาน หากข้อมูลรับรองอ่อนไหวอาจเคยผ่านตัวกลางที่ไม่รู้จักหรือไม่น่าเชื่อถือ ให้หมุนเวียนคีย์ทันที และตรวจสอบ audit log ของ SSH, VPN, GitLab และระบบคลาวด์เพื่อหาพฤติกรรมผิดปกติ
4. เลือกเส้นทางตรงหรือ Gateway ที่องค์กรควบคุม
หากทำได้ ให้เชื่อมต่อผู้ให้บริการโมเดลโดยตรง หรือใช้ gateway ภายในที่องค์กรดูแลเอง หากจำเป็นต้องใช้ Relay ภายนอกหรือเส้นทางที่ให้บริการในจีน ควรประเมินโครงสร้างความเป็นเจ้าของ ที่จัดเก็บข้อมูล ผู้รับจ้างช่วง มาตรการความปลอดภัย เงื่อนไขแจ้งเหตุ และข้อผูกพันเรื่องการบันทึก การฝึกโมเดล การขาย หรือการนำข้อมูลลูกค้าไปใช้ต่อ
5. จำกัดสิ่งที่ agent มีสิทธิ์สั่งทำ
กำหนดให้การดำเนินการอ่อนไหวต้องผ่านการอนุมัติ ใช้ allowlist สำหรับเครื่องมือและปลายทาง และเฝ้าระวังการเปลี่ยนแปลงที่ไม่คาดคิดของชื่อโมเดล รูปแบบคำตอบ schema ของเครื่องมือ หรือ outbound tool call วิธีนี้ช่วยลดผลกระทบจากการดัดแปลงเส้นทางตอบกลับตามที่งานวิจัยกล่าวถึง 27
6. ปกป้อง agent log ไม่ต่างจากความลับของระบบจริง
ปิดการบันทึกเนื้อหาเมื่อทำได้ หากจำเป็นต้องเก็บล็อก ควรปกปิดข้อมูลลับก่อนจัดเก็บ เข้ารหัส จำกัดผู้เข้าถึง กำหนดระยะเวลาเก็บรักษาให้สั้นและชัดเจน และป้องกันการส่งออกข้อมูลโดยไม่มีการควบคุม อาร์กิวเมนต์ของเครื่องมือและ agent trace ควรได้รับการคุ้มครองในระดับเดียวกับซอร์สโค้ด ข้อมูลรับรอง และคอนฟิก production
สรุป
ข้ออ้างเรื่องข้อมูล 6TB ของ Shou ควรถูกมองว่าเป็นข้อกล่าวหาที่ยังไม่ยืนยัน แต่มีนัยสำคัญต่อความปลอดภัยของระบบ AI บทเรียนที่คงอยู่ไม่ว่าข้ออ้างนี้จะพิสูจน์ได้หรือไม่ คือ LLM Router ไม่ใช่เพียง “ท่อส่งข้อมูล” ที่เป็นกลาง หากมันอ่านข้อความ prompt, ข้อมูลรับรอง, อินพุตของเครื่องมือ และคำตอบที่วิ่งผ่านได้ องค์กรที่ใช้งาน AI agent จึงควรถือว่าการเพิ่ม Relay ภายนอกทุกแห่ง คือการขยายขอบเขตของระบบที่ต้องไว้วางใจ และออกแบบมาตรการด้าน prompt hygiene, การจัดการข้อมูลรับรอง, การบันทึกล็อก และการควบคุมการปฏิบัติการให้เหมาะสม 11
27
Studio Global AI
ทำการวิจัยต่อ
หน้านี้รวมคำตอบที่ได้รับการสนับสนุนจากแหล่งที่มาซึ่งคุณสามารถดำเนินการต่อภายใน Studio Global
คนยังถาม
คำตอบสั้น ๆ สำหรับ "ข้ออ้างข้อมูล 6TB ชี้ LLM Router อาจกลายเป็นจุดรวมความลับขององค์กร" คืออะไร
Chaofan Shou อ้างว่าข้อมูลการเรียกใช้โมเดลราว 6TB จาก LLM Router ในจีนมี SSH key, การตั้งค่า VPN, ข้อมูล Alibaba Cloud และ GitLab token ซึ่งอ้างว่าเชื่อมโยงกับบริษัท 19 แห่งและหน่วยงานภาครัฐ/เกี่ยวข้องกับภาครัฐ 7 แห่ง
ประเด็นสำคัญที่ต้องตรวจสอบก่อนคืออะไร?
Chaofan Shou อ้างว่าข้อมูลการเรียกใช้โมเดลราว 6TB จาก LLM Router ในจีนมี SSH key, การตั้งค่า VPN, ข้อมูล Alibaba Cloud และ GitLab token ซึ่งอ้างว่าเชื่อมโยงกับบริษัท 19 แห่งและหน่วยงานภาครัฐ/เกี่ยวข้องกับภาครัฐ 7 แห่ง LLM Router ที่เห็นข้อความคำขอและคำตอบแบบ plaintext อาจเก็บ prompt, บริบทของเอเจนต์ และพารามิเตอร์เรียกเครื่องมือ ซึ่งอาจรวมถึงความลับที่นักพัฒนาใส่เข้าไป
ฉันควรทำอย่างไรต่อไปในทางปฏิบัติ?
ยังไม่มีหลักฐานยืนยันอิสระถึงที่มาหรือความครบถ้วนของชุดข้อมูล ความใช้ได้จริงของข้อมูลรับรอง การบุกรุกสำเร็จ หรือคำยืนยันอย่างเป็นทางการจากองค์กรที่ถูกเอ่ยชื่อ