Luisa Crawford
30 ม.ค. 2569 16:35
ทีม AI Red Team ของ NVIDIA เผยแพร่มาตรการควบคุมความปลอดภัยที่จำเป็นสำหรับตัวแทน AI ที่เขียนโค้ด เพื่อรับมือกับการโจมตีแบบ prompt injection และช่องโหว่การหลุดจาก sandbox
ทีม AI Red Team ของ NVIDIA ได้เปิดตัวกรอบความปลอดภัยที่ครอบคลุมเมื่อวันที่ 30 มกราคม โดยมุ่งเป้าไปที่จุดอับในขั้นตอนการทำงานของนักพัฒนาที่กำลังเติบโต: ตัวแทน AI ที่เขียนโค้ดทำงานด้วยสิทธิ์ผู้ใช้เต็มรูปแบบ คำแนะนำนี้มาพร้อมกับตลาด sandbox ความปลอดภัยเครือข่ายที่พองตัวไปสู่ 368 พันล้านดอลลาร์ และช่องโหว่ล่าสุดอย่าง CVE-2025-4609 เตือนทุกคนว่าการหลุดจาก sandbox ยังคงเป็นภัยคุกคามที่แท้จริง
ปัญหาหลัก? ผู้ช่วย AI ในการเขียนโค้ดอย่าง Cursor, Claude และ GitHub Copilot ดำเนินการคำสั่งด้วยสิทธิ์การเข้าถึงใดๆ ที่นักพัฒนามี ผู้โจมตีที่วางพิษใน repository แทรกคำสั่งที่เป็นอันตรายลงในไฟล์ .cursorrules หรือทำให้การตอบสนองของเซิร์ฟเวอร์ MCP ถูกบุกรุกสามารถยึดการกระทำของตัวแทนได้ทั้งหมด
สามมาตรการควบคุมที่ไม่อาจเจรจาได้
กรอบของ NVIDIA ระบุมาตรการควบคุมสามข้อที่ทีม Red Team ถือว่าเป็นข้อบังคับ—ไม่ใช่ข้อเสนอแนะ แต่เป็นข้อกำหนด:
การล็อกการเชื่อมต่อขาออกของเครือข่าย บล็อกการเชื่อมต่อขาออกทั้งหมดยกเว้นปลายทางที่ได้รับอนุมัติอย่างชัดเจน วิธีนี้ป้องกันการขโมยข้อมูลและ reverse shells ทีมแนะนำการบังคับใช้ HTTP proxy, DNS resolvers ที่กำหนด และรายการปฏิเสธระดับองค์กรที่นักพัฒนาแต่ละคนไม่สามารถแทนที่ได้
การเขียนไฟล์เฉพาะใน workspace ตัวแทนไม่ควรแตะต้องสิ่งใดนอกไดเรกทอรีโปรเจ็กต์ที่ใช้งานอยู่ การเขียนไปยัง ~/.zshrc หรือ ~/.gitconfig เปิดประตูให้กับกลไกความยืนยงและการหลุดจาก sandbox NVIDIA ต้องการการบังคับใช้ระดับ OS ที่นี่ ไม่ใช่คำสัญญาระดับแอปพลิเคชัน
การปกป้องไฟล์ config สิ่งนี้น่าสนใจ—แม้แต่ไฟล์ภายใน workspace ก็ต้องการการปกป้องหากเป็นไฟล์กำหนดค่าของตัวแทน Hooks, คำจำกัดความเซิร์ฟเวอร์ MCP และสคริปต์ทักษะมักดำเนินการนอกบริบท sandbox คำแนะนำตรงไปตรงมา: ห้ามตัวแทนแก้ไขไฟล์เหล่านี้โดยเด็ดขาด แก้ไขด้วยตนเองโดยผู้ใช้เท่านั้น
เหตุใดมาตรการควบคุมระดับแอปพลิเคชันจึงล้มเหลว
ทีม Red Team ทำให้มีเหตุผลน่าเชื่อสำหรับการบังคับใช้ระดับ OS มากกว่าข้อจำกัดระดับแอป เมื่อตัวแทนสร้าง subprocess แอปพลิเคชันหลักจะสูญเสียการมองเห็น ผู้โจมตีมักจะเชื่อมโยงเครื่องมือที่ได้รับอนุมัติเพื่อเข้าถึงเครื่องมือที่ถูกบล็อก—เรียกคำสั่งที่ถูกจำกัดผ่าน wrapper ที่ปลอดภัยกว่า
macOS Seatbelt, Windows AppContainer และ Linux Bubblewrap สามารถบังคับใช้ข้อจำกัดใต้ระดับแอปพลิเคชัน จับเส้นทางการดำเนินการทางอ้อมที่รายการอนุญาตพลาด
คำแนะนำที่ยากกว่า
นอกเหนือจากทั้งสามข้อบังคับ NVIDIA ร่างมาตรการควบคุมสำหรับองค์กรที่มีความทนทานต่อความเสี่ยงต่ำกว่า:
การสร้างเสมือนเต็มรูปแบบ—VMs, Kata containers หรือ unikernels—แยก kernel ของ sandbox จาก host โซลูชัน shared-kernel อย่าง Docker ทำให้ช่องโหว่ kernel สามารถถูกใช้ประโยชน์ได้ ภาระโอเวอร์เฮดเป็นจริงแต่มักถูกบดบังด้วยความหน่วงในการอนุมาน LLM อยู่แล้ว
การแทรกข้อมูลลับแทนการสืบทอด เครื่องของนักพัฒนาเต็มไปด้วย API keys, ข้อมูลรับรอง SSH และโทเค็น AWS การเริ่มต้น sandbox ด้วยชุดข้อมูลรับรองที่ว่างเปล่าและแทรกเฉพาะสิ่งที่จำเป็นสำหรับงานปัจจุบันจำกัดรัศมีการระเบิด
การจัดการวงจรชีวิตป้องกันการสะสม artifact Sandbox ที่ทำงานนานรวบรวม dependencies, ข้อมูลรับรองที่แคชไว้ และโค้ดที่เป็นกรรมสิทธิ์ที่ผู้โจมตีสามารถนำไปใช้ใหม่ได้ สภาพแวดล้อมชั่วคราวหรือการทำลายตามกำหนดเวลาจัดการกับสิ่งนี้
ความหมายของสิ่งนี้สำหรับทีมพัฒนา
จังหวะเวลามีความสำคัญ ตัวแทน AI ในการเขียนโค้ดได้เปลี่ยนจากความแปลกใหม่เป็นความจำเป็นสำหรับหลายทีม แต่แนวปฏิบัติด้านความปลอดภัยยังไม่ทัน การอนุมัติด้วยตนเองของทุกการกระทำสร้างความเคยชิน—นักพัฒนาประทับตราคำขอโดยไม่อ่าน
แนวทางแบบแบ่งชั้นของ NVIDIA เสนอเส้นทางกลาง: รายการปฏิเสธขององค์กรที่ไม่สามารถแทนที่ได้, การอ่าน-เขียน workspace โดยไม่มีความขัดแย้ง, รายการอนุญาตเฉพาะสำหรับการเข้าถึงภายนอกที่ถูกต้อง และการปฏิเสธตามค่าเริ่มต้นพร้อมการอนุมัติแบบรายกรณีสำหรับทุกสิ่งอื่น
กรอบหลีกเลี่ยงโดยชัดเจนการจัดการกับความถูกต้องของผลลัพธ์หรือการจัดการที่เป็นปฏิปักษ์ของข้อเสนอแนะ AI—สิ่งเหล่านั้นยังคงเป็นความรับผิดชอบของนักพัฒนา แต่สำหรับความเสี่ยงในการดำเนินการที่มาจากการให้ตัวแทน AI เข้าถึงระบบจริง? นี่คือคำแนะนำสาธารณะที่ละเอียดที่สุดที่มีจากทีมความปลอดภัยของผู้ขายรายใหญ่
แหล่งที่มาของภาพ: Shutterstock
แหล่งที่มา: https://blockchain.news/news/nvidia-ai-agent-security-framework-sandbox-controls
