ตัวตน สิทธิ์ และบันทึกตรวจสอบของ AI Agent: ชั้นความปลอดภัยที่มือถือ Agent ต้องมี

ทำไมตัวตนของ AI Agent ต้องชัดก่อนลงมือ

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

ตัวตนของ AI Agent บนมือถือไม่ควรเป็นเพียงชื่อในหน้าจอสนทนา แต่ควรเป็นตัวตนที่ระบบใช้แยกจากผู้ใช้ แอป และบริการอื่น เมื่อ agent ขออ่านแจ้งเตือน ร่างข้อความ หรือเปิดแอปที่รองรับ ระบบควรรู้ว่านี่คือการกระทำของ agent ใด ภายใต้สิทธิ์ใด และได้รับคำสั่งจากผู้ใช้คนใด งานวิจัยด้านระบบ agent หลายชิ้น เช่น Auditable Agents และงานเกี่ยวกับการจัดการตัวตนของผู้กระทำที่ไม่ใช่มนุษย์ ชี้ไปในทิศทางเดียวกันว่า accountability ต้องเริ่มจากการระบุผู้กระทำให้ได้

ในมุมของเรา เราจึงไม่ออกแบบ FoneClaw ให้การกระทำของ agent กลืนหายไปกับการแตะหน้าจอทั่วไป เราออกแบบโดยถือว่างาน Android ที่รองรับต้องมีจุดเริ่มจากเจตนาของผู้ใช้ มีขอบเขตที่ระบบเข้าใจ และมีผลลัพธ์ที่ตรวจทานได้ เราไม่ได้อ้างว่า FoneClaw เป็นระบบตัวตนองค์กรหรือ compliance platform แต่สำหรับ phone agent การแยกว่าการกระทำนั้นเกิดจากผู้ใช้โดยตรงหรือเกิดผ่าน agent เป็นฐานความปลอดภัยที่ละเลยไม่ได้

สิทธิ์ควรผูกกับงาน เวลา และบริบท

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

งานวิจัยเรื่อง Authorization Propagation in Multi-Agent AI Systems วางกรอบว่าระบบที่มีผู้กระทำที่ไม่ใช่มนุษย์ต้องคิดเรื่องการมอบสิทธิ์ การส่งต่อสิทธิ์ และเวลาที่สิทธิ์ยังใช้ได้ แม้บริบทของงานวิจัยจะกว้างกว่าโทรศัพท์ แต่บทเรียนตรงกับ phone agent มาก ถ้า agent ได้สิทธิ์อ่านข้อความเพื่อสรุปประชุม สิทธิ์นั้นไม่ควรถูกนำไปใช้ส่งไฟล์ส่วนตัวในอีกแอปหนึ่งโดยอัตโนมัติ และไม่ควรคงอยู่ตลอดไปหลังงานจบ

สำหรับ FoneClaw เราใช้หลักคิดนี้กับงานที่รองรับบน Android: ขอสิทธิ์เท่าที่จำเป็น บอกให้ผู้ใช้เห็นว่าใช้เพื่ออะไร และหยุดให้ยืนยันเมื่อผลลัพธ์มีความเสี่ยง เช่น การส่งข้อความ แชร์ข้อมูล หรือเปลี่ยนการตั้งค่าที่กระทบผู้ใช้ หากต้องการลงลึกเรื่องบันทึกสิทธิ์และการกำกับดูแลในบริบทครอบครัว บทความ บันทึกสิทธิ์และการควบคุม AI Agent ขยายประเด็นนี้โดยไม่ต้องซ้ำรายละเอียดทั้งหมดในหน้านี้

บันทึกตรวจสอบทำให้งานบนมือถือมีหลักฐาน

บันทึกตรวจสอบหรือ audit trail ของ AI Agent ไม่ใช่เรื่องสำหรับองค์กรเท่านั้น บนโทรศัพท์ส่วนตัวก็สำคัญไม่แพ้กัน เพราะงานมือถือจำนวนมากมีผลทันที: ส่งข้อความแล้วอีกฝ่ายเห็น เปิดเผยไฟล์แล้วเรียกคืนยาก เปลี่ยนการตั้งค่าแล้วทำให้แจ้งเตือนหาย หรือยืนยันบางอย่างโดยไม่ตั้งใจ ถ้าไม่มีบันทึก ผู้ใช้จะเหลือแค่ความรู้สึกว่า AI ทำอะไรบางอย่าง แต่ไม่รู้แน่ชัดว่าเกิดขึ้นตอนไหน

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

สำหรับ phone agent บันทึกไม่ควรยาวจนผู้ใช้ไม่อ่าน แต่ต้องพอให้ตรวจสอบได้ เช่น สรุปงานที่ทำ เวลา แอปที่เกี่ยวข้อง และสถานะการยืนยัน เรามองว่าสิ่งนี้เป็นส่วนหนึ่งของประสบการณ์ผู้ใช้ ไม่ใช่ไฟล์เทคนิคหลังบ้าน สำหรับความเสี่ยงเชิงเหตุการณ์ เช่น agent ถูกใช้ผิดทางหรือมีการทำงานเกินขอบเขต บทความ ขอบเขตสิทธิ์ของ phone agent ช่วยอธิบายว่าทำไมบันทึกและสิทธิ์ที่จำกัดจึงเป็นแนวป้องกันที่ต้องมี

ทำไม guardrails อย่างเดียวไม่พอสำหรับการอนุญาต

หลายระบบเริ่มจากการเขียนกติกาให้โมเดล เช่น ห้ามทำสิ่งอันตราย ห้ามเปิดเผยข้อมูลส่วนตัว หรือให้ถามผู้ใช้ก่อนทำงานสำคัญ กติกาเหล่านี้มีประโยชน์ แต่ไม่ควรถูกใช้แทนระบบอนุญาตจริง เพราะ prompt เป็นคำสั่งเชิงพฤติกรรม ไม่ใช่กลไกที่ล็อกสิทธิ์ของแอป โทรศัพท์ หรือข้อมูล

ถ้า agent ได้สิทธิ์กว้างเกินไป แล้วมีคำสั่งคลุมเครือหรือข้อมูลบนหน้าจอทำให้เข้าใจผิด guardrails อาจช่วยลดความเสี่ยงบางส่วน แต่ไม่สามารถพิสูจน์ได้เสมอว่าการกระทำนั้นควรได้รับอนุญาตในบริบทนั้น งานวิจัย From Secure Agentic AI to Secure Agentic Web ชี้ว่าระบบ agent ในโลกจริงยังมีโจทย์เปิดเรื่องตัวตน การอนุญาต แหล่งที่มาของข้อมูล และการติดตามเหตุการณ์ สิ่งเหล่านี้เป็นโครงสร้างระบบ ไม่ใช่ข้อความเตือนในโมเดลอย่างเดียว

ดังนั้นในแนวทางของเรา FoneClaw ต้องแยกสองเรื่องให้ชัด: โมเดลช่วยตีความเจตนาได้ แต่สิทธิ์และการยืนยันต้องถูกบังคับในระดับผลิตภัณฑ์ งานที่รองรับบน Android ควรมีขอบเขตชัดเจน ไม่ใช่ให้โมเดลตัดสินเองทั้งหมดว่าอะไรปลอดภัย งานด้านความปลอดภัยของสกิลและสิทธิ์บนโทรศัพท์มีรายละเอียดเพิ่มใน ความปลอดภัยของสกิล AI Agent โดยแกนคิดคือสิทธิ์ต้องถูกตรวจขณะทำงาน ไม่ใช่เดาไว้ล่วงหน้าครั้งเดียว

ผู้ใช้ควรเห็นอะไรก่อน ระหว่าง และหลังการกระทำ

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

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

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

เราใช้แนวคิดนี้กับการทำงาน Android ที่รองรับอย่างไร

เมื่อ FoneClaw ช่วยงาน Android ที่รองรับ เราไม่ได้เริ่มจากความคิดว่า agent ควรทำได้ทุกอย่าง แต่เริ่มจากงานที่ผู้ใช้ต้องการลดการแตะซ้ำและยังตรวจทานได้ เช่น เตรียมข้อความ เปิดแอป สรุปข้อมูลที่อนุญาตให้ดู หรือช่วยจัดลำดับขั้นตอนบนโทรศัพท์ งานเหล่านี้ยังต้องอยู่ภายใต้สิทธิ์ของระบบ Android และการตัดสินใจของผู้ใช้

ในระดับผลิตภัณฑ์ เราต้องการให้แต่ละงานมีตัวตนการทำงานชัดเจน: ผู้ใช้สั่งอะไร FoneClaw เข้าใจเป็นงานใด ต้องใช้สิทธิ์อะไร และจะหยุดให้ยืนยันตรงไหน ตัวอย่างเช่น ถ้าผู้ใช้สั่งให้ร่างข้อความตอบลูกค้า เราสามารถช่วยเตรียมเนื้อหาและเปิดบริบทที่รองรับได้ แต่ก่อนส่งจริงควรให้ผู้ใช้เห็นผู้รับและข้อความเสมอ นี่คือความต่างระหว่างช่วยทำงานกับแย่งสิทธิ์ตัดสินใจ

ข้อจำกัดก็ต้องพูดตรงๆ เราไม่ได้วาง FoneClaw เป็นระบบ IAM ที่รับรอง compliance ครบวงจร ไม่ได้อ้างว่าป้องกันการใช้ AI Agent ผิดทางได้ทั้งหมด และไม่ได้สัญญาว่าควบคุมได้ทุกแอป สิ่งที่เราสามารถรับผิดชอบในฐานะทีมผลิตภัณฑ์คือทำให้การทำงานที่รองรับบน Android มีสิทธิ์ที่มองเห็นได้ มีจุดยืนยัน มีบันทึกตรวจสอบ และมีทางหยุดเมื่อข้อมูลไม่พอหรือผู้ใช้ไม่มั่นใจ

เช็กลิสต์สำหรับ phone agent ที่ปลอดภัยกว่า

ก่อนเชื่อใจ phone agent ให้เริ่มจากคำถามที่จับต้องได้ ไม่ใช่ดูว่าโมเดลตอบเก่งแค่ไหน ถ้า agent แตะข้อความ ไฟล์ แอป หรือการตั้งค่า ควรรู้ว่า agent นั้นมีตัวตนอย่างไร ได้รับสิทธิ์เมื่อใด ใช้สิทธิ์เพื่อทำงานอะไร และผู้ใช้เพิกถอนได้หรือไม่ คำถามเหล่านี้ช่วยเปลี่ยนธรรมาภิบาล Agent จากแนวคิดใหญ่ให้กลายเป็นเกณฑ์เลือกใช้งานจริง

• ตัวตนของ AI Agent แยกจากผู้ใช้และแอปอื่นชัดเจนหรือไม่
• สิทธิ์ของ AI Agent จำกัดตามงาน เวลา และบริบทหรือไม่
• งานอ่อนไหว เช่น ส่งข้อความ แชร์ไฟล์ หรือเปลี่ยนการตั้งค่า มีการยืนยันก่อนทำจริงหรือไม่
• มีบันทึกตรวจสอบที่บอกคำสั่ง สิทธิ์ ขั้นตอน ผลลัพธ์ และเวลาหรือไม่
• ผู้ใช้หยุด ยกเลิก หรือเพิกถอนสิทธิ์ได้ง่ายหรือไม่
• ระบบบอกตรงๆ หรือไม่ว่างานใดไม่รองรับ แทนที่จะเดาทำต่อ

ถ้าคำตอบของข้อเหล่านี้ไม่ชัด อย่ารีบให้ agent แตะข้อมูลสำคัญ แม้ระบบจะมี guardrails หรือคำสัญญาด้านความปลอดภัยก็ตาม งานวิจัยด้าน Security and Privacy in Agentic AI ช่วยย้ำว่าความปลอดภัยและความเป็นส่วนตัวยังเป็นโจทย์ที่กำลังพัฒนา ไม่ใช่ปัญหาที่แก้จบด้วยคำสั่งระบบเพียงชุดเดียว สำหรับ FoneClaw เราใช้เช็กลิสต์นี้เป็นแนวคิดในการออกแบบงาน Android ที่รองรับ: เห็นสิทธิ์ เห็นผลลัพธ์ ยืนยันจุดสำคัญ และตรวจสอบย้อนหลังได้เท่าที่ผลิตภัณฑ์รองรับ