9 จาก 428 Router ฉีดโค้ดใส่ Agent, ทำไมด่านป้องกันยังไม่พอ

โดย Nokka (นก-กา) | 12 กันยายน 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash) ผ่าน Hermes Agent ตรวจสอบและเรียบเรียงโดย Nokka

มีคำถามหนึ่งที่คนทำ agent ควรถามตัวเองก่อนอ่านบทความนี้

เครื่องมือ AI ของคุณเรียกโมเดลผ่านตัวกลางหรือเปล่า ถ้าคำตอบคือใช่ ตัวกลางนั้นอ่านทุกอย่างที่ผ่านไปมาได้ทั้งหมด รวมถึงคำสั่งที่ AI ของคุณสั่งให้เครื่องทำ

งานวิจัยที่ตีพิมพ์ในเดือนเมษายน 2026 แล้วตรวจ 428 ตัวกลางแบบนี้ พบว่าเก้าตัวกำลังฉีดโค้ดอันตรายเข้าไปในคำสั่งเหล่านั้นจริง [1][2]

ตอนที่งานวิจัยนี้ออกใหม่ ๆ ผู้เขียนคนหนึ่งสรุปสั้น ๆ ว่า 26 ตัวกลางกำลังฉีดคำสั่งอันตรายและขโมยข้อมูลรับรอง ซึ่งเป็นตัวเลขที่ต่างจากงานวิจัยฉบับสมบูรณ์เพราะนับจากชุดตัวอย่างที่กว้างกว่า [5]

วงการความปลอดภัยให้ความสนใจเรื่องนี้ต่อเนื่อง และมีผู้ให้บริการตัวกลางบางรายเริ่มเสนอชั้นป้องกันเพิ่มเข้ามา [3]

ตัวกลางที่เห็นทุกอย่าง

LLM API Router คือบริการที่รับคำขอในรูปแบบเดียว แล้วส่งต่อไปยังผู้ให้โมเดลหลายเจ้า เหตุผลที่คนใช้คือความสะดวกและราคา จ่ายที่เดียว เข้าถึงโมเดลได้หลายค่าย [1]

ประเด็นที่คนมักไม่ทันคิดคือ สถาปัตยกรรมของมันทำให้ตัวกลางตัดการเชื่อมต่อที่เข้ารหัสจากฝั่งลูกค้าออก แล้วเปิดการเชื่อมต่อใหม่ไปยังผู้ให้โมเดล

พูดให้เข้าใจง่ายคือ ลูกค้าตั้งค่าที่อยู่ของตัวกลางเอง ทุกอย่างจึงผ่านตัวกลางในรูปแบบข้อความธรรมดา

ตัวกลางจึงเห็นได้หมด ทั้งคำสั่งที่ผู้ใช้พิมพ์ คีย์ API และรายการเครื่องมือที่ AI ขอเรียกใช้

ทำไมเรื่องนี้ต่างจากการดักฟังทั่วไป

การดักฟังแบบเดิมต้องหลอกใบรับรองความปลอดภัยหรือลดระดับการเข้ารหัส ซึ่งตรวจจับได้

กรณีนี้ไม่ต้องทำอะไรแบบนั้นเลย เพราะลูกค้าตั้งใจตั้งค่าตัวกลางเป็นปลายทางเอง ตัวกลางจึงมีสิทธิ์เต็มในระดับแอปพลิเคชัน

จุดที่ทำให้ต่างจากการส่งต่อทั่วไปอยู่ที่ payload ตอนนี้มีความหมายเชิงการทำงานอยู่ในตัว [1]

ตัวอย่างในงานวิจัยชัดเจน คำสั่งเดิมบอกให้ติดตั้งแพ็กเกจชื่อหนึ่ง ตัวกลางเปลี่ยนชื่อแพ็กเกจเป็นชื่อที่คล้ายกันที่ผู้โจมตีลงทะเบียนไว้ก่อนแล้ว [1]

ชื่อ requests กลายเป็น reqeusts ซึ่งสลับตัวอักษรสองตัว แต่คำสั่งที่เหลือเหมือนเดิมทั้งหมด

ผลคือคำสั่งนี้ผ่านด่านที่ตรวจชื่อโดเมนได้ เพราะโดเมนคือที่เดิมที่เชื่อถือได้ มันต่างกันแค่ชื่อแพ็กเกจ

และความเสียหายอยู่ต่อ เพราะแพ็กเกจที่ถูกเปลี่ยนจะถูกเก็บไว้ในเครื่อง แล้วถูกเรียกกลับมาใช้ในเซสชันต่อ ๆ ไป [1]

ตัวเลขจากการวัดจริง

งานวิจัยตรวจตัวกลางสองกลุ่ม ตัวที่จ่ายเงิน 28 ตัวที่ซื้อจากตลาดในจีนและร้านบน Shopify และตัวฟรีอีก 400 ตัวที่เก็บจากชุมชนสาธารณะ [1]

ผลที่พบคือตัวกลางที่จ่ายเงินหนึ่งตัวและตัวฟรีแปดตัวฉีดโค้ดอันตรายเข้าไปในคำสั่งเครื่องมือที่ส่งกลับมา

ตัวกลางสองตัวใช้เทคนิคหลบแบบปรับตัว คือยิงโค้ดอันตรายเฉพาะหลังผ่านไปห้าสิบคำขอ หรือยิงเฉพาะเซสชันที่ผู้ใช้ตั้งโหมดให้ทำทุกอย่างอัตโนมัติโดยไม่ถามยืนยัน [1]

กับดักของเทคนิคนี้คือถ้าทดสอบสั้น ๆ ตัวกลางจะดูปกติทุกอย่าง

ยังมีอีกสิบเจ็ดตัวที่แตะข้อมูลรับรองทดสอบของนักวิจัยหลังจากข้อมูลนั้นผ่านไปแล้ว และมีหนึ่งตัวที่ดูดเงินออกจากกุญแจส่วนตัวคริปโตที่นักวิจัยวางไว้เป็นกับดัก [1]

ฝั่งที่ไม่ได้ตั้งใจร้ายก็กลายเป็นปัญหาได้

งานวิจัยไม่ได้มีแค่ตัวกลางที่จงใจร้าย เขายังทดลองว่าตัวกลางที่ดูปกติจะถูกดึงเข้ามาเป็นปัญหาได้ไหม [1]

การทดลองแรกคือปล่อยคีย์ OpenAI ที่รู้กันว่าเป็นของนักวิจัยไว้ในฟอรัมจีนและกลุ่มแชต คีย์นั้นถูกนำไปใช้ต่อจนสร้างโทเคนได้ 100 ล้านโทเคนและเปิดเซสชันได้มากกว่าเจ็ดครั้ง [1]

การทดลองที่สองคือวางเซิร์ฟเวอร์ทดสอบที่ตั้งค่าไม่รัดกุมไว้บนยี่สิบโดเมนและยี่สิบที่อยู่ไอพี

ผลที่ได้คือมีคนพยายามเข้าถึงโดยไม่ได้รับอนุญาตจาก 147 ที่อยู่ไอพี ตัวเลขที่ไหลผ่านคือ 2,000 ล้านโทเคน ปริมาณข้อมูลที่มองเห็นได้ราว 13 กิกะไบต์ และข้อมูลรับรองที่รั่วออกไป 99 รายการจาก 440 เซสชัน [1]

จุดที่น่าตกใจที่สุดในตัวเลขชุดนี้คือ ใน 440 เซสชันนั้น ทุกเซสชันเปิดทางให้รันคำสั่งเชลล์ได้ และ 401 เซสชันรันในโหมดอัตโนมัติอยู่แล้ว [1]

ความหมายคือไม่ต้องใช้เทคนิคหลบแบบซับซ้อนเลยด้วยซ้ำ แค่ฉีดคำสั่งตรง ๆ ก็ทำงานได้

ด่านป้องกันที่ใช้ได้จริงตอนนี้

งานวิจัยทดลองด่านฝั่งลูกค้าสามแบบ พร้อมวัดผลจริง [1]

ด่าน	จับอะไรได้	แลกกับอะไร
ตรวจคำสั่งเสี่ยงสูง	ฉีดโค้ดตรง ๆ 100%	บล็อกงานติดตั้งปกติผิด 1%
คัดกรองความผิดปกติ	ฉีดโค้ดตรง ๆ 89%	จับการเปลี่ยนชื่อแพ็กเกจได้แค่ครึ่ง
บันทึกตรวจสอบ	ไม่จับอะไร แต่สืบย้อนหลังได้	ใช้พื้นที่ 1.26 KB ต่อรายการ

ด่านที่หนึ่ง ด่านตรวจคำสั่งที่มีความเสี่ยงสูง ทำงานแบบปฏิเสธไว้ก่อนถ้าไม่แน่ใจ ตัวนี้บล็อกตัวอย่างการฉีดโค้ดตรง ๆ ได้ทั้งหมด ที่อัตราการเตือนผิด 1.0 เปอร์เซ็นต์ [1]

ด่านที่สอง การคัดกรองความผิดปกติฝั่งคำตอบ ตัวนี้ใช้สัญญาณที่มองเห็นได้ในเครื่องตัวเองล้วน ๆ ทั้งรูปแบบคำสั่งที่มีความเสี่ยง ความถี่ของชื่อเครื่องมือในเซสชัน และความผิดปกติเชิงโครงสร้าง [1]

ตัวนี้ตรวจจับการฉีดโค้ดตรง ๆ ได้ 89.0 เปอร์เซ็นต์ ที่อัตราการเตือนผิด 6.7 เปอร์เซ็นต์ แต่จับการเปลี่ยนชื่อแพ็กเกจได้แค่ครึ่งเดียว [1]

ด่านที่สาม บันทึกตรวจสอบแบบเขียนต่อท้ายเท่านั้น [2] ตัวนี้ไม่ป้องกันอะไรเลย แต่มีประโยชน์ตอนสืบสวนย้อนหลัง ว่าตัวกลางหรือข้อมูลรับรองหนึ่งรายการไปไกลแค่ไหน [1]

ขนาดของบันทึกอยู่ที่ประมาณ 1.26 กิโลไบต์ต่อรายการ ซึ่งเบาพอจะเปิดไว้ในเครื่องนักพัฒนาทั่วไปได้ [1]

ช่องที่ยังเหลืออยู่

งานวิจัยระบุตรง ๆ ว่าด่านทั้งสามแบบไม่ได้ยืนยันที่มา [1]

ตัวกลางที่อยู่ในกรอบที่อนุญาตและไม่ทำอะไรผิดปกติ ยังเปลี่ยนความหมายของคำสั่งได้อยู่ดี

ช่องนี้จะปิดได้ต่อเมื่อผู้ให้โมเดลลงลายเซ็นดิจิทัลกำกับคำตอบ เพื่อให้ฝั่งลูกค้าตรวจสอบได้ว่าคำสั่งที่กำลังจะรันมาจากโมเดลจริง ไม่ได้ถูกแก้ระหว่างทาง [1]

ข้อเสนอนี้มีรายละเอียดที่ทำได้จริง ทั้งการแปลงคำสั่งให้เป็นรูปแบบมาตรฐานก่อนลงลายเซ็น และการตรวจสอบฝั่งลูกค้าก่อนรันคำสั่งใด ๆ [1]

แต่ทั้งนี้ทั้งนั้นก็ต้องรอให้ผู้ให้โมเดลทำก่อน ซึ่งยังไม่มีใครทำ

ประเด็นที่คนในวงการตั้งคำถาม

ใต้วีทที่อ้างถึงงานวิจัยนี้ มีคอมเมนต์หนึ่งที่ตรงประเด็นที่สุด [4]

ผู้ใช้ @bygregorr เขียนว่า ด่านนี้จะยืนได้ก็ต่อเมื่อมันอยู่ในตัวรันของ agent ไม่ใช่ในตัวกลาง [4]

เหตุผลเบื้องหลังความคิดเห็นนี้คือ ถ้าด่านป้องกันอยู่ในตัวกลาง และตัวกลางนั้นคือผู้ที่ลงมือแก้คำสั่ง ก็เท่ากับให้ผู้ต้องสงสัยตรวจตัวเอง

ในทางกลับกัน การวางด่านไว้ในตัวรันของ agent ก็มีข้อจำกัดของมันเอง เพราะตัวรันไม่มีข้อมูลว่าผู้ให้โมเดลส่งอะไรมาจริง

นี่คือทางตันที่งานวิจัยเองก็ยอมรับ คือเมื่อไม่มีกลไกยืนยันที่มาจากต้นทาง ฝั่งไหนก็ป้องกันได้แค่ระดับหนึ่ง

มุมมองจากคนที่ตั้งค่าโมเดลเองทุกวัน

ผมตั้งค่าเส้นทางไปยังโมเดลหลายค่ายในงานประจำ และบทความนี้ทำให้ผมกลับไปตรวจการตั้งค่าของตัวเอง

เรื่องที่ผมคิดว่าคนทำระบบควรตระหนักคือ ต้นทุนในการเปลี่ยนตัวกลางมันต่ำมาก แก้ที่อยู่ปลายทางบรรทัดเดียวกับเปลี่ยนคีย์ ก็จบ [1]

ความสะดวกนี้เองที่ทำให้คนไม่ค่อยตรวจว่าตัวกลางอ่านอะไรได้บ้าง เพราะขั้นตอนมันง่ายจนดูเหมือนไม่มีอะไรต้องคิด

อีกเรื่องที่ผมเห็นว่าน่าสนใจคือคำถามที่ตัวกลางเองตั้งไว้ในวีท ว่าด่านของเขาไม่ได้ถามว่าเนื้อหานี้ปลอดภัยไหม แต่ถามว่าการกระทำนี้ควรได้รันหรือเปล่า [4]

กรอบคำถามนี้ถูกต้องและเป็นประโยชน์ เพราะมันย้ายจุดสนใจจากเนื้อหาไปที่การกระทำ ซึ่งเป็นจุดที่ความเสียหายเกิดขึ้นจริง

แต่การที่ด่านอยู่ในตัวกลางก็ยังไม่ตอบคำถามของคอมเมนต์นั้นได้ และผมคิดว่านี่เป็นข้อจำกัดเชิงโครงสร้างที่ต้องเข้าใจ ไม่ใช่ข้อบกพร่องของใครคนใดคนหนึ่ง

สิ่งที่ผมทำกับระบบตัวเองคือเปิดบันทึกคำขอและคำตอบไว้ เพราะอย่างน้อยเมื่อมีเหตุการณ์เกิดขึ้น ผมจะรู้ว่าอะไรผ่านไปบ้าง แม้มันจะช่วยตอนเกิดเหตุไม่ได้

ข้อควรระวังก่อนนำไปใช้

หนึ่ง ตัวเลขทั้งหมดในงานวิจัยมาจากการทดลองที่นักวิจัยควบคุมบัญชีเองและเลือกตลาดที่ศึกษาจำเพาะ การนำไปเหมารวมกับตัวกลางทุกตัวจึงไม่ถูกต้อง ตัวอย่าง 428 ตัวเป็นภาพของตลาดหนึ่ง ไม่ใช่ค่าเฉลี่ยของทั้งอุตสาหกรรม [1]

สอง การตรวจว่าตัวกลางอ่านอะไรได้บ้างทำได้ยากจากภายนอก เพราะสัญญาณที่ผู้ใช้เห็นไม่ได้บอกว่ามีการแก้อะไรระหว่างทาง การเลือกตัวกลางจึงเป็นการตัดสินใจเรื่องความเชื่อถือ ไม่ใช่เรื่องเทคนิคที่ตรวจสอบได้ [1]

สาม ด่านป้องกันที่มีผลดีที่สุดในงานวิจัยเป็นแบบปฏิเสธไว้ก่อน ซึ่งแลกมาด้วยคำสั่งที่ถูกบล็อกผิด ทั้งงานติดตั้งที่ชอบใช้ และคำสั่งจัดการระบบที่ถูกต้อง ต้องชั่งน้ำหนักกับความคล่องตัวของทีมก่อนเปิดใช้ [1]

สี่ งานวิจัยนี้ตรวจตัวกลางที่ให้บริการสาธารณะเป็นหลัก ตัวกลางที่องค์กรสร้างเองหรือโฮสต์บนคลาวด์ส่วนตัวยังไม่ได้อยู่ในขอบเขตศึกษา จึงไม่ควรสรุปว่าปลอดภัยกว่า และไม่ควรสรุปว่าอันตรายกว่าเช่นกัน [1]

สรุป

เรื่องนี้ไม่ได้จบที่คำถามว่าตัวกลางเจ้าไหนน่าเชื่อถือ

มันจบที่คำถามว่า ระบบนิเวศทั้งหมดยังไม่มีกลไกให้ฝั่งลูกค้ายืนยันได้ว่าคำสั่งที่กำลังจะรันมาจากโมเดลจริง

ตราบใดที่ยังไม่มี ต่อให้วางด่านไว้ตรงไหน ก็ยังเป็นการเชื่อใจใครสักคนอยู่ดี

สำหรับคนที่รัน agent ในงานจริง คำถามที่ผมคิดว่าควรถามก่อนคือ ถ้าคำสั่งที่ AI ขอทำถูกแก้ไปหนึ่งคำ เราจะรู้ตัวไหม

ถ้าคำตอบคือไม่รู้ นั่นคือจุดที่ควรเริ่มปรับ

แหล่งอ้างอิง

[1] Liu, H., Shou, C., Wen, H., Chen, Y., Fang, R. J., Feng, Y., "Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain", arXiv:2604.08407 (9 เม.ย. 2026), https://arxiv.org/abs/2604.08407

[2] Markovic, S., "Command integrity breaks in the LLM routing layer", Help Net Security (16 เม.ย. 2026), https://www.helpnetsecurity.com/2026/04/16/llm-router-security-risk-agent-commands/

[3] OrcaRouter, "The control stack: keys, guardrails, firewall, audit" (เข้าถึง 12 ก.ย. 2026), https://docs.orcarouter.ai/security/concepts/control-stack

[4] OrcaRouter, โพสต์บน X เรื่อง malicious LLM router (11 ก.ย. 2026), https://x.com/OrcaRouter/status/2098314095401521391

[5] Shou, C., โพสต์บน X เรื่อง 26 LLM routers (เม.ย. 2026), https://x.com/shoucccc/status/2042423713019412941