Google Cloud ได้เปิดตัวบริการ GKE Agent Sandbox แบบ managed ในขณะที่โปรเจกต์โอเพนซอร์ส kubernetes-sigs/agent-sandbox ก็นำความสามารถแบบเดียวกันนี้มาสู่ Kubernetes cluster ใดๆ ก็ตาม ทั้งคู่ช่วยให้นักพัฒนาสามารถมี Linux container แบบใช้แล้วทิ้งสำหรับ AI agent โดยไม่ส่งผลกระทบต่อโครงสร้างพื้นฐานส่วนที่เหลือ

ทำไมโค้ดที่สร้างโดย AI ถึงต้องการพื้นที่ทดลอง (playpen)

AI agent สมัยใหม่ไม่ได้ทำแค่ตอบคำถามเท่านั้น แต่ยังเขียนสคริปต์, ท่องเว็บ, รันคำสั่ง shell และแม้กระทั่งเปิดใช้งาน web services พลังเหล่านี้สร้างช่องโหว่ด้านความปลอดภัย เนื่องจากโค้ดที่พวกมันสร้างออกมาอาจมีบั๊ก, เป็นอันตราย หรือทำงานที่รุนแรงเกินไป หาก agent รันคำสั่ง rm -rf / หรือเชื่อมต่อกับฐานข้อมูลภายในโดยไม่ได้รับอนุญาต ก็อาจทำให้ระบบทั้งหมดตกอยู่ในอันตรายได้

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

สองวิธีในการใช้งาน sandbox

  • GKE Agent Sandbox – บริการแบบ fully managed สำหรับลูกค้า Google Cloud
  • kubernetes-sigs/agent-sandbox – โปรเจกต์โอเพนซอร์สสำหรับ Kubernetes cluster ใดๆ ก็ตาม

ทั้งคู่ใช้สถาปัตยกรรมหลักแบบเดียวกัน ซึ่งสร้างขึ้นบน Kubernetes primitives มาตรฐาน

โครงสร้างของระบบ

Component บทบาท
Sandbox Container ที่ถูกแยกส่วนเพื่อรันโค้ดของ agent โดยจะมีชื่อที่คงที่และมี persistent storage หากจำเป็น
SandboxTemplate พิมพ์เขียวที่กำหนด container image และนโยบายความปลอดภัย เปรียบเสมือนสูตรสำหรับสร้าง sandbox ใหม่
SandboxClaim คำขอที่ส่งโดย agent (หรือ controller ของมัน) เพื่อสร้าง sandbox จาก template ที่ระบุ
SandboxWarmPool กลุ่มของ sandbox ที่ถูกสร้างไว้ล่วงหน้าพร้อมสำหรับการใช้งานทันที การรักษา container ให้ "warm" ช่วยลดความหน่วง (latency) จากการดึง image และการเริ่ม pod ใหม่ทุกครั้ง

เมื่อ agent ต้องการสภาพแวดล้อมในการทำงาน มันจะส่ง SandboxClaim ออกไป จากนั้น controller จะตรวจสอบใน warm pool เพื่อเลือก sandbox ที่ว่างอยู่และผูกเข้ากับ claim นั้น หาก pool ว่างเปล่า ระบบจะสร้าง sandbox ใหม่จาก template แต่หากมีอยู่แล้ว การส่งมอบจะเกิดขึ้นภายในเวลาเพียงไม่กี่มิลลิวินาที

ตัวเลือกการปรับแต่งความปลอดภัย (Security knobs)

  • Default-deny networking – โดยค่าเริ่มต้น sandbox จะไม่สามารถเข้าถึงเครือข่ายภายในได้ คุณต้องเพิ่มกฎที่ชัดเจนเพื่ออนุญาตการเชื่อมต่อขาออก (outbound) หรือขาเข้า (inbound) เพื่อป้องกันการเปิดเผยบริการภายในโดยไม่ตั้งใจ
  • Isolation levels – เลือก container runtime ที่เหมาะสมกับระดับความเสี่ยงที่คุณยอมรับได้:
    • Standard containers เพื่อความรวดเร็ว
    • gVisor เพื่อเพิ่มเลเยอร์การแยกส่วนในระดับ user-space
    • Kata Containers สำหรับการแยกส่วนที่ใช้ฮาร์ดแวร์ช่วย (hardware-assisted isolation) ซึ่งทำงานเหมือนกับ lightweight VM
  • SDKs – ไลบรารีสำหรับ Python และ Go ช่วยให้นักพัฒนาสามารถสร้าง, claim และทำลาย sandbox ได้ผ่านการเขียนโปรแกรม ซึ่งสอดคล้องกับเวิร์กโฟลว์ของ AI-driven pipelines

ใครได้ประโยชน์ และใครที่อาจจะคัดค้าน

บทสรุป

การมอบ Linux box แบบใช้แล้วทิ้งให้กับ AI agent ช่วยขจัดความไม่แน่นอนที่ใหญ่ที่สุดของการทำ automation ด้วย AI นั่นคือความเสี่ยงที่โค้ดซึ่งถูกสร้างขึ้นจะทำลาย host บริการ GKE Agent Sandbox แบบ managed ของ Google Cloud และ kubernetes-sigs/agent-sandbox ที่ดูแลโดยชุมชน ช่วยให้การแยกส่วน (isolation) นี้ใช้งานได้จริงทั้งในสภาพแวดล้อมแบบ cloud-native และ on-prem องค์กรที่ต้องการสร้างสมดุลระหว่างความคล่องตัวและความปลอดภัย จึงมีเครื่องมือที่เป็น Kubernetes-native และจับต้องได้ เพื่อควบคุมโค้ดที่สร้างโดย AI ให้อยู่ในพื้นที่ทดลอง (sandboxed playpen) ที่ปลอดภัย