Google ปล่อยพิมพ์เขียว zero-trust สำหรับ AI agent — เซ็นทุกการเขียนข้อมูลด้วย HSM และรันโค้ดใน gVisor ที่ไม่มีเน็ต

17 ส.ค. 2026 Google Developers Blog เผยแพร่บทความและ reference implementation แบบโอเพนซอร์ส ที่ตอบคำถามซึ่งทีมส่วนใหญ่ยังตอบไม่ได้: จะปล่อยให้เอเจนต์ตัดสินใจเองได้แค่ไหน โดยที่ไม่ต้องเชื่อว่าโมเดลจะประพฤติดี

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

สามชั้นของสถาปัตยกรรมนี้

1. เซ็นด้วยกุญแจที่ฝังในฮาร์ดแวร์ (hardware-backed signatures)

ทุกคำสั่งที่เปลี่ยนสถานะข้อมูลต้องถูกเซ็นด้วย asymmetric key ที่เก็บใน Cloud HSM โดยเอเจนต์ตัวที่ร้องขอ — บทความระบุว่า “ทุกการเขียนที่เปลี่ยนสถานะต้องถูกเซ็นโดยเอเจนต์ตัวที่ร้องขอนั้น” ผลที่ได้คือ non-repudiation: เมื่อเกิดเหตุ คุณตอบได้ว่าเอเจนต์ตัวไหนสั่งอะไร และพิสูจน์ได้ทางเข้ารหัส ไม่ใช่แค่ดูจาก log ที่แก้ได้

2. Sandbox ระดับเคอร์เนล

โค้ดที่โมเดลสร้างขึ้นจะถูกรันใน gVisor — user-space container ที่แยก syscall ออกจากเคอร์เนลจริง — พร้อมเงื่อนไขสามข้อ: ไม่มี network egress เลย, จำกัดทรัพยากรเข้ม, และ drop capabilities ทิ้ง แปลว่าต่อให้โมเดลถูก prompt injection จนเขียนโค้ดดูด secret ได้จริง ก็ไม่มีทางส่งมันออกไปข้างนอก

3. Semantic gateway ที่ทำงานแบบ deterministic

ชั้นสุดท้ายคือ proxy ตรวจ input/output ที่บังคับกฎธุรกิจด้วยการตรวจแบบ regex และ regression test — จงใจให้เป็น deterministic ไม่ใช่ให้ AI ตัดสิน เพื่อสกัดทั้งความพยายาม jailbreak และธุรกรรมที่หลุดกรอบที่กำหนดไว้

ของจริงที่ดาวน์โหลดไปรันได้

จุดที่ทำให้บทความนี้มีน้ำหนักกว่า whitepaper ทั่วไปคือ Google ปล่อยเดโมที่ทำงานได้จริงใน repo zero-trust-agents บน GitHub (อยู่ในโครงการ GoogleCloudPlatform/generative-ai) รันในเครื่องได้ด้วย ./demo/run_demo.sh และมีแดชบอร์ดในเบราว์เซอร์ให้กดดูว่าแต่ละชั้นทำงานอย่างไร

บทความไม่ได้ระบุเลขเวอร์ชันของ ADK เอาไว้ — เอกสารประกอบอยู่ที่ google.github.io/adk-docs

มุมมอง AI Curator

ถ้าอ่านโพสต์นี้คู่กับเคสที่ Copilot Autofix เปิดช่องโหว่ใน CI ของ Snowflake ซึ่งเปิดเผยวันเดียวกันพอดี จะเห็นภาพชัดขึ้นมาก — ทั้งสองเรื่องพูดถึงปัญหาเดียวกันคนละมุม: เราเริ่มให้ AI เขียนและรันโค้ดในระบบจริงแล้ว แต่ยังไม่ได้ย้ายขอบเขตความปลอดภัยตามไปด้วย

สิ่งที่ผมชอบในดีไซน์ของ Google คือมันยอมรับตั้งแต่ต้นว่า โมเดลจะถูกหลอกได้ แล้วออกแบบให้ต่อให้ถูกหลอกก็ทำอะไรไม่ได้ ตรงข้ามกับแนวทางที่วงการทำกันเยอะคือเติม guardrail ด้วย LLM อีกตัวมาคอยตรวจ — ซึ่งก็คือเอาสิ่งที่ถูกหลอกได้มาเฝ้าสิ่งที่ถูกหลอกได้ การเลือกใช้ regex และ regression test ในชั้น gateway อาจดูโบราณ แต่มันคือคุณสมบัติที่สำคัญที่สุดของระบบความปลอดภัย: ทำนายพฤติกรรมได้และทดสอบซ้ำได้

ข้อจำกัดที่ต้องพูดให้ตรง: นี่เป็น reference implementation ที่ผูกกับบริการของ Google Cloud อยู่พอสมควร — Cloud HSM ไม่ฟรีและไม่ใช่ของที่สตาร์ทอัพจะเปิดใช้เป็นค่าเริ่มต้น ส่วน gVisor นั้นเปิดกว้างกว่าและใช้ได้นอก GCP แต่ก็แลกมาด้วย overhead ของ syscall ทีมส่วนใหญ่จึงยังไม่ควรลอกทั้งชุด

แต่หลักการสามข้อนี้แยกออกมาใช้ได้ทันทีโดยไม่ต้องมี GCP: (1) ให้เอเจนต์เขียนข้อมูลผ่าน service account เฉพาะตัวที่แยกกัน ไม่ใช่ใช้ credential ร่วมกันทั้งระบบ (2) รันโค้ดที่โมเดลสร้างในคอนเทนเนอร์ที่ตัด network egress — แค่ข้อนี้ข้อเดียวก็ตัดช่องทางขโมยข้อมูลออกไปเกือบทั้งหมด (3) ตรวจ output ด้วยกฎที่เขียนเป็นโค้ด ไม่ใช่ให้ LLM ตรวจ LLM

สำหรับทีมไทยและ SEA ที่กำลังทำ agent แตะระบบหลังบ้านจริง — ธนาคาร, e-commerce, บริการภาครัฐ — ผมคิดว่าคำถามที่ควรถูกถามในห้องประชุมถัดไปคือ “ถ้าเอเจนต์ของเราถูก prompt injection สำเร็จวันนี้ มันส่งข้อมูลออกไปข้างนอกได้ไหม” ถ้าคำตอบคือ “ได้” หรือ “ไม่แน่ใจ” นั่นคือช่องว่างที่ต้องปิดก่อนจะไปคุยเรื่องความสามารถของโมเดล และข่าวดีคือการปิดช่องนี้ไม่ต้องรอโมเดลที่ฉลาดขึ้น — เป็นงาน infrastructure ที่ทำได้เลยตั้งแต่สัปดาห์นี้

แหล่งข่าว

• Build zero-trust AI agents with Google’s Agent Development Kit — Google Developers Blog (17 ส.ค. 2026)
• Agent Development Kit — เอกสารทางการ
• GoogleCloudPlatform/generative-ai — repo ตัวอย่างของ Google Cloud