เกราะ 3 ชั้นสำหรับ AI Agent ที่แตะเงิน: Google ADK เปิด blueprint + open-source repo

ข่าวนี้คืออะไร

วันที่ 17 ส.ค. 2026 ทีม Google Agent Development Kit (ADK) เผยแพร่บทความ “Build zero-trust AI agents with Google’s Agent Development Kit” พร้อม open-source repository บน GitHub (อยู่ใน GoogleCloudPlatform/generative-ai) ที่ให้โค้ดตัวอย่าง agent รับเรื่องคืนสินค้าและคืนเงิน พร้อมฉากโจมตีจริงให้ทดสอบว่าเกราะที่ใส่ไว้ทนหรือไม่

ประเด็นของข่าวไม่ใช่รุ่นโมเดลใหม่ แต่เป็นแบบแปลน (blueprint) วิธีปล่อย agent ออกไปทำงานกับของจริง ทั้งเงิน ทั้งฐานข้อมูล โดยไม่ต้องเชื่อว่าตัวโมเดลจะ “เป็นของดี” เสมอไป

ทำไมต้องสนใจ ถ้า agent ของเราแตะเงินหรือฐานข้อมูล

เวิร์กโฟลว์ AI ที่คนทำงานจริงกำลังไปในทิศทางเดียวกัน: จาก “แชทกับ AI” ไปเป็น “ให้ AI ออก action” อย่างสร้างใบเสนอราคา อัปเดตสต็อก ตอบลูกค้า หรือคืนเงิน

จุดเปลี่ยนคือวันที่เราต่อ agent เข้ากับฐานข้อมูลและระบบจ่ายเงิน ตั้งแต่วันนั้นมันไม่ใช่แอปสร้างข้อความอีกต่อไป แต่เป็นระบบที่เปลี่ยนสถานะของธุรกิจจริง ๆ

Google ยกตัวอย่างที่เจ็บที่สุดในบทความ: ลูกค้าส่งข้อความขอคืนเงิน $10,000 จากออเดอร์ $149 พร้อมขอให้ agent “รันสคริปต์เช็กว่าเงินเข้าไหม” ซึ่งเป็นข้อความเดียวที่ถ้าระบบไม่มีเกราะ จะกลายเป็นทั้งการจ่ายเงินเกินและการยังรหัสลับทั้งเครื่องออกไปในคำขอเดียว

และคำตอบที่ Google ย้ำคือ การเขียนกฎไว้ใน system prompt ว่า “ห้ามคืนเงินเกินมูลค่าออเดอร์” ไม่ใช่ความปลอดภัย เพราะ prompt ถูกหลอกได้ ถูกแก้ระหว่างปรับจูน และพังเงียบ ๆ เวลาเปลี่ยนรุ่นโมเดล

เกราะ 3 ชั้น คืออะไร ในภาษาคนทำงาน

ชั้นที่ 1: เซ็นชื่อกำกับทุกครั้งที่ agent เขียนข้อมูล

ทุกครั้งที่มีการแก้ฐานข้อมูล ให้แนบลายเซ็นที่คำนวณจากตัวข้อมูลเอง โดยใช้กุญแจของ agent ตัวนั้น ๆ ไว้ด้วย

ผลที่ได้จริงมีสองอย่าง อย่างแรก ถ้ามีคนแอบแก้เลขเงินตรงในฐานข้อมูลหลังบ้าน เลขกับลายเซ็นจะไม่ตรงกัน ระบบตรวจย้อนได้ทันที อย่างที่สอง ถ้า agent ตัวไหนทำอะไรผิด เรารู้ชื่อมันทันทีเพราะทุกรายการผูกกับกุญแจของเจ้าของรายการ ไม่ใช่ connection รวมที่ทุกตัวใช้ร่วมกัน

ในโค้ดตัวอย่าง ชั้นนี้ใช้ HMAC รันในเครื่องได้เลย ส่วน production บน Google Cloud คือเปลี่ยนไปเซ็นด้วย Cloud KMS ที่กุญแจอยู่ใน HSM ไม่ต้องเก็บไฟล์กุญแจไว้ในเครื่องเซิร์ฟเวอร์

ชั้นที่ 2: รันโค้ดที่ agent เขียน ในกรงที่ตัดเน็ต

agent หลายตัวต้องเขียน Python สั้น ๆ ระหว่างทำงาน เช่น คำนวณส่วนลดตามสัดส่วน หรือแปลงไฟล์ ปัญหาคือโค้ดที่โมเดลเขียนอาจถูกฝังคำสั่งไม่ดีเข้ามา เช่น ส่งค่า environment ทั้งใบ (ที่มี API key) ออกไปยังเซิร์ฟเวอร์คนร้าย

วิธีของ blueprint นี้: เอาโค้ดที่ agent เขียนไปรันใน gVisor container ที่ (1) ตัดเครือข่ายออกทั้งหมด (2) ตัดสิทธิ์ root ทั้งหมด (3) จำกัดแรม 64MB (4) จำกัด CPU และหมดเวลาใน 5 วินาที ถ้าโค้ดพยายามอ่านไฟล์ระบบหรือต่อเน็ตออก ระบบปฏิบัติการบังคับระดับ kernel ไม่ให้ทำ ไม่เกี่ยวกับว่าโมเดลจะถูกหลอกหรือไม่

ชั้นที่ 3: ตัวกรองกฎตายตัว หน้าและหลังตัวโมเดล

กฎธุรกิจแบบ “คืนเงินได้ไม่เกินมูลค่าออเดอร์” หรือ “ห้ามส่งรหัสบัตรออกนอกระบบ” ต้องอยู่ในโค้ดที่เราควบคุม ไม่ใช่อยู่ใน prompt

ตัวกรองทำงานสองจุด ก่อนส่งข้อความเข้าโมเดล และก่อนส่งคำสั่งออกไปแก้ฐานข้อมูล มันเช็กด้วยกฎตายตัว เช่น เจอรูปแบบบัตรเครดิตหรือคำว่า sk_live ใน output ให้หยุดทันที เจอคำขอแก้ยอดเงินที่ไม่ตรงกับออเดอร์ให้หยุดทันที

ส่วนที่คนมองข้ามแต่สำคัญมาก: กฎพวกนี้ต้องมี automated test ใน CI คอยรันทุกครั้งที่แก้ prompt หรือเปลี่ยนรุ่นโมเดล เพราะสิ่งที่ยอมให้ผ่านเมื่อเดือนก่อน อาจหลุดหลังอัปเดตโดยเราไม่รู้ตัว

จะเอาไปใช้กับทีมเล็กได้ยังไง

1. ลองฉากโจมตีจริงก่อนเขียนโค้ดเอง โคลน repo แล้วรัน demo ในเครื่อง ดูสด ๆ ว่าข้อความขอคืนเงิน $10,000 จากออเดอร์ $149 โดนชั้นไหนสกัดไว้ ร้อยเห็นหนึ่งครั้งดีกว่าอ่านสิบรอบ
2. เช็ค agent ที่กำลังจะปล่อย ด้วยเช็กลิสต์ 3 ชั้นด้านล่าง ถ้าตอบ “ไม่มี” ครบทั้ง 3 ชั้น และ agent แตะเงินหรือฐานข้อมูล ให้ถือว่ายังไม่พร้อม
3. เริ่มจากชั้นที่ 3 ก่อน ถ้าทำได้ทีเดียวแค่อย่างเดียว ตัวกรองกฎตายตัวหน้า-หลังโมเดลคือของที่คุ้มที่สุดสำหรับทีมเล็ก เพราะเขียนเป็นโค้ดธรรมดา ทดสอบด้วย unit test ได้ ไม่ต้องมีโครงสร้างพิเศษ
4. ถ้า agent ต้องเขียนโค้ดระหว่างทำงาน ทำชั้นที่ 2 บังคับ ไม่ต้องถึง gVisor ก็เริ่มได้ ด้วย container ที่ตัดเน็ต จำกัดแรม และมี timeout
5. อย่าประกาศว่า “ปลอดภัยแล้ว” เกราะ 3 ชั้นลดความเสี่ยง ไม่ได้ลดเหลือศูนย์ ทุกชั้นต้องคอยอัปเดตและทดสอบต่อ

Operator Kit: เช็กลิสต์เกราะ 3 ชั้นสำหรับ Agent ที่แตะเงินหรือฐานข้อมูล

ใช้เช็คก่อนปล่อย agent เข้า production ตอบ “ผ่าน” ให้ได้ทุกข้อก่อนกดยืนยัน

ชั้นที่ 1: รอยเซ็นและร่องรอยย้อนได้

• [ ] ทุกครั้งที่ agent เขียนหรือแก้ข้อมูลสำคัญ มีลายเซ็นหรือกุญแจประจำตัว agent นั้นกำกับอยู่
• [ ] มีงานตรวจย้อน (audit) ที่เทียบข้อมูลกับลายเซ็นเป็นระยะ ถ้าไม่ตรงต้องมี alert ไม่ใช่เงียบ
• [ ] ไม่มี agent สองตัวขึ้นไปที่ใช้สิทธิ์เดียวกันแบบแยกไม่ออกว่าใครทำอะไร

ชั้นที่ 2: กรงสำหรับโค้ดที่ agent เขียน

• [ ] โค้ดที่ agent สร้างระหว่างทำงาน รันในสภาพแวดล้อมแยกส่วน ไม่ใช่รันบนเครื่องหลักตรง ๆ
• [ ] กรงนั้นต่ออินเทอร์เน็ตออกไม่ได้
• [ ] มีข้อจำกัดหน่วยความจำ CPU และเวลา โค้ดวนลูปไม่รู้จบต้องตายเอง

ชั้นที่ 3: ตัวกรองกฎตายตัวหน้า-หลังโมเดล

• [ ] กฎวงเงินและของห้าม (ยอดเงินสูงสุด รหัสบัตร รหัสลับ) อยู่ในโค้ดที่เราควบคุม ไม่ใช่ใน system prompt อย่างเดียว
• [ ] มีการสกัดทั้ง input ก่อนเข้าโมเดล และ output ก่อนออก action
• [ ] กฎเหล่านี้มี automated test รันใน CI และรันซ้ำทุกครั้งที่เปลี่ยน prompt หรือเปลี่ยนรุ่นโมเดล

5 คำถามที่ตอบไม่ผ่านก็ยังอย่าปล่อย

1. ถ้ามีคนหลอก agent ให้จ่ายเงินเกินจริง อะไรคือสิ่งแรกที่หยุดเขาได้ และมันอยู่นอกตัวโมเดลหรือเปล่า
2. ถ้าโค้ดที่ agent เขียนถูกฝังคำสั่งส่งข้อมูลออก มันต่อเน็ตออกได้ไหม
3. ถ้ามีคนแก้ยอดเงินตรงในฐานข้อมูล ระบบรู้ได้ไหม รู้ได้ภายในกี่นาที
4. ถ้าเปลี่ยนรุ่นโมเดลพรุ่งนี้ ใครหรืออะไรการันตีว่ากฎเดิมยังทำงาน
5. ถ้า agent ทำผิด เราไล่ย้อนได้ไหมว่าตัวไหน คำสั่งไหน เวลาไหน

SOP เริ่มวันนี้ (60 นาที)

1. โคลนโปรเจกต์ตัวอย่าง: git clone https://github.com/GoogleCloudPlatform/generative-ai แล้วเข้าโฟลเดอร์ agents/adk/zero-trust-agents
2. รัน ./demo/run_demo.sh ดูฉากโจมตีทั้งสามแบบว่าโดนชั้นไหนสกัด
3. เปิด demo/gateway_guard.py ดูตัวอย่างกฎตายตัวที่สั้นที่สุด แล้วเขียนกฎ 3 ข้อสำหรับ agent ของทีมเราเอง (วงเงิน ของห้ามส่งออก คำสั่งห้ามปล่อยผ่าน)
4. เขียน unit test 3 ข้อคู่กับกฎที่เขียน แล้วยัดเข้า CI ให้เสร็จในวันเดียว
5. จดผลไว้ตอบ 5 คำถามด้านบน ก่อนนำ agent ไปพรีเซนต์ว่าพร้อมขึ้น production

ข้อจำกัดที่ควรรู้

• โค้ดตัวอย่างใช้ HMAC key จำลองเพื่อให้รันได้ในเครื่อง การขึ้นจริงต้องเปลี่ยนเป็นบริการเซ็นกุญแจแบบมี HSM เช่น Cloud KMS
• ฉากโจมตีใน demo เป็นการสาธิตของผู้เขียนเอง ไม่ใช่ผลวิจัยความปลอดภัยอิสระ อย่าถือว่าครอบคลุมทุกรูปแบบการโจมตี
• ถ้า agent ของเรายังไม่แตะเงินหรือฐานข้อมูล ทั้งสามชั้นอาจยังเร็วเกินไป เริ่มที่ชั้นที่ 3 พอ
• การนำไปใช้บน Google Cloud มี mapping ไปเป็นบริการจริง (KMS, gVisor ผ่าน GKE, VPC Service Controls) ซึ่งมีต้นทุนและความซับซ้อนของตัวเอง

เริ่มต้นกับ Data-Espresso

ถ้าทีมคุณกำลังจะปล่อย agent ตัวแรกที่แตะงานจริงแต่ยังไม่มีระบบเช็กลิสต์แบบนี้ Data-Espresso ช่วยแปลงข่าว AI เป็นเวิร์กโฟลว์ที่ใช้งานได้จริงในบริบทธุรกิจคุณ ทั้งการออกแบบขอบเขตงาน agent การวางตัวกรองกฎ และการทดสอบก่อนปล่อยจริง หรือถ้าอยากได้สภาพแวดล้อมรัน agent ที่แยกส่วนพร้อมชุดเครื่องมือครบ ลองดู OPB Stack ได้ครับ