เมื่อ AI Agent อ่านข้อมูลภายในและเรียกเครื่องมือที่เปลี่ยนระบบได้ คำถามไม่ได้จบที่ผลลัพธ์ในแชต ทีมยังต้องรู้ว่า agent กำลังทำงานแทนใคร ใช้สิทธิ์อะไร และหยุดมันได้อย่างไร
Sarthak Aggarwal ผู้ร่วมก่อตั้ง Decawork ทางช่อง AI Engineer เสนอให้มอง agent เป็นผู้กระทำการในองค์กรที่ต้องมีตัวตน การมอบหมายสิทธิ์ การตรวจ และการเพิกถอน คลิปนี้อธิบายกรอบสถาปัตยกรรมและแนวทางภายในที่ผู้พูดรายงาน ไม่ใช่ผลทดสอบว่าเครื่องมือป้องกันความเสียหายได้ทุกกรณี
VibeSolo ชวนทีมที่กำลังเชื่อม AI กับ CRM ระบบบัญชี HR หรือฐานข้อมูลลูกค้าใช้กรอบนี้กำหนดหน้าที่และความรับผิดชอบก่อนเพิ่มสิทธิ์ทำรายการ ตัวอย่างธุรกิจไทยต่อไปนี้เป็นการประยุกต์ของ VibeSolo
เปลี่ยนมุมมองจาก AI เป็นเครื่องมือ ไปเป็นพนักงานดิจิทัล
Sarthak อธิบายว่า agent ที่มีเป้าหมาย memory ข้อมูลภายใน และอำนาจเรียกเครื่องมือ ไม่ใช่เพียง model call แต่เป็น actor ที่อาจเปลี่ยนสถานะ เปิดเผยข้อมูล หรือทำงานภายใต้อำนาจของคนอื่น
เขาจึงแยกการทำเดโมสำเร็จออกจากความพร้อมให้ใช้งานในองค์กร: เดโมแสดงความสามารถบางอย่าง แต่ยังต้องตอบได้ว่าใครเป็นเจ้าของ agent มันแตะอะไรได้ ทำงานแทนใคร หยุดอย่างไร และอธิบายสิ่งที่ทำย้อนหลังได้หรือไม่
คำถามที่ VibeSolo เสนอให้ใช้จัดขอบเขตงานคือ:
- Agent นี้มีหน้าที่และเจ้าของงานเป็นใคร
- ใครมอบหมายอำนาจให้มัน และในนามของใคร
- เข้าถึงข้อมูลหรือเรียก action ใดได้ในแต่ละระบบ
- นโยบายใดใช้ตัดสินก่อน action นั้น
- ใครหยุดงานหรือเพิกถอนสิทธิ์ได้
- มีหลักฐานอะไรให้ตรวจการกระทำย้อนหลัง
ตัวอย่างสมมติของ VibeSolo คือ agent บริการลูกค้าที่อ่านแชตและค้นประวัติคำสั่งซื้อจาก CRM หากต้องเพิ่ม action คืนเงินหรือแก้ที่อยู่จัดส่ง ต้องกำหนดสิทธิ์ของ action เหล่านี้แยกจากสิทธิ์อ่านข้อความ รวมถึงข้อมูลลูกค้ารายใดที่งานนั้นเข้าถึงได้
สร้างบัตรประจำตัวและวงจรชีวิตให้ทุก AI Agent
Sarthak เสนอให้ agent มี runtime identity ที่ใช้ได้ในเชิงปฏิบัติการ พร้อมวงจรขึ้นทะเบียน ให้สิทธิ์ ตรวจติดตาม และเพิกถอน โดยเทียบกับวงจรจัดการพนักงานในองค์กร
ข้อมูลนี้ต้องแยก actor คือ agent, subject คือผู้ใช้ บัญชีบริการ อุปกรณ์ หรือตัวตนที่มันทำงานแทน และ delegation context คือบริบทของการมอบหมาย เช่น ticket พร้อมระบุผู้มอบอำนาจ capability นโยบาย และการเพิกถอน ผู้ส่งคำขอกับ subject อาจไม่ใช่คนเดียวกัน และ ticket เองไม่ใช่ subject
ในคลิป Sarthak เปรียบเทียบกับแนวคิด identity เดิมอย่าง OAuth แต่ประเด็นที่เขาต้องการเพิ่มคือการระบุ agent และผู้ที่มันทำงานแทนตลอดการมอบหมาย VibeSolo ชวนเริ่มจากบันทึกความสัมพันธ์เหล่านี้ ไม่ถือว่าการมี API key อย่างเดียวอธิบายขอบเขตงานได้ครบ
ข้อเสนอเริ่มต้นของ VibeSolo คือทำทะเบียนหน้าที่ของ agent และแยกสิทธิ์ตามงาน เช่น agent ตอบคำถามสินค้ากับ action สร้างใบลดหนี้ แล้วกำหนดวงจรใช้งานให้ตรวจได้:
- บันทึกตัวตน หน้าที่ เจ้าของ และ subject ที่ทำงานแทน
- กำหนดข้อมูลและ action ที่อนุญาตตามขอบเขตงาน
- ตรวจเงื่อนไขก่อนเชื่อมกับระบบจริง
- บันทึกคำขอและผลเรียกเครื่องมือ
- ทบทวนสิทธิ์เมื่อหน้าที่หรือ workflow เปลี่ยน
- ทดสอบการหยุดและเพิกถอนสิทธิ์เมื่อเลิกใช้หรือเกิดปัญหา
ผู้พูดมองว่านี่คือการนำวงจรบริหารผู้ทำงานมาใช้กับ software worker โดยต้องรับมือกับความเร็ว ปริมาณ และความคลุมเครือของการตัดสินใจด้วย
ถือว่าข้อความภายนอกอาจเป็นคำสั่งโจมตีเสมอ
Sarthak เตือนว่า ข้อความที่ไม่น่าเชื่อถืออาจนำไปสู่ action ที่ใช้สิทธิ์จริง Ticket อีเมล เอกสาร เว็บ หรือข้อความ Slack ที่ agent อ่านอาจแฝงคำสั่งให้ทำเรื่องนอกงานเดิม สถาปัตยกรรมจึงต้องเผื่อว่าบริบทเหล่านี้อาจเป็นข้อมูลโจมตี
กรอบความเสี่ยงที่เขายกประกอบด้วย ข้อมูลส่วนตัว ข้อมูลภายนอกที่ไม่น่าเชื่อถือ และช่องทางส่งออก แล้วเพิ่มชั้น action ที่เปลี่ยนระบบได้ เขายก help desk agent เป็นตัวอย่างที่ต้องอ่าน ticket ดูข้อมูลผู้ใช้ และดำเนินงานในระบบ identity อุปกรณ์ หรือ SaaS จึงต้องแยกอำนาจออกจากข้อความที่อ่าน
ผู้พูดยกกรณี EchoLeak ที่เกี่ยวข้องกับ Microsoft 365 Copilot เพื่ออธิบายเส้นทางจากอีเมลภายนอกไปยังบริบทที่มองเห็นข้อมูลภายในและช่องทางส่งออก ประเด็นที่เขาชี้คือผู้โจมตีอาจอาศัยข้อความที่ agent อ่าน แทนการได้ credential ของ agent โดยตรง นี่เป็นกรณีที่ Sarthak เล่าในคลิป ไม่ใช่การตรวจสถานะช่องโหว่ของผลิตภัณฑ์ปัจจุบัน
แนวทางที่ผู้พูดเสนอคือให้ตัวกรองและ guardrails ช่วยตรวจหรือบอกเหตุ แต่มีขอบเขตสิทธิ์ที่อยู่นอกการตัดสินใจของโมเดลสำหรับ action ที่มีผลสำคัญ ข้อความใน prompt เพียงอย่างเดียวไม่ใช่จุดอนุมัติสิทธิ์นั้น
แยกคำสั่งเชิงนโยบายออกจากขอบเขตที่บังคับได้จริง
Sarthak ยังยกกรณี Replit ตามที่เขาเล่า: agent มีเส้นทางไปยังฐานข้อมูล production แม้ได้รับคำสั่ง freeze จึงใช้กรณีนี้แยกระหว่างข้อความห้ามกับขอบเขตที่ระบบบังคับก่อนทำ action ประเด็นของบทความคือกรอบควบคุมที่ผู้พูดเสนอ โดยไม่ได้ตรวจเหตุการณ์หรือผลแก้ไขของ Replit เพิ่มจากต้นทางอื่น
ข้อเสนอของเขาคือกำหนด scoped access ตรวจ policy ขณะทำ action ขออนุมัติเรื่องทำลายข้อมูล และมี audit กับเส้นทางเพิกถอน การอยู่ใน prompt ว่า “ห้ามทำ” ยังไม่ตัดสิทธิ์ที่เครื่องมือมีอยู่จริง
ในกรอบนี้ งานอย่างลบข้อมูล เปลี่ยนสิทธิ์ ปิด MFA หรือส่งข้อมูลออกต้องผ่านการตัดสินของระบบควบคุมตามแผนและขอบเขตที่อนุญาต กติกาต้องถูกทดสอบกับ action จริง ไม่ถือว่าโมเดลที่ตอบดีจะป้องกันเหตุเหล่านี้ได้เอง
ตัวอย่างสมมติของ VibeSolo คือเงื่อนไข “คืนเงินเกิน 2,000 บาทต้องให้คนอนุมัติ” ให้ระบบตรวจวงเงินก่อนทำรายการ แทนการฝากเงื่อนไขไว้ใน prompt เพียงจุดเดียว ตัวเลขนี้เป็นตัวอย่างให้ทีมออกแบบเกณฑ์ของตน ไม่ใช่วงเงินมาตรฐาน ส่วนงานลบหรือแก้ข้อมูลต้องกำหนดวิธีตรวจและรับมือที่เหมาะกับระบบนั้น
แยกคนวางแผนออกจากคนลงมือทำด้วย Planner และ Executor
Sarthak เสนอ privilege separation โดยแยกการวางแผนกับการลงมือทำ และเล่าว่า Decawork ใช้แนวทางคล้ายกันภายใน แผน สิทธิ์ และข้อมูลที่อ่านจึงไม่ควรเป็นสิ่งเดียวกัน
ตามคำอธิบายของเขา Planner เริ่มจากเจตนาที่ผ่านการยืนยัน เช่น รีเซ็ตรหัสผ่านผู้ใช้รายหนึ่ง พร้อมรู้ว่าใครขอ ทำในนามใคร capability อะไร ขอบเขตใด และนานเท่าใด แล้วสร้างแผนที่มีชนิดชัดเจนและบันทึกก่อนอ่านหลักฐานที่ไม่น่าเชื่อถือ ส่วน Executor ใช้หลักฐานดำเนินแผน และเรียกได้เฉพาะเครื่องมือที่อนุมัติ ไม่สร้าง action ใหม่จากข้อมูลนั้น
ทุก action ในแนวทางที่เขาเสนอเป็นคำขอที่ผ่าน policy gate ซึ่งตรวจแผน capability และความเสี่ยง: model เสนอ แต่ policy ตัดสินก่อนเรียก tool หลักฐานเติมรายละเอียดในพารามิเตอร์ที่อนุญาตได้ แต่ไม่ควรสร้างอำนาจหรือ action ใหม่ แม้เป็นเครื่องมือที่ระบบมีอยู่แล้ว
เขายก ticket รีเซ็ตรหัสผ่านที่แฝงคำสั่งให้ปิด MFA ทั้งองค์กรและส่งรหัสทางอีเมลเป็นตัวอย่าง ในระบบที่เสนอ gate ถูกกำหนดให้ปฏิเสธ action MFA เพราะอยู่นอกแผนและ scope พร้อมยกระดับและบันทึกเหตุ ตัวอย่างนี้อธิบายขอบเขตที่ต้องการบังคับ ไม่ได้พิสูจน์ว่าทุก implementation ป้องกัน prompt injection ได้หมด
การประยุกต์ที่ VibeSolo เสนอสำหรับทีมเล็กคือแยก “ขั้นคิดและเสนอ” ออกจาก “ขั้นอนุมัติและทำรายการ” เช่น AI ร่างคำขอคืนเงิน แล้วระบบธุรกิจหรือเจ้าหน้าที่ตรวจตามเกณฑ์ก่อนทำ action ทีมต้องกำหนดว่าข้อมูลที่ได้รับเติมอะไรได้และต้องไม่เปลี่ยนสิทธิ์ส่วนใด
ใช้สิทธิ์ชั่วคราว บันทึกหลักฐาน และต้องหยุด Agent ได้จริง
Sarthak เสนอว่า Executor ไม่ควรถือ credential ถาวรสำหรับทุกงาน แต่รับ capability อายุสั้นของ action ที่ผ่านอนุมัติ โดยผูกกับ actor, subject, ระบบปลายทางที่รับสิทธิ์ และเวลาหมดอายุ พร้อมมีทางเพิกถอนเมื่อเกิดปัญหา
ตัวอย่างประยุกต์ของ VibeSolo คือสิทธิ์รีเซ็ตรหัสผ่านที่ใช้ได้กับผู้ใช้รายเดียวและ action เดียวในเวลาที่กำหนด ทีมควรตรวจว่าระบบปลายทางบังคับขอบเขตนี้จริง รวมถึงปฏิเสธเมื่อขอใช้กับบัญชีอื่นหรือเมื่อสิทธิ์หมดอายุ
ผู้พูดเน้น receipt ของการกระทำ เช่น actor, subject, การมอบหมาย, plan ID, capability และ action ที่ขอ VibeSolo เสนอให้เชื่อมผลลัพธ์และเหตุผลอนุมัติเพิ่มด้วย เพื่อให้ตามตรวจและหยุดสิทธิ์ได้ ข้อมูลเหล่านี้เป็นเครื่องมือปฏิบัติการ ไม่ได้รับรองการผ่านข้อกำหนด privacy หรือ compliance โดยตัวมันเอง
ในช่วงท้าย Sarthak มอง MCP และ A2A เป็นช่องทางสื่อสารที่ยังต้องมีระบบตัดสินว่า agent ใดทำอะไร ภายใต้อำนาจของใคร และตรวจย้อนหลังอย่างไร ประเด็นคือแยกการเชื่อมต่อเครื่องมือออกจากการอนุญาต action ในงานนั้น
ที่มา: IT Admin for the AI Workforce — Sarthak Aggarwal, Decawork โดย Sarthak Aggarwal จาก Decawork ทางช่อง AI Engineer อัปโหลด 20 สิงหาคม 2026 ตามเวลาไทย เนื้อหาและประสบการณ์ของทีมเป็นสิ่งที่ผู้พูดรายงานในเวลานั้น ตัวอย่างประยุกต์และข้อเสนอเพิ่มเติมที่ระบุชื่อ VibeSolo เป็นมุมมองของกองบรรณาธิการ
