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

Claude Code เคยใช้วิธีนี้เป็นหลักเพื่อป้องกันความเสียหาย โดยให้อ่านไฟล์ได้เลย แต่ถ้าจะเขียนไฟล์ รันคำสั่ง หรือต่อออกเน็ต ต้องถามคนก่อนทุกครั้ง ผู้ใช้เริ่มล้าจากการกดอนุมัติภายในไม่กี่สัปดาห์หลังเปิดตัว และข้อมูลการใช้งานที่ Anthropic เก็บจากผู้ใช้จริงก็ชี้ว่าคนกดผ่านราว 93% ของคำถามที่เด้งขึ้นมา ทีมวิศวกรรมของบริษัทเพิ่งเปิดบันทึกตลอดสองปีที่ผ่านมาว่าใช้วิธีไหนป้องกันไม่ให้ agent สร้างความเสียหายบ้าง วิธีไหนยังใช้ได้ และวิธีไหนใช้ไม่ได้แล้ว ข้อสรุปสำคัญของเรื่องนี้มีประโยคเดียว คือเลิกไล่ดูว่า agent กำลังทำอะไร แล้วหันมากำหนดตั้งแต่ต้นว่ามันทำอะไรได้บ้าง

สามตัวเลขจากการใช้งานจริง กับชุดเดียวที่ลดปัญหาลงได้

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

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

ตัวเลขชุดที่สองมาจากโหมด auto ของ Claude Code ซึ่งใช้โมเดลตัวเล็กช่วยคัดว่าคำสั่งไหนอนุมัติได้โดยอัตโนมัติ ตัวคัดกรองจับพฤติกรรมเสี่ยงที่ agent ทำเกินหน้าที่ได้ราว 83% ก่อนคำสั่งจะทำงาน และบล็อกคำสั่งปกติผิดๆ ราว 0.4% แม้ตัวเลขจะดูดี แต่ก็หมายความว่ายังมีพฤติกรรมเสี่ยงราว 17% ที่หลุดผ่านไปได้ ต้นทางจึงระบุไว้ตรงๆ ว่าโหมดนี้เป็นเพียงชั้นป้องกันที่ทำงานอยู่ภายใน sandbox ไม่ได้มีไว้แทน sandbox

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

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

ปัญหาของ agent มาจากสามทาง และแต่ละทางกันคนละแบบ

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

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

ยิ่งโมเดลมีความสามารถมากขึ้น ก็ยิ่งสร้างความเสียหายได้มากขึ้นตามไปด้วย เมื่อเดือนเมษายน 2026 มีการประเมินว่าโมเดลชื่อ Claude Mythos Preview อาจก่อความเสียหายในทางทฤษฎีเป็นวงกว้างเกินกว่าจะเปิดตัว สุดท้ายจึงไม่ได้ปล่อยออกมา

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

ชั้นป้องกันสามชั้น และเหตุผลที่ต้องซ้อนกัน

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

ชั้นที่สองคือตัวโมเดล ซึ่งรวมทั้งคำสั่งระบบ ตัวคัดกรอง และการฝึกโมเดล ชั้นนี้ทำงานได้ดีกว่าที่หลายคนคิด ในชุดทดสอบ Agent Red Teaming ของ Gray Swan ที่วัดว่าโมเดลหลงทำตามคำสั่งแฝงง่ายแค่ไหน Claude Opus 4.7 ถูกเจาะสำเร็จราว 0.1% เมื่อลองครั้งเดียว และเพิ่มเป็นราว 5-6% เมื่อคนโจมตีปรับวิธีแล้วลองซ้ำ 100 ครั้ง แม้อัตราจะต่ำมาก แต่ความเสี่ยงก็ยังไม่หมดไป เพราะชั้นนี้ทำงานด้วยความน่าจะเป็น จึงกำหนดได้เพียงว่า agent มีแนวโน้มจะทำอะไร ไม่ได้กำหนดว่ามันทำอะไรได้ ต้นทางจึงเขียนไว้ชัดว่าการป้องกันที่ชั้นโมเดลไม่มีวันได้ร้อยเปอร์เซ็นต์ และนี่คือเหตุผลที่ใช้ชั้นนี้เพียงลำพังไม่ได้

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

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

ชั้นที่อ่อนที่สุดมักเป็นชั้นที่สร้างขึ้นมาเอง

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

สามเรื่องที่พังจริง และแต่ละเรื่องสอนอะไร

โค้ดที่ทำงานตั้งแต่ก่อนคนกดว่าเชื่อโฟลเดอร์นี้

ระหว่างกลางปี 2025 ถึงมกราคม 2026 คนนอกแจ้งช่องโหว่เข้ามา 3 รายการ ทั้งสามรายการมีปัญหาด้านโครงสร้างเหมือนกัน คือมีโค้ดทำงานก่อนที่ผู้ใช้จะกดยินยอม

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

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

คำสั่งอันตรายที่ผู้ใช้เอามาวางเอง

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

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

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

ข้อมูลหลุดออกไปทางโดเมนที่อนุญาตไว้แล้ว

กรณีนี้คนนอกเป็นผู้แจ้งเข้ามาเช่นกัน Claude Cowork มีรายชื่อปลายทางที่อนุญาตให้ส่งข้อมูลออกไปได้ ในรายชื่อนั้นมีโดเมนของ Anthropic เอง ซึ่งจำเป็นต้องเปิดไว้เพื่อให้ผลิตภัณฑ์ทำงานได้

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

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

ทางแก้คือวางตัวกลางตรวจคำขอไว้ในพื้นที่ที่ล้อม แล้วปล่อยผ่านเฉพาะคำขอที่มีโทเคนประจำรอบของพื้นที่นั้นจริงๆ กุญแจที่คนร้ายฝังมากับไฟล์จึงใช้ไม่ได้ พร้อมกันนั้น ทีมยังปิดค่าที่สั่งให้เซิร์ฟเวอร์ไปดึงข้อมูลมาให้อีกทอด ตัวกลางนี้ต้องอยู่ภายในพื้นที่ที่ล้อม ไม่ใช่อยู่บนเซิร์ฟเวอร์ เพราะมีแต่ระบบข้างในเท่านั้นที่รู้ว่าคำขอมาจากไหนจริงๆ เมื่อมองจากฝั่งเซิร์ฟเวอร์ คำขอจากผลิตภัณฑ์กับคำขอจากโปรแกรมอื่นมีลักษณะเหมือนกันทั้งหมด

ผลิตภัณฑ์คนละแบบ ต้องล้อมคนละอย่าง

ในช่วงสองปีที่ผ่านมา Anthropic เปิดตัวผลิตภัณฑ์ที่ให้ AI ทำงานเองสามตัว และกำหนดขอบเขตให้แต่ละตัวต่างกัน เพราะทำงานในสภาพแวดล้อมและมีกลุ่มผู้ใช้ไม่เหมือนกัน

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

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

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

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

Cowork กำหนดสิทธิ์เข้าถึงโฟลเดอร์ของ agent ไว้สามระดับ คืออ่านอย่างเดียว อ่านและเขียนได้ และอ่านเขียนได้แต่ลบไม่ได้ องค์กรที่ต้องควบคุมเข้มงวดกว่านั้นยังกำหนดล่วงหน้าได้ว่าอนุญาตให้ผู้ใช้เลือกโฟลเดอร์ใดบ้าง

ตั้งขอบเขตอย่างไรให้ใช้งานได้จริง

สิ่งที่เอาไปทำได้ตั้งแต่งานถัดไปมีไม่กี่ข้อ

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

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

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

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

คำถามที่ยังไม่มีคำตอบ

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

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

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

---

ที่มา: บทความ How we contain Claude across products จากบล็อกวิศวกรรมของ Anthropic