ข่าวเผยแพร่โดย Enterprise AI Thailand
Google เพิ่มแนวทางคุม Agent
ประเด็นสำคัญ
Agent ที่เรียกหลายระบบควรมีแผนตัวตนและสิทธิ์ตั้งแต่ผู้สั่งงานจนถึงระบบปลายทาง ระบุผู้อนุญาตในแต่ละช่วงและวิธีถอนสิทธิ์ โดยไม่ถือว่าเชื่อม MCP ได้แล้วเท่ากับอนุมัติทุกการกระทำ
- ข่าววันที่
- ตรวจทานล่าสุด
- เวลาอ่าน
- ประมาณ 2 นาที

Google ปรับคู่มือสถาปัตยกรรมส่วนใด
Google Cloud บันทึกการปรับแนวทางเมื่อ 27 ตุลาคม 2026 สำหรับ Agent ที่ประสานหลายระบบ โดยเพิ่ม Agent Identity, Gateway, Registry และ IAP
สถาปัตยกรรมฉบับปรับปรุง แนะนำการจำกัดสิทธิ์ ตัวตนผูกกับงาน และการกำกับโดยคนบนเส้นทาง orchestrator กับ MCP การแก้คู่มือนี้ไม่ใช่ประกาศว่าทุกองค์กรเปิดมาตรการเหล่านั้นแล้วโดยอัตโนมัติ
ต้องส่งตัวตนผ่านชั้นใดก่อนถึงข้อมูล
ข้อเสนอสำหรับผู้ซื้อระบบคือให้ทีมส่งมอบวาดตัวตนที่แต่ละบริการมองเห็น ไม่ใช้เพียงชื่อแอปบนหน้าจอเป็นคำตอบ ต้องอธิบายด้วยว่าเมื่อลูกจ้างหรือ Agent ถูกถอนสิทธิ์ บัญชีใดจะหยุดทำงานตาม
| ช่วงของคำขอ | คำถามที่ควรตอบ | หลักฐานที่ตรวจได้ |
|---|---|---|
| ผู้ใช้ถึง orchestrator | ใครเป็นผู้ขอและทำงานในนามใคร | ตัวตนผู้เรียกและสิทธิ์ตามบทบาท |
| orchestrator ถึงเครื่องมือ | เลือกเครื่องมือจากรายการใด | รายการที่อนุมัติและเจ้าของ |
| เครื่องมือถึงแอปเดิม | ระบบเดิมเห็นบัญชีใด | สิทธิ์อ่านและเขียนที่ปลายทาง |
| ผลกลับถึงผู้ใช้ | ผู้รับมีสิทธิ์เห็นผลทั้งหมดหรือไม่ | ขอบเขตข้อมูลและบันทึกคำขอ |
นี่เป็นแผนตรวจที่เสนอ ไม่ใช่ผลทดสอบ Google Cloud ให้ลองทั้งคำขอที่ควรผ่านและคำขอที่ต้องถูกปฏิเสธ โดยเฉพาะกรณีบัญชีบริการมีสิทธิ์มากกว่าผู้สั่งงาน
จะถอนสิทธิ์และหยุดงานข้ามระบบอย่างไร
กำหนดเจ้าของการเชื่อมต่อแต่ละเส้น และจุดหยุดเมื่อขาดการอนุมัติหรือพิสูจน์ตัวตนไม่สำเร็จ ก่อนรับระบบควรมีตัวอย่างบันทึกที่ตามคำขอเดียวกันได้ตั้งแต่ต้นจนจบ โดยไม่คัดลอกข้อมูลส่วนตัวเกินจำเป็นลง log
ใช้แผนนี้ประกอบการเลือก สถาปัตยกรรม AI สำหรับองค์กร การมี reference architecture ไม่ได้ยืนยันความพร้อมในทุกภูมิภาค การปฏิบัติตามกฎหมายไทย หรือการเชื่อมบริการเหล่านี้ใน Mimir
วิดีโอ Gemini ในงาน I/O เดือนพฤษภาคมเป็นบริบทเรื่อง Agent เท่านั้น ไม่ใช่การสาธิต Cloud Run, IAP หรือการตั้งค่าความปลอดภัยในคู่มือนี้
คำถามที่พบบ่อย
- มี Agent Gateway แล้วจำเป็นต้องคุมสิทธิ์ระบบปลายทางอีกหรือไม่
- ควรกำหนดทั้งสองชั้น Gateway มีหน้าที่ในเส้นทางเรียกใช้งาน ส่วนระบบปลายทางต้องจำกัดข้อมูลและการกระทำตามสิทธิ์ที่องค์กรตั้งไว้ด้วย
- ควรเริ่มวาดเส้นทางตัวตนจากจุดใด
- เริ่มจากผู้เรียก แล้วตามไปยังตัว orchestrator เครื่องมือ และบัญชีที่ระบบปลายทางเห็น ระบุทุกจุดที่มีการเปลี่ยนตัวตนหรือใช้บัญชีบริการร่วม
วิดีโอที่เกี่ยวข้อง
Gemini | I/O 2026 Keynote
Google · เผยแพร่
วิดีโอประกอบความเข้าใจ
ดูวิดีโอต้นทางบน YouTube
แหล่งข้อมูล
- Architecture Center changes: 27 October 2026
Google Cloud
- เผยแพร่ต้นทาง
- เข้าถึงข้อมูล
- Enterprise orchestration architecture: revised 27 October
Google Cloud
- เผยแพร่ต้นทาง
- เข้าถึงข้อมูล