AI Agent ที่เข้าถึงอีเมล เอกสาร ระบบลูกค้า และข้อมูลธุรกิจได้ กำลังเป็นภาพที่หลายบริษัทอยากไปให้ถึง แต่คำถามที่สำคัญกว่าคือ ถ้า Agent ทำงานด้วยสิทธิ์เดียวกับพนักงาน เราจะยังรู้ได้หรือไม่ว่าใครทำอะไร และข้อมูลสำคัญกำลังไหลออกไปทางไหน
คลิปจากช่อง AI Engineer ที่ Shu Fang จาก Two Sigma นำเสนอ Tethered: Our Agents Are Us เล่าการออกแบบให้ agent ทำงานผ่าน identity ของผู้ใช้ พร้อมการตรวจย้อนหลังและการควบคุมทางออกเว็บ บทความนี้สรุปสิ่งที่ผู้พูดเล่า ส่วนข้อเสนอสำหรับธุรกิจไทยเป็นการประยุกต์ทางบรรณาธิการ ไม่ใช่ผลทดสอบความปลอดภัย
Fang ระบุว่า ในระบบที่เขาเล่า พนักงานทุกคนมี cloud agent และ agent ทำงานผ่าน identity ของเจ้าของงาน เขาย้ำช่วงต้นว่ามุมมองในคลิปเป็นของเขาและไม่จำเป็นต้องเป็นมุมมองของบริษัท จึงควรอ่านเป็นกรณีศึกษาจากผู้พูด ไม่ใช่คำรับรองหรือคำแนะนำทางการของ Two Sigma
วิดีโอเผยแพร่วันที่ 3 กันยายน 2026 เวลา 21:30:21 น. ตามเวลาไทย (14:30:21 UTC) วันที่นี้เป็นวันเผยแพร่วิดีโอ ไม่ใช่วันที่จัดงานบรรยาย ดูวิดีโอต้นทาง
เปลี่ยนคำถามจาก “จะใช้ Agent ไหม” เป็น “จะผูก Agent กับใคร”
ผู้พูดใช้คำว่า tethered เป็นอุปมาของ agent ที่ผูกอยู่กับระบบกำกับดูแล ต่างจากการปล่อยให้เข้าถึงหรือส่งข้อมูลโดยไม่กำหนดเส้นทางและร่องรอยให้ตรวจได้
Fang เล่าว่าทีมต้องการให้คนเรียกใช้ agent จาก browser, Slack หรือมือถือได้ และรันงานระยะไกล แทนการจำกัดอยู่ที่ command line บนเครื่องส่วนตัว เพราะผู้ใช้บางคนไม่สะดวกกับ CLI
ตัวอย่างการประยุกต์กับธุรกิจไทยคือเริ่มจากงานสรุปประชุม ค้นเอกสารภายใน หรือร่างคำตอบลูกค้า พร้อมระบุว่า agent ทำงานแทนใคร ใช้ข้อมูลชุดใด และมีสิทธิ์ทำอะไรบ้าง
เปรียบเทียบต้นทุนการดูแล identity ของ agent
ทางเลือกหนึ่งคือสร้าง machine identity แยกจากผู้ใช้ เช่น “เอมี” และ “เอมี Agent” Fang เล่าว่าทีมพบภาระการดูแลรูปแบบนี้เมื่อขยายใช้งาน จึงเลือกให้ agent รันผ่าน identity ของผู้ใช้ในระบบของตน ข้อนี้ไม่ได้หมายความว่า service account ใช้ไม่ได้ในทุกองค์กร
ปัญหาที่ผู้พูดยกขึ้นมา ได้แก่
- สิทธิ์ของพนักงานกับ Agent ค่อยๆ ไม่ตรงกัน เมื่อมีการย้ายทีม เปลี่ยนบทบาท หรือเพิ่มสิทธิ์ใหม่
- ต้องบริหาร license สองชุด ทั้งของคนและของ Agent
- ระบบบางตัวไม่รองรับหลาย identity ที่ต้องแตะข้อมูลชุดเดียวกัน เช่น อีเมลและเครื่องมือทำงานร่วมกัน
- เกิดเส้นแบ่งใหม่ระหว่างข้อมูลส่วนบุคคล ข้อมูลทีม และข้อมูลที่ Agent เข้าได้ ซึ่งไม่มีใครอยากเป็นคนดูแลตลอดเวลา
แนวทางที่ Fang เล่าคือใช้ identity ของผู้ใช้เดิมเพื่อลดภาระการซิงก์สิทธิ์และการเข้าถึงระบบ แต่เมื่อคนกับ agent ใช้ identity เดียวกัน ก็ต้องมีวิธีระบุการกระทำและตรวจย้อนหลังควบคู่กัน
เมื่อนำไปประยุกต์ ควรเลือกวิธีผูก identity และขอบเขตสิทธิ์ให้เหมาะกับงาน สำหรับการโอนเงิน เปลี่ยนข้อมูลลูกค้า หรือลบข้อมูล อาจกำหนดจุดอนุมัติของคนตามนโยบายองค์กร ก่อนขยายจากงานอ่านและร่างไปสู่การลงมือจริง
ใช้ infrastructure ที่มีอยู่แล้ว แทนการสร้างระบบใหม่ทั้งหมด
ตามคำอธิบายของ Fang องค์กรมี Kubernetes namespace สำหรับพนักงานแต่ละคนในแต่ละ region อยู่แล้ว ใช้กับงานอัตโนมัติ container และ research notebook ที่ไม่เหมาะจะรันเฉพาะบนเครื่องส่วนตัว จึงนำโครงสร้างเดิมมาใช้กับ cloud agent
เขาอธิบาย flow โดยย่อว่า trigger ส่งคำขอไปยัง controller เพื่อสร้าง compute จากนั้น sidecar ใน pod ดึง identity จาก identity service ให้ container รันเป็นผู้ใช้ เป็นคำอธิบาย architecture ในคลิป ไม่ใช่ขั้นตอนติดตั้งที่บทความนี้ได้ทดลอง
เมื่อนำหลักคิดนี้มาใช้ อาจสำรวจระบบเดิมก่อน เช่น ระบบเอกสาร CRM และการกำหนดสิทธิ์ของทีม แล้วดูว่ารองรับ workflow ที่ต้องการอย่างไร ไม่จำเป็นต้องใช้ Kubernetes ตามกรณีนี้
ข้อเสนอทางบรรณาธิการคือทำแผนที่ว่าแต่ละงานใช้ระบบใด มีข้อมูลประเภทไหน และใครเป็นเจ้าของสิทธิ์ แล้วตรวจข้อจำกัดก่อนเลือก platform เพิ่ม
แยกให้ได้ว่า “คนทำ” หรือ “Agent ทำ” ด้วย trace ที่ต่อเนื่อง
เมื่อ Agent ใช้ identity เดียวกับคน ปัญหาใหญ่คือ audit log ปกติอาจบอกได้เพียงว่า “เอมีเข้าถึงเอกสารนี้” แต่บอกไม่ได้ว่าเอมีเป็นคนกดเอง หรือ Agent ทำตาม workflow ที่เอมีเริ่มไว้
Fang เล่าว่าใช้ header สำหรับระบุ agent และให้ข้อมูลนี้ถูกส่งต่อไปตามขั้นตอน คล้าย trace ID ในระบบ observability เพื่อแยก human action จาก agent action และเชื่อมเหตุการณ์ข้ามระบบ
ตามที่ผู้พูดอธิบาย การส่ง header ต่อเนื่องช่วยย้อน chain ของ action กลับไปยังจุดเริ่มต้นได้ ในช่วงถามตอบเขาระบุด้วยว่า header ไม่ใช่การยืนยันตัวตนในตัวมันเอง ยังต้องตรวจ identity ต้นทางควบคู่กัน การมี tag เพียงอย่างเดียวจึงไม่รับรองว่า attribution จะถูกต้อง
ตัวอย่างการประยุกต์คือเก็บผู้เริ่มงาน เวลา เป้าหมาย แหล่งข้อมูล และ action สำคัญ พร้อมทดลองย้อนรอยจากผลลัพธ์กลับไปยังคำสั่งเริ่มต้น หากใช้ platform สำเร็จรูป อาจตรวจว่าส่งออก audit log และแยก human/agent action ได้เพียงใด
ในช่วงถามตอบ Fang เล่าว่าข้อมูล session บางส่วนจำกัดผู้เข้าถึง เพราะอาจมีข้อมูลละเอียดอ่อน และทีมใช้ข้อมูลการใช้งานเพื่อปรับการตั้งค่า agent ในมุมการประยุกต์จึงควรระบุทั้งสิ่งที่จะบันทึกและผู้ที่เข้าถึงบันทึกได้
ปิดทางออกสู่เว็บโดยตรง แล้วสร้างเส้นทางค้นหาที่ควบคุมได้
Fang ระบุความเสี่ยงของการเปิด web search และ web fetch โดยตรงไว้หลายด้าน ได้แก่
- ข้อมูลรั่วไหล: Agent อาจส่งข้อมูลภายในหรือทรัพย์สินทางปัญญาออกไปยังปลายทางที่ไม่ควรเข้าถึง
- Prompt injection: หน้าเว็บหรือเอกสารภายนอกอาจมีข้อความหลอกให้ Agent เปลี่ยนเป้าหมาย หรือพยายามขอข้อมูลเพิ่ม
- เนื้อหาที่ไม่มีสิทธิ์ใช้: ข้อมูลจากเว็บอาจมีเงื่อนไขลิขสิทธิ์หรือ license ที่ไม่ตรงกับการนำมาใช้เชิงพาณิชย์
ผู้พูดเล่าว่าเลือกใช้ web grounding for enterprise ของ Google Cloud สำหรับ search และ fetch ผ่านดัชนีเว็บภายใน network boundary ที่องค์กรควบคุม เขาอธิบายการออกแบบที่ทีมเลือก ไม่ใช่ผลตรวจ vendor documentation หรือการรับรองผลิตภัณฑ์ปัจจุบันโดยบทความนี้
Fang บอกว่า ตอนที่เขาตรวจล่าสุด ข้อมูลในดัชนีสดภายในประมาณ 24 ชั่วโมง และเว็บไซต์ที่อัปเดตบ่อยภายในประมาณ 6 ชั่วโมง ตัวเลขนี้เป็นสิ่งที่เขารายงานในคลิป ไม่ใช่ SLA หรือข้อมูลผลิตภัณฑ์ที่ตรวจสอบใหม่ ทีมที่ใช้ต้องทดสอบความสดให้ตรงกับงานของตน
นอกจากเส้นทางดัชนี เขาเล่าว่าปิดทั้งการออกเว็บโดยตรงและ native web search/web fetch ของ agent แล้วให้ใช้เส้นทางที่กำหนดผ่าน MCP, CLI, client code หรือ skills ในช่วงถามตอบเขายอมรับด้วยว่าการคัดเนื้อหาอาจผิดพลาดได้ จึงไม่ควรถือว่าดัชนีภายในกำจัด prompt injection หรือความเสี่ยงอื่นทั้งหมด
วัดผลแบบความคุ้มค่าต่อความเสี่ยง ไม่ใช่วัดแค่ความฉลาดของ Agent
ผู้พูดใช้กรอบ risk และ return เพื่ออธิบายเป้าหมายว่าอยากรักษาคุณค่าของการให้ agent ทำงานผ่านสิทธิ์ผู้ใช้ พร้อมลดความเสี่ยงจากการกระทำและข้อมูลภายนอก กรอบนี้เป็นวิธีอธิบาย trade-off ไม่ใช่คะแนนความปลอดภัยที่วัดไว้
Fang ประเมินว่าทีมยังรักษาคุณค่าที่คาดหวังไว้ได้ ขณะที่ได้ observability มากขึ้นและลดความเสี่ยงบางด้าน แม้ดัชนีเว็บจะล่าช้า นี่เป็นข้อประเมินของผู้พูดในระบบที่เขาเล่า ไม่มีตัวเลขเปรียบเทียบที่บทความนี้ตรวจยืนยันอิสระ
ตัวอย่างสมมติสำหรับทีมคือแยกการร่างอีเมลจากการเปลี่ยนราคาใน ERP แล้วกำหนดสิทธิ์และจุดอนุมัติตามผลกระทบของแต่ละงาน แทนการใช้ policy เดียวกับทุก workflow
ข้อจำกัดที่ต้องยอมรับ
กรณีที่ Fang เล่าอาศัย infrastructure, identity service และระบบควบคุมขององค์กร การประยุกต์กับทีมขนาดเล็กจึงต้องตรวจว่ามีองค์ประกอบใดรองรับแล้ว และส่วนใดยังขาด ไม่ควรคาดการณ์ว่าจะได้ผลเหมือนกันจากชื่อเครื่องมือเพียงอย่างเดียว
อาจเริ่มจาก use case แคบ ให้ agent อ่านและเสนอแนะ เก็บร่องรอยงาน และตรวจวิธีอนุมัติก่อนเปิด action เพิ่ม เมื่อ workflow จะขยายเป็นระบบกลาง ผู้พูดระบุในช่วงถามตอบว่าต้องพิจารณา production support และ security เหมือน application อื่นขององค์กร
มุมมองส่วนตัวเรื่อง model ที่องค์กรดูแลเอง
ในช่วงถามตอบ Fang มองเป็นการส่วนตัวว่า model ที่องค์กรจัดการเองอาจเป็นทางเลือกระยะยาวสำหรับ inference บางส่วน เพราะต้นทุน การเลิกให้บริการ และความผันผวนเมื่อ model เปลี่ยน เขาย้ำว่าข้อนี้ไม่ใช่มุมมองของบริษัท จึงไม่ได้เป็นการประกาศ roadmap ของ Two Sigma หรือคำรับรองว่าจะลดต้นทุนได้
