- 03
- กันยายน
Reasoning Trace Leak คือการที่ “ความคิดระหว่างทาง” ของโมเดล AI ซึ่งผู้ให้บริการเข้ารหัสไว้ ถูกดึงกลับออกมาเป็นข้อความอ่านได้ โดยไม่ต้องมีกุญแจถอดรหัส และในเดือนสิงหาคม 2569 มีงานวิจัยแสดงให้เห็นว่า วิธีที่ได้ผลคือเอาบล็อกที่เข้ารหัสไว้ไปป้อนให้โมเดลรุ่นเล็กกว่าของค่ายเดียวกันเป็นคนถอดให้ ช่องโหว่นี้เกิดกับ OpenAI, Anthropic และ Google เหมือนกันทั้งสามราย บทความนี้อธิบายว่ามันทำงานอย่างไร ถอดออกมาเจออะไรบ้าง และองค์กรที่กำลังต่อ AI เข้ากับระบบงานภายในควรเปลี่ยนอะไร
สรุปบรรทัดเดียว: บล็อก reasoning ที่เข้ารหัสไว้ของทั้งสามค่ายใช้กุญแจกลางชุดเดียว จึงถูก replay ข้าม session ผู้ใช้ และโมเดลได้ ทีมวิจัยถอดจาก log สาธารณะ 315,320 บล็อก พบ credential 182 รายการ — ผู้ให้บริการแพตช์แล้วเมื่อสิงหาคม 2569
reasoning block คืออะไร และทำไมผู้ให้บริการถึงเข้ารหัสมันไว้
โมเดลรุ่นใหม่ที่ "คิดก่อนตอบ" จะสร้างข้อความชุดหนึ่งขึ้นมาระหว่างทาง เป็นการไล่เหตุผล ลองผิดลองถูก และตัดตัวเลือกทิ้ง ก่อนจะสรุปเป็นคำตอบที่ผู้ใช้เห็น ข้อความชุดนี้เรียกว่า reasoning trace และมันมีค่าสองทางพร้อมกัน
ทางแรกคือมีค่ากับผู้ให้บริการ เพราะเป็นทรัพย์สินทางปัญญาที่คู่แข่งอยากได้ไปฝึกโมเดลของตัวเอง ทางที่สองคือมีค่ากับผู้โจมตี เพราะระหว่างที่โมเดลคิด มันมักหยิบข้อมูลที่อยู่ในบริบทมาพูดถึงตรง ๆ รวมถึงข้อมูลที่ไม่เคยโผล่ในคำตอบสุดท้าย
ผู้ให้บริการจึงเลือกวิธีเดียวกันหมด คือ เข้ารหัส reasoning trace แล้วส่งกลับมาให้ผู้ใช้ถือไว้ ในรูป blob ที่อ่านไม่ออก เวลาเรียก API รอบถัดไปก็ส่ง blob นั้นกลับไปเพื่อให้โมเดลจำบริบทเดิมได้ วิธีนี้ประหยัดที่เก็บฝั่งเซิร์ฟเวอร์และดูปลอดภัยดี — จนกระทั่งมีคนถามว่า "แล้วใครถอดมันได้บ้าง"
ประเด็นหลักของงานวิจัย: ผู้ให้บริการใช้ กุญแจกลางชุดเดียว ในการเข้ารหัสและรับรอง reasoning block ทุกก้อน ทำให้ก้อนที่ได้จาก session หนึ่ง ผู้ใช้คนหนึ่ง หรือโมเดลตัวหนึ่ง เอาไปใช้กับ session อื่น ผู้ใช้อื่น และโมเดลอื่นในค่ายเดียวกันได้
วิธีโจมตี — ให้โมเดลรุ่นเล็กเป็นคนแปลให้
เมื่อ blob เดินข้ามโมเดลได้ ผู้วิจัยจึงไม่ต้องพยายามถอดรหัสเลย แต่ใช้วิธีที่ตรงกว่านั้นมาก คือ เอา blob ที่ได้จากโมเดลตัวเก่ง ไปยัดใส่โมเดลรุ่นเล็กของค่ายเดียวกัน แล้วสั่งให้มันเขียนสิ่งที่อยู่ข้างในออกมา
โมเดลรุ่นเล็กถอด blob ได้ตามปกติเพราะมันใช้กุญแจชุดเดียวกัน และเมื่อมันถูกฝึกมาด้วยการป้องกันที่บางกว่า มันก็ยอมพิมพ์เนื้อหาข้างในออกมาแบบคำต่อคำ ผลลัพธ์คือได้ความคิดของโมเดลตัวเก่ง โดยไม่ต้อง jailbreak โมเดลตัวเก่งเลยแม้แต่ครั้งเดียว
| ค่าย | โมเดลต้นทางที่ทดสอบ | โมเดลที่ใช้เป็นตัวถอด |
|---|---|---|
| Anthropic | Claude Opus 4.8, Sonnet 5 / 4.6 / 4.5, Fable 5 | Claude Haiku 4.5 |
| OpenAI | GPT-5.6 Sol / Terra / Luna, GPT-5, GPT-5-mini, o4-mini | GPT-5.6 Luna |
| Gemini 3.1 Pro, Gemini 3 Pro, Gemini 3.5 / 3 / 3.1 Flash Lite | Robotics ER-1.6 |
สังเกตว่าทั้งสามค่ายโดนแบบเดียวกัน นี่ไม่ใช่บั๊กของผู้ให้บริการรายใดรายหนึ่ง แต่เป็นผลจากการเลือกออกแบบที่เหมือนกัน คือย้ายภาระการเก็บ state ไปไว้ที่ฝั่งผู้ใช้แล้วป้องกันด้วยการเข้ารหัสอย่างเดียว โดยไม่ได้ผูก blob เข้ากับตัวตนของผู้ใช้หรือ session ที่มันเกิดมา
สี่ทางที่ช่องโหว่นี้ถูกใช้ประโยชน์ได้
| รูปแบบ | เกิดอะไรขึ้น |
|---|---|
| ขโมยไปกลั่นโมเดล | ดึง reasoning trace ของโมเดลระดับแนวหน้าไปฝึกโมเดลตัวเอง โดยไม่ต้องจ่ายค่าเรียกโมเดลตัวเก่งโดยตรง ผู้วิจัยประเมินต้นทุนไว้ราว 720 ดอลลาร์สหรัฐ ต่อ trace 10,000 ชุด |
| ดูดความลับจาก log สาธารณะ | ถอด reasoning ที่ติดมากับ log ของ AI agent ที่คนอัปโหลดขึ้นที่สาธารณะ แล้วเก็บเกี่ยว credential และข้อมูลส่วนบุคคลที่ติดอยู่ข้างใน |
| กู้เนื้อหาที่โมเดลปฏิเสธ | คำตอบที่ผู้ใช้เห็นดูปลอดภัยดี แต่เนื้อหาอันตรายที่โมเดลคิดแล้วตัดทิ้งยังอยู่ใน reasoning block และดึงกลับออกมาได้ |
| ซ่อน prompt injection | ฝังคำสั่งประสงค์ร้ายไว้ในบล็อกที่ผู้ใช้มองไม่เห็น แล้วให้มันทำงานข้าม session — ต่อยอดจากช่องโหว่ที่เราเคยอธิบายไว้ใน บทความเรื่อง Prompt Injection |
ตัวเลขที่ถอดออกมาได้จริง
ส่วนที่ทำให้งานวิจัยนี้ต่างจากงานเชิงทฤษฎีทั่วไป คือทีมวิจัยไม่ได้หยุดที่การพิสูจน์ว่าทำได้ แต่ไปไล่เก็บ log ของ AI agent ที่คนเผยแพร่ไว้ตามที่สาธารณะจริง ๆ แล้วถอดดูว่ามีอะไรอยู่ข้างใน
| สิ่งที่พบ | จำนวน |
|---|---|
| ชุด log การทำงานของ AI agent ที่เก็บมาวิเคราะห์ | 6,708 ชุด |
| reasoning block ที่ถอดออกมาได้ | 315,320 บล็อก |
| ชุด log ที่มีข้อมูลอ่อนไหวอย่างน้อย 1 รายการ | 328 ชุด (4.9%) |
| ข้อมูลส่วนบุคคล (PII) ที่กู้ได้ | 367 รายการ |
| credential ที่กู้ได้ | 182 รายการ — API key 62, รหัสผ่าน 33, access token 24, private key 7 |
| รายการที่ ไม่ปรากฏ ในประวัติแชตที่มองเห็นเลย | 64 รายการ |
บรรทัดที่ควรอ่านซ้ำ: 64 รายการที่กู้ได้ ไม่เคยปรากฏในบทสนทนาที่ผู้ใช้มองเห็น แปลว่าคนที่กด export log แล้วอ่านทวนก่อนอัปโหลด ก็ยังพลาดได้ เพราะสิ่งที่รั่วอยู่ในส่วนที่จอไม่แสดง
เทียบกับความผิดพลาดที่คุ้นเคยกว่า
ถ้ารู้สึกว่าเรื่องนี้ไกลตัว ลองเทียบกับความผิดพลาดที่ทีมพัฒนาทุกที่เคยเจอ คือการเผลอ commit ไฟล์ที่มีรหัสผ่านขึ้น repo แล้วลืมไปว่ามันยังอยู่ในประวัติ ต่อให้ลบไฟล์ทิ้งในภายหลัง ประวัติก็ยังเก็บไว้ และเครื่องมือกวาดหา secret ก็เจอได้อยู่ดี
สิ่งที่เกิดขึ้นกับ reasoning block คือเรื่องเดียวกัน แต่ร้ายกว่าตรงสองจุด จุดแรกคือ คนที่แชร์มองไม่เห็นว่ามีอะไรอยู่ข้างใน เพราะมันเป็น blob ที่อ่านไม่ออก ต่างจากไฟล์ข้อความที่เปิดดูแล้วรู้ทันทีว่ามีรหัสผ่านอยู่ จุดที่สองคือ เครื่องมือกวาดหา secret ที่องค์กรใช้อยู่มองไม่เห็นมันเช่นกัน เพราะสิ่งที่มันสแกนคือข้อความธรรมดา ไม่ใช่ blob ที่ต้องเอาไปให้โมเดลถอดก่อน
ผลคือ log ของ AI agent กลายเป็นไฟล์ประเภทที่ทั้งคนและเครื่องมืออัตโนมัติตรวจไม่เจอ แต่ผู้ที่รู้วิธีถอดกลับอ่านได้หมด นี่คือเหตุผลที่ตัวเลข 64 รายการที่ไม่ปรากฏในแชตเลย ถึงเป็นตัวเลขที่สำคัญที่สุดในงานวิจัยชิ้นนี้
ตอนนี้แก้แล้วหรือยัง
แก้แล้ว ทีมวิจัยแจ้งผู้ให้บริการทั้งสามรายและแพลตฟอร์มที่เกี่ยวข้องก่อนเผยแพร่ และรายงานระบุว่าการโจมตีรูปแบบหลักตามที่สาธิตไว้ ทำซ้ำไม่ได้แล้วตั้งแต่เดือนสิงหาคม 2569 เพราะผู้ให้บริการออก mitigation ฝั่งเซิร์ฟเวอร์
แต่สิ่งที่รั่วไปแล้วไม่กลับมา: การปิดช่องโหว่หยุดการถอดครั้งใหม่ได้ ไม่ได้ทำให้ API key 62 ตัวและรหัสผ่าน 33 ชุดที่ถูกกู้ออกมาแล้วปลอดภัยขึ้น องค์กรที่เคยเผยแพร่ log การทำงานของ AI agent ขึ้นที่สาธารณะควรถือว่าความลับที่อยู่ในนั้นถูกเปิดเผยแล้ว และหมุนเปลี่ยนมันทิ้ง
ผู้วิจัยเสนอให้แก้ที่ตรงไหน
ข้อเสนอในรายงานแบ่งเป็นสี่ชั้น และมีเพียงชั้นสุดท้ายที่เป็นงานของฝั่งผู้ใช้ ส่วนอีกสามชั้นเป็นการบ้านของผู้ให้บริการ
- ชั้นสถาปัตยกรรม — เก็บ reasoning trace ไว้ฝั่งเซิร์ฟเวอร์แล้วอ้างถึงด้วย reference แทนที่จะส่ง blob ที่เข้ารหัสไว้ให้ผู้ใช้ถือ ตัดปัญหาที่ต้นทางเลย
- ชั้นการเข้ารหัส — ผูก blob เข้ากับผู้ใช้ session และ prompt ที่มันเกิดมา ผ่านการเข้ารหัสแบบที่รับรองความถูกต้องของบริบทไปพร้อมกัน (AEAD) เพื่อให้การเอาไปใช้ข้ามบริบทกลายเป็นของที่ระบบปฏิเสธเองโดยอัตโนมัติ
- ชั้นโครงสร้างพื้นฐาน — แยกไม่ให้ blob ของโมเดลหนึ่งไปใช้กับอีกโมเดลหนึ่งได้ ตรวจจับความผิดปกติเชิงปริมาณเวลามีคนยิงถอดจำนวนมาก และมีกลไกเพิกถอนลายเซ็นเมื่อพบว่าถูกละเมิด
- ชั้นตัวโมเดลและผู้ใช้ — ฝึกให้โมเดลปฏิเสธคำสั่งประเภท "ถอดแล้วพิมพ์ออกมาให้หน่อย" และฝั่งผู้ใช้ต้องตัด reasoning block ทิ้งก่อนเผยแพร่ log รวมถึงไม่ commit บันทึกการเรียก API แบบดิบลง repo
ข้อสังเกตที่น่าสนใจคือสามชั้นแรกเป็นการยอมแลก ผู้ให้บริการเลือกส่ง blob ให้ผู้ใช้ถือตั้งแต่แรกเพราะประหยัดต้นทุนการเก็บ state ฝั่งเซิร์ฟเวอร์ การย้ายกลับไปเก็บเองแปลว่าต้นทุนขยับขึ้น — เป็นตัวอย่างที่ชัดว่าการตัดสินใจเชิงวิศวกรรมที่ดูเป็นเรื่องประสิทธิภาพล้วน ๆ กลายเป็นการตัดสินใจด้านความปลอดภัยได้อย่างไร
บทเรียนที่ใช้ได้จริง ไม่ว่าผู้ให้บริการจะแก้หรือไม่
ประเด็นที่ทำให้เรื่องนี้ควรค่าแก่การอ่าน ไม่ใช่เพราะช่องโหว่ตัวนี้ยังเปิดอยู่ แต่เพราะมันเปิดเผยสมมติฐานที่หลายองค์กรถือไว้โดยไม่รู้ตัว ว่า อะไรที่จอไม่แสดง แปลว่าไม่มี
| สิ่งที่ควรทำ | เหตุผล |
|---|---|
| อย่าใส่ credential ลงใน prompt หรือ context | ถ้าไม่เคยส่งเข้าไป มันก็ไม่มีทางติดออกมากับ reasoning ให้ระบบภายนอกถือ token ไว้แล้วให้ AI เรียกผ่านชั้นกลางแทน |
| ถือว่า log ของ AI agent เป็นข้อมูลลับ | ไม่ commit ลง repo ไม่แนบใน issue ไม่อัปโหลดขึ้นที่สาธารณะ และถ้าจำเป็นต้องแชร์ ให้ตัด reasoning block ทิ้งก่อน |
| ให้ AI ทำงานผ่านสิทธิ์ของผู้ใช้ ไม่ใช่ผ่านบัญชี super user | ถ้า context รั่ว ความเสียหายถูกจำกัดอยู่ในขอบเขตที่ผู้ใช้คนนั้นเห็นได้อยู่แล้ว |
| หมุนเปลี่ยน key และ token ตามรอบ | บทเรียนเดียวกับ การโจมตีผ่านตัวตนดิจิทัล — ความลับที่อายุยืนคือความลับที่รั่วแล้วเจ็บนาน |
| เปิดยืนยันตัวตนสองชั้นกับบัญชีสำคัญ | รหัสผ่านที่หลุดจะใช้ไม่ได้ทันทีถ้ายังต้องผ่านชั้นที่สอง อ่านเพิ่มได้ที่ บทความเรื่อง 2FA |
เชื่อมกับการต่อ AI เข้าระบบ ERP
เรื่องนี้ตรงกับคำถามที่เราเจอบ่อยที่สุดเวลาลูกค้าถามเรื่องต่อ AI เข้ากับระบบหลังบ้าน คือ "ข้อมูลจะรั่วไหม" คำตอบที่ซื่อสัตย์คือ ความเสี่ยงหลักไม่ได้อยู่ที่ผู้ให้บริการโมเดลจะแอบเอาข้อมูลไปใช้ แต่อยู่ที่ องค์กรส่งอะไรเข้าไปในบริบท และเก็บร่องรอยของมันไว้ที่ไหน
ตอนออกแบบการเชื่อม Saeree ERP เข้ากับ AI ผ่าน MCP เราจึงยึดสามข้อ ข้อแรก ไม่มี credential อยู่ใน prompt — การยืนยันตัวตนเกิดที่ชั้นเซิร์ฟเวอร์ ไม่ใช่ข้อความที่ส่งให้โมเดลอ่าน ข้อสอง สิทธิ์การเข้าถึงเป็นของผู้ใช้คนนั้น ลงถึงระดับแถวและคอลัมน์ที่เขาเห็นได้ตามปกติ ไม่ใช่เปิดฐานข้อมูลทั้งก้อนให้โมเดล ข้อสาม ทุกการเรียกลง audit trail แยกจากตัวข้อความที่ส่งให้โมเดล เพื่อให้ตรวจย้อนได้ว่าใครถามอะไรเมื่อไร โดยไม่ต้องเก็บบริบทดิบไว้
หลักการเบื้องหลังไม่ได้ใหม่ มันคือหลักการเดียวกับที่เราเขียนไว้ใน บทความเรื่อง Data Governance ของ Claude และ Zero Data Retention คือ ระบบภายในเป็นแหล่งข้อมูลจริงและเป็นเจ้าของสิทธิ์ ส่วนโมเดลเป็นผู้ช่วยที่อ่านเฉพาะสิ่งที่ยื่นให้ และเราควรยื่นให้น้อยที่สุดเท่าที่งานจะเดินได้
ข้อสังเกตที่เป็นบวก: ข้อมูลที่รั่วในงานวิจัยนี้ 4.9% ของ log ทั้งหมด มาจากคนที่เผยแพร่ log เอง ไม่ใช่จากการที่ผู้ให้บริการทำข้อมูลหลุด แปลว่าตัวแปรที่กำหนดความเสี่ยงส่วนใหญ่อยู่ในมือองค์กรเอง และเป็นสิ่งที่แก้ได้ด้วยนโยบายการใช้งาน ไม่ต้องรอใครมาแพตช์ให้
ถ้าอยากเห็นภาพใหญ่ว่าทำไมความปลอดภัยของ AI ถึงกลายเป็นวาระของทั้งอุตสาหกรรมในเดือนนี้ อ่านต่อได้ที่บทความเรื่อง โมเดล AI ไซเบอร์ที่ทั้งสามค่ายปล่อยพร้อมกัน
ความลับที่อันตรายที่สุดไม่ใช่ความลับที่คุณรู้ว่าส่งออกไป แต่คือความลับที่ติดไปกับสิ่งที่จอไม่แสดงให้เห็น
- ไพฑูรย์ บุตรี, บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด
แหล่งอ้างอิง
ตรวจสอบข้อมูลล่าสุด ณ วันที่ 3 กันยายน 2569
- Panfilov และคณะ — Stealing Reasoning Traces from Proprietary LLM APIs (arXiv:2608.09867, 10 ส.ค. 2569)
- The Hacker News — OpenAI, Anthropic, Google API Flaw Let Weaker AI Models Decode Hidden Reasoning (12 ส.ค. 2569)
- Cyber Security News — Top AI Models APIs Flaw Exposes Hidden Reasoning
- NSFOCUS — Encrypted Reasoning Blocks of Proprietary LLMs Can Be Stolen via Cross-Model Replay
สนใจระบบ ERP สำหรับองค์กรของคุณ?
ปรึกษาทีมงาน Grand Linux Solution เรื่องการต่อ AI เข้ากับระบบงานอย่างปลอดภัย — สิทธิ์ระดับผู้ใช้ ไม่มี credential ใน prompt และ audit trail ครบทุกการเรียก
ขอ Demo ฟรีโทร 02-347-7730 | sale@grandlinux.com
