โดย Insightist™ | เผยแพร่: 27 ต.ค. 2569 | อ้างอิง: Google Cloud Blog
สรุปสาระสำคัญ
- Google เปิดตัว Agent Compute Engine บริการใหม่บน Google Cloud ให้ AI agent ทุกตัวมี microVM ของตัวเอง
- sandbox ของ agent ไม่เก็บ credentials ใดๆ ทั้งใน memory และบนดิสก์
- Google แยกตัวตนที่เกี่ยวข้องกับ agent ออกเป็น 4 แบบ
- agent ที่ว่างอยู่จะถูกพักไว้จนแทบไม่กินทรัพยากร แล้วปลุกกลับมาเมื่อมีงานใหม่
- เป้าหมายคือเปิด preview ในอีกไม่กี่เดือนข้างหน้า ยังไม่มีราคาหรือวันเปิดที่ชัดเจน
ถ้า AI ที่ช่วยตอบอีเมลของบริษัทคุณเปิดเจอข้อความซ่อนที่สั่งให้ส่งรหัสลับออกไป มันจะมีรหัสอะไรอยู่ในมือให้ส่งบ้าง ทีมวิศวกรของ Google ถามคำถามนี้ก่อนจะสร้างระบบใหม่ และคำตอบของพวกเขาคือต้องไม่มีอะไรเลย
Agent Compute Engine คืออะไร และทำไม Google ต้องสร้างขึ้นมา?
Agent Compute Engine คือบริการ compute ใหม่ของ Google Cloud ที่ให้ AI agent ทุกตัวมี microVM ของตัวเอง แยกขาดด้วยฮาร์ดแวร์ เร็วระดับ container และไม่มี credentials อยู่ใน sandbox เหตุผลคือ agent ต้องมีคอมพิวเตอร์จริงสำหรับรันโค้ด เปิดเบราว์เซอร์ และเรียกเครื่องมือ แต่ VM แบบเดิมช้า เริ่มหรือกลับมาทำงานต่อใช้เวลาตั้งแต่หลายวินาทีถึงหลายนาที ส่วน container เร็วแต่ใช้ kernel ร่วมกัน ไม่พอสำหรับ coding agent ที่ต้องการสิทธิ์ root ตามที่ Google ระบุ
ถ้า AI โดนหลอก จะไม่มีอะไรให้ขโมยได้ยังไง?
Google เริ่มจากสมมติว่าผู้โจมตีควบคุมทุกอย่างในเครื่องได้ แล้วออกแบบให้เขาไม่เจออะไรที่ใช้ได้ microVM ไม่เก็บ credentials ของผู้ใช้ API keys OAuth refresh tokens หรือ cloud service account keys และไม่มีการ์ดเครือข่ายตรงๆ ทุกคำขอต้องผ่าน proxy แล้วไปถึง Agent Gateway นอกเครื่อง gateway ตรวจสอบสิทธิ์ที่ผู้ใช้มอบให้ ตัวตนของ agent และตัวตนของเครื่อง แล้วใส่ credential จริงตอนคำขอออกจาก gateway ปลายทางจึงเห็นเป็นตัวตนมาตรฐานที่ตรวจย้อนหลังได้ ว่า agent ทำงานในนามของผู้ใช้คนไหน
ทำไม Google ต้องแยกตัวตนของ agent เป็น 4 แบบ?
เพราะระบบเดิมของ Google Cloud รู้จักผู้เรียกแค่สองแบบ คือคนกับ services แต่ agent ไม่ใช่ทั้งสองอย่าง ตัวตนทั้ง 4 แบบของ Agent Compute Engine ได้แก่
- User identity คือผู้ใช้ที่เริ่มคำขอ ใช้ยืนยันงานโดยรวมเท่านั้น
- Delegated Agent OBO Identity คือสิทธิ์ที่ผู้ใช้มอบให้ agent ทำงานเฉพาะอย่าง เก็บอยู่ใน authorization service กลาง ไม่เคยอยู่บนเครื่อง
- Agent Workload Identity คือตัวตนอายุสั้นของ microVM ตามมาตรฐาน SPIFFE ใช้ระบุว่าคำขอมาจาก sandbox ไหน เอาไปเรียก backend API ตรงๆ ไม่ได้
- Agent Workforce Identity คือ agent ที่ทำหน้าที่เป็นผู้ช่วยด้วยบัญชีและ resources ของตัวเอง
Agent ที่ว่างอยู่ ทำไมถึงแทบไม่กินทรัพยากร?
Google วัดแล้วพบว่า Agent ใช้เวลาส่วนใหญ่ไปกับการรอ model หรือรอผู้ใช้ ในแต่ละขณะมีแค่ส่วนน้อยที่รันโค้ดอยู่ เมื่อ agent รัน tool call เสร็จ sandbox จะส่งสัญญาณให้ host พักเครื่องแบบ checkpoint ไว้ และปลุกกลับเมื่อมีงานใหม่ ทำให้เครื่องเดียวรับ agent ได้มากกว่า VM ทั่วไปเป็นระดับ orders of magnitude นอกจากนี้ microVM ทุกตัวบน host ใช้หน้า memory ของ base image ชุดเดียวกัน เสียเพิ่มเฉพาะส่วนที่ agent แต่ละตัวแก้ไขจริง
ธุรกิจไทยควรดูอะไรจากเรื่องนี้?
บทความยังไม่ได้บอกราคา ภูมิภาคที่เปิดให้บริการ หรือวันเปิดตัวที่แน่นอน จึงยังไม่ใช่ข่าวให้รีบซื้อ แต่เป็นโจทย์ให้เตรียมตัว ก่อนจะให้ AI อ่านอีเมลหรือเรียกข้อมูลลูกค้าแทนพนักงาน ลองเช็คกับผู้ให้บริการ 3 เรื่อง รหัสและสิทธิ์ของ agent เก็บไว้ที่ไหน ถ้าเครื่องของ agent โดนเจาะ ผู้โจมตีเอาอะไรไปได้บ้าง และตรวจย้อนหลังได้ไหมว่า agent ทำอะไรในนามใคร เริ่มถามวันนี้ จะได้คำตอบพร้อมก่อนที่ระบบแบบนี้เปิดให้ใช้จริง
คำถามที่พบบ่อย (FAQs)
Q: Agent Compute Engine เปิดให้ใช้แล้วหรือยัง?
A: ยังไม่เปิดทั่วไป Google ระบุว่าตั้งเป้าเปิด preview ในอีกไม่กี่เดือนข้างหน้า
Q: ต้องเสียเงินเพิ่มไหม?
A: บทความต้นฉบับยังไม่ระบุราคา สิ่งที่ Google พูดถึงคือคุณไม่ต้องจ่ายค่า VM ที่ว่างอยู่
Q: Agent ที่ถูกพักไว้ จะลืมงานที่ทำค้างไหม?
A: ไม่ลืม Google ระบุว่าไฟล์และ memory ถูกเก็บข้ามรอบสนทนาและข้ามวัน agent กลับมาทำต่อจากจุดที่ค้างไว้ได้ทันที
Q: ถ้า Agent โดนหลอกด้วยข้อความซ่อนในอีเมล จะเกิดอะไรขึ้น?
A: ตัว Model อาจยังทำตามคำสั่งนั้นได้ แต่ sandbox ไม่มี credentials ให้ส่งออกไป ผู้โจมตีจึงไม่ได้อะไรที่ใช้ต่อได้
ถ้าคุณสนใจข่าวสารนี้ ให้ Add Line OA เพิ่ม: https://lin.ee/ulsmCKk หรือ @nhx2358e
