ความปลอดภัยของเอเจนต์ DeepSeek V4 Pro ขึ้นอยู่กับ Harness ไม่ใช่แค่โมเดล

องค์กรที่นำเอเจนต์ DeepSeek V4 Pro ไปใช้งานไม่ควรประเมินโมเดลเพียงลำพัง แต่ควรประเมินการตั้งค่าครบชุด โมเดล–harness–งาน–สภาพแวดล้อม

การที่โมเดลใช้งานได้ผ่าน Web แอปมือถือ API, OpenAI Responses API หรือการเชื่อมต่อกับ Codex อาจยืนยันได้ว่าอินเทอร์เฟซสามารถสื่อสารกับโมเดลได้ แต่ไม่ได้หมายความว่าพรอมป์ เครื่องมือ สิทธิ์ หน่วยความจำ ระบบลองใหม่ หรือผลกระทบต่อระบบภายนอกจะทำงานเหมือนกันทุกช่องทาง

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

ทำไม Harness จึงเปลี่ยนความเสี่ยงของเอเจนต์

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

องค์ประกอบที่อาจแตกต่างกันอย่างมีนัยสำคัญ ได้แก่

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

ดังนั้น DeepSeek V4 Pro backend เดียวกันอาจมีโปรไฟล์ความเสี่ยงต่างกันเมื่อทำงานผ่าน harness หรือสภาพแวดล้อมที่ต่างกัน การรองรับ schema ของ API เดียวกันเป็นเพียงคุณสมบัติด้านการผสานระบบ ไม่ใช่ใบรับรองความปลอดภัย

ผลการทดสอบ AgentS4D บอกอะไร—and ไม่ได้บอกอะไร

AgentS4D ประเมินการตั้งค่ารันไทม์แบบครบชุด แทนที่จะดูเฉพาะคำตอบของโมเดล การทดสอบใช้กรณีที่ฝังความเสี่ยง 328 กรณี ครอบคลุม harness 4 แบบและโมเดล backend 5 แบบ รวมเป็นการรันใน sandbox 6,560 ครั้ง ผลการศึกษาระบุว่ามี 4,461 ครั้ง หรือ 68.0% ที่ไม่ปลอดภัย และ 4,344 ครั้ง หรือ 66.22% ที่ทั้งไม่ปลอดภัยและถูกตัดสินว่างานเสร็จสมบูรณ์ 13

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

ตัวเลขดังกล่าวไม่ควรถูกนำเสนอเป็นอัตราเหตุการณ์ความปลอดภัยของ DeepSeek V4 Pro ในระบบจริง เพราะการทดสอบใช้กรณีที่จงใจใส่ความเสี่ยงใน sandbox และรวมผลจากหลายคู่โมเดล–harness ขณะที่ประเภทงานจริง มาตรการควบคุม การได้รับเนื้อหาจากผู้โจมตี ทรัพย์สินที่เข้าถึงได้ และนิยามของความเสียหายย่อมแตกต่างกัน ผลการทดสอบจึงเป็นหลักฐานว่าต้องวัดความปลอดภัยของรันไทม์โดยตรง ไม่ใช่การพยากรณ์ว่าเอเจนต์ทุกการติดตั้งจะเกิดเหตุในอัตราเดียวกัน 135

จำกัดความเสียหายสูงสุดจากการกระทำของเอเจนต์

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

ใช้ตัวตนเฉพาะและสิทธิ์น้อยที่สุด

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

จำกัดระบบไฟล์และเครือข่าย

• เมานต์เฉพาะโฟลเดอร์ workspace ที่จัดไว้โดยเฉพาะ
• ทำให้เส้นทางอื่นเข้าถึงไม่ได้จริง ไม่ใช่เพียงซ่อนไว้
• กำหนด allowlist ของปลายทางเครือข่าย วิธีการเชื่อมต่อ พอร์ต และปริมาณข้อมูลขาออกเมื่อจำเป็น
• แยกสิทธิ์อ่าน ร่างงาน เขียนใน staging และเขียนใน production
• เก็บความลับไว้ในตัวกลางจัดการข้อมูลรับรองหรือระบบโทเคนแบบอายุสั้น
• ห้ามใส่ข้อมูลรับรองอายุยาวไว้ในพรอมป์ ไฟล์ workspace ตัวแปรสภาพแวดล้อม หรือผลลัพธ์จากเครื่องมือ

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

ตรวจสอบห่วงโซ่การทำงานทั้งหมด

เครื่องมือที่พัฒนาโดยผู้ให้บริการเองเป็นเพียงส่วนหนึ่งของพื้นผิวการโจมตีเท่านั้น ยังต้องตรวจสอบ child process คำสั่ง shell โค้ดที่สร้างขึ้น การติดตั้งแพ็กเกจ เซิร์ฟเวอร์เครื่องมือระยะไกล ปลั๊กอิน และโค้ดของ skill ต่าง ๆ เพราะทั้งหมดอาจสร้างผลกระทบต่อระบบได้

นโยบายเดียวกันต้องครอบคลุมทุกเส้นทาง โดยเฉพาะการป้องกันไม่ให้ shell หรือโค้ดที่เอเจนต์สร้างขึ้นใช้เป็นช่องทางเลี่ยงการควบคุมระบบไฟล์ เครือข่าย การอนุญาต การบันทึกเหตุการณ์ หรือขั้นตอนอนุมัติ

ทำให้เครื่องมือบังคับใช้นโยบายได้โดยไม่พึ่งโมเดล

คำขอเรียกใช้เครื่องมือที่โมเดลสร้างขึ้นควรถูกถือเป็นคำขอที่ไม่น่าไว้วางใจ เซิร์ฟเวอร์เครื่องมือ—not โมเดล—ต้องเป็นผู้บังคับใช้กฎด้านสิทธิ์และความปลอดภัย

ควรใช้ schema ที่แคบและควบคุมได้ เช่น

• จำกัดค่า enum และความยาวของข้อมูล
• ทำให้เส้นทางเป็นรูปแบบมาตรฐานและใช้ตัวระบุทรัพยากรที่ชัดเจน
• กำหนด allowlist ของปลายทาง
• จำกัดจำนวนหน้าและขนาดผลลัพธ์
• ตรวจสอบอาร์กิวเมนต์นอกโมเดล
• ตรวจสอบสิทธิ์ที่ฝั่งเซิร์ฟเวอร์สำหรับผู้เรียกใช้ ผู้เช่า เป้าหมาย และปฏิบัติการนั้นโดยเฉพาะ

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

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

มาตรการเหล่านี้สำคัญเพราะ JSON ที่ดูถูกต้องอาจยังระบุเป้าหมายที่ไม่มีสิทธิ์เข้าถึง เส้นทางอันตราย ขอบเขตที่กว้างเกินไป หรือปฏิบัติการที่ควรต้องผ่านการตรวจสอบโดยมนุษย์

กำหนดพฤติกรรมของสถานะและหน่วยความจำก่อนเปิดใช้งาน

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

อย่างน้อยควรกำหนดเรื่องต่อไปนี้

• การแยกข้อมูล: แยกสถานะตามผู้ใช้ ผู้เช่า งาน และสภาพแวดล้อม ห้ามแชร์ข้ามเซสชันโดยปริยาย
• การเก็บรักษา: ระบุอายุข้อมูล การเข้ารหัส การควบคุมการเข้าถึง และกฎการลบให้ชัดเจน
• การรีเซ็ต: มีวิธีที่ระบุไว้ชัดเจนสำหรับล้างบริบท หน่วยความจำ สถานะ workspace ข้อมูลรับรอง และแคชระหว่างการรันแต่ละครั้ง
• การลองใหม่และหมดเวลา: จำกัดจำนวนครั้งและงบเวลาหรือทรัพยากร การลองใหม่ต้องรักษา idempotency และห้ามเพิ่มสิทธิ์โดยไม่แจ้งให้ทราบ
• การทำงานพร้อมกัน: กำหนดการล็อกและวิธีจัดการความขัดแย้งของไฟล์ร่วม ขั้นตอนอนุมัติ และปฏิบัติการภายนอก

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

ถือว่าทุกแหล่งนำความเสี่ยงเป็นอินพุตที่ไม่น่าไว้วางใจ

การโจมตีแบบ prompt injection ไม่จำเป็นต้องมาจากข้อความโดยตรงของผู้ใช้ แต่อาจซ่อนอยู่ใน

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

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

เช็กลิสต์ก่อนปล่อยใช้งานที่ต้องผูกกับ Harness โดยเฉพาะ

ก่อนอนุมัติการดีพลอย ควรตรึงและบันทึกการตั้งค่าที่แน่นอนดังนี้

1. โมเดลและเส้นทางการเรียกใช้: ตัวระบุและเวอร์ชันโมเดล เส้นทางผ่านผู้ให้บริการ ค่าการอนุมานหรือระดับ effort และ adapter ที่ใช้เพื่อความเข้ากันได้
2. พฤติกรรมของ harness: เวอร์ชัน harness, system prompt, การจัดการเซสชัน กฎการลองใหม่และหมดเวลา นโยบาย subprocess และระบบหน่วยความจำ
3. เครื่องมือและนโยบาย: คำจำกัดความและเวอร์ชันของเครื่องมือ เวอร์ชันนโยบาย เกณฑ์การอนุมัติ ตรรกะการอนุญาต และขอบเขตความน่าเชื่อถือของเซิร์ฟเวอร์เครื่องมือ
4. สิทธิ์: ตัวตน ขอบเขตสิทธิ์ รากระบบไฟล์ ปลายทางเครือข่าย แหล่งข้อมูลรับรอง และเส้นทางที่เขียนลง production ได้
5. ความหมายของสถานะ: การแยกข้อมูล การเก็บรักษา การรีเซ็ต พฤติกรรมแคช การทำงานพร้อมกัน และขอบเขตระหว่างเซสชัน
6. การทดสอบเชิงรุก: prompt injection ผ่านแหล่งความเสี่ยงทุกประเภท การหลอกให้เอเจนต์ใช้สิทธิ์แทนผู้อื่น การเปิดเผยข้อมูลรับรอง path traversal, SSRF หรือการใช้ egress ในทางที่ผิด คำตอบจากเครื่องมือที่เป็นอันตราย การทำรายการซ้ำจากการลองใหม่ การปนเปื้อนหน่วยความจำ และการเลี่ยงขั้นตอนอนุมัติ
7. หลักฐาน: พรอมป์และเวอร์ชันนโยบาย การเรียกใช้และผลลัพธ์ของเครื่องมือ การอนุมัติ การตัดสินใจของนโยบาย ความแตกต่างของไฟล์ใน workspace คำขอขาออก ตัวตนที่ใช้ ผลงานสุดท้าย ผลการทำงานเสร็จ และผลด้านความปลอดภัยภายใต้ run ID ที่คงที่

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

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

เป้าหมายที่ได้รับอนุมัติควรเป็นการตั้งค่าที่ตรึงไว้ ไม่ใช่ป้ายกำกับกว้าง ๆ อย่าง “DeepSeek V4 Pro agent” องค์กรควรรันชุดทดสอบเฉพาะการตั้งค่าใหม่ทุกครั้งที่มีการเปลี่ยนแปลงสำคัญ เช่น

• โมเดลหรือเส้นทางผ่านผู้ให้บริการ
• ค่าการอนุมานหรือระดับ effort
• system prompt หรือ adapter
• ตรรกะของ harness หรือเซสชัน
• เครื่องมือหรือเซิร์ฟเวอร์เครื่องมือระยะไกล
• นโยบายสิทธิ์และการอนุมัติ
• เส้นทางการจัดการข้อมูลรับรอง
• พฤติกรรมของหน่วยความจำ การลองใหม่ การหมดเวลา หรือการทำงานพร้อมกัน
• ขอบเขตเครือข่ายหรือระบบไฟล์

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