AI Agent ควรมีสิทธิ์แค่ไหน? โจทย์ใหม่ที่องค์กรไม่อยากเจอที่สุด แต่หลบไม่พ้น

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

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

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

ไม่มีใครตอบได้

เบื้องหลังเหตุการณ์

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

สามขั้นแรก ปัญหาสิทธิ์ไม่ชัด พอถึงขั้นที่สี่ ธรรมชาติก็เปลี่ยนไปเลย AI Agent กลายเป็น "ผู้กระทำ" ที่ปฏิบัติการกับระบบของบริษัท ทั้งที่มันไม่ใช่พนักงาน และไม่ใช่ service account แบบเดิม

service account แบบเดิมมีรูปแบบพฤติกรรมที่ชัดเจนและตายตัว รันแบตช์ทุกตีสาม ทำอะไรเขียนตายตัวในโปรแกรม ส่วน AI Agent ไม่ใช่ มันตัดสินตามอินพุตว่าจะเรียกเครื่องมือไหน แก้ข้อมูลรายการใด พื้นที่พฤติกรรมกว้างจนแจกแจงไม่หมด

นี่แหละคือปัญหา กรอบการกำกับการเข้าถึงเดิมออกแบบมาสำหรับ "โปรแกรมที่พฤติกรรมทำนายได้" และ "คนที่มีต้นทุนทางจิตใจ" Agent ไม่ใช่ทั้งสองอย่าง

ประเด็นสำคัญครั้งนี้

การกำกับการเข้าถึงในยุค Agent ผมคิดว่ามีปัญหาการออกแบบสี่ข้อที่ต้องจัดการ:

• ตัวตนอิสระ: Agent ต้องมีบัญชีและ credential ของตัวเอง ยืมตัวตนพนักงานไม่ได้ นี่คือเงื่อนไขนำหน้าของการควบคุมทุกอย่างที่ตามมา
• สิทธิ์น้อยที่สุดและมีอายุ: ให้เฉพาะสิทธิ์ที่จำเป็นต่อการทำงาน และพยายามให้ credential ชั่วคราวที่มีอายุ ไม่ใช่คีย์ที่ใช้ได้ถาวร
• นำการแบ่งแยกหน้าที่มาใช้กับบัญชีที่ไม่ใช่มนุษย์: Agent หนึ่งไม่ควรมีทั้งสิทธิ์ "สร้าง" และ "อนุมัติ" เรื่องเดียวกัน กฎนี้ควรเข้มกับ Agent มากกว่ากับคนด้วยซ้ำ
• ร่องรอยการตรวจสอบครบถ้วน: ใครทริกเกอร์ อ้างอิงอะไร แก้อะไร มีคนอนุมัติหรือไม่ ข้อที่สี่ถูกลืมบ่อยที่สุด

เครื่องมือที่จัดการสิทธิ์ ERP และการแบ่งแยกหน้าที่ในตลาด (เช่น Pathlock) เดิมออกแบบมาเพื่อคน ตอนนี้กำลังเจอปัญหาเดียวกัน คือคลังกฎ SoD ของมันจะครอบคลุมผู้กระทำที่ไม่ใช่มนุษย์อย่างไร นี่คือช่วงที่ทั้งอุตสาหกรรมยังคลำหาทางอยู่

วิเคราะห์ผลกระทบต่อตลาด

ต่อผู้ใช้ในไทย: การเปลี่ยนแปลงที่พนักงานทั่วไปสัมผัสได้คือ "Agent มักพูดว่าทำไม่ได้" ฟังดูเหมือนฟังก์ชันไม่พอ แต่หลายครั้งเป็นการออกแบบตั้งใจ

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

ต่อการใช้งานในองค์กร: องค์กรในไทยมีจุดอ่อนเชิงโครงสร้างสองข้อที่จะถูกขยายในโจทย์นี้

หนึ่งคือ สิทธิ์มีแต่เพิ่มไม่เคยลดมายาวนาน การจัดการสิทธิ์ของบริษัทส่วนใหญ่คือ "มีความจำเป็นก็เพิ่ม ลาออกค่อยลบ" สะสมมาสิบกว่าปี ลำพังจะเข้าใจสภาพปัจจุบันก็เป็นงานใหญ่แล้ว บนพื้นฐานแบบนี้ยังเพิ่ม Agent เข้าไปอีก เท่ากับสร้างตึกบนฐานรากที่เน่า

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

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

ต่อนักพัฒนา: หลักการออกแบบสามข้อที่ผมคิดว่าควรถือเป็นกฎตายตัว

หนึ่ง สิทธิ์เขียนปิดไว้เป็นค่าเริ่มต้น เวลา Agent ขึ้นทำงานให้แค่สิทธิ์อ่าน ฟังก์ชันเขียนต้องขออนุมัติและประเมินทีละอย่าง เรื่องนี้สวนกับนิสัยการพัฒนาทั่วไป (ให้สิทธิ์เต็มก่อนเพื่อทดสอบง่าย ๆ แล้วค่อยเก็บทีหลัง) แต่สภาพแวดล้อมทดสอบกับโปรดักชันของ Agent มักใช้ข้อมูลร่วมกัน "ค่อยเก็บทีหลัง" มักไม่เกิดขึ้น

สอง การกระทำที่ทำลายล้างต้องให้คนอนุมัติเสมอ ลบ คืนเงิน ส่งอีเมลให้ลูกค้าภายนอก แก้ยอดเงิน การกระทำกลุ่มนี้ควรออกแบบเป็น "Agent เตรียมพร้อม คนกดยืนยัน" นี่ไม่ใช่การไม่เชื่อ AI แต่ต้นทุนความผิดพลาดของสิ่งเหล่านี้ไม่สมมาตร ต้นทุนของการกดยืนยันเพิ่มอีกครั้งต่ำมาก แต่ต้นทุนของการส่งอีเมลผิดให้ลูกค้าสูงมาก

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

แนวโน้มการพัฒนาในอนาคต

ผมคิดว่าจะเกิดสามเรื่อง

หนึ่ง "ตัวตน Agent" จะกลายเป็นประเภทตัวตนอิสระ ระบบจัดการตัวตนปัจจุบันแบ่งเป็น "คน" กับ "service account" สองประเภท Agent ไม่จัดอยู่ในประเภทใดเต็มตัว ผลิตภัณฑ์ IAM ในอนาคตน่าจะมีประเภทตัวตน Agent เฉพาะ ที่มาพร้อมการประกาศวัตถุประสงค์ ขอบเขตพฤติกรรม และวันหมดอายุ

สอง เครื่องมือกำกับการเข้าถึงจะเริ่มนำ Agent เข้าสู่การวิเคราะห์ SoD นี่คือช่องว่างผลิตภัณฑ์ที่ชัดเจนสำหรับผู้ผลิตปัจจุบัน และเป็นโอกาสของสตาร์ทอัพ

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

ขอเสริมข้อสังเกตที่ค่อนข้างสงวนท่าที ปัจจุบันการอภิปรายเรื่องการกำกับ Agent ในตลาดกลิ่นเทคนิคจัดมาก พูดเรื่อง OAuth scope พูดเรื่อง sandbox พูดเรื่อง policy engine แต่สิ่งที่ทำให้องค์กรติดขัดจริงมักเป็นปัญหาที่อยู่ข้างหน้ากว่านั้น คือ ไม่มีใครรู้ว่าในบริษัทมี Agent รันอยู่กี่ตัว นี่คือปัญหาแบบเดียวกับ shadow IT เมื่อสิบปีก่อน วิธีแก้ก็เหมือนกัน คือทำการสำรวจก่อน

บทสรุปและความเห็นจาก TheAI Academy

กลับไปที่ตัวอย่างในไทยตอนต้น สิ่งที่พวกเขาทำในภายหลังง่ายมาก คือเปลี่ยนบัญชีของผู้ช่วยจาก service account ที่ใช้ร่วมกันเป็นบัญชีเฉพาะ เปลี่ยนฟังก์ชันคืนเงินเป็น "ผู้ช่วยเตรียม ฝ่ายบริการลูกค้ายืนยัน" และลงทะเบียน Agent ทั้งหมดในฟอร์มที่ใช้ร่วมกันแผ่นหนึ่ง

ใช้เวลาสองสัปดาห์ ไม่ได้ซื้อเครื่องมือใดเลย

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

คำแนะนำที่เป็นรูปธรรมสำหรับผู้อ่านในไทย สามเรื่องที่ทำได้สัปดาห์หน้า:

หนึ่ง ทำการสำรวจ Agent สักครั้ง ตอนนี้ในบริษัทมี AI Agent รันอยู่กี่ตัว แต่ละตัวใช้บัญชีอะไร ใครรับผิดชอบ ลำพังทำตารางนี้ออกมา บริษัทส่วนใหญ่ก็จะพบว่ามีของหนึ่งสองอย่างที่ไม่มีใครจำได้ยังรันอยู่

สอง เก็บสิทธิ์เขียนกลับมา ให้ขอใหม่ เรื่องนี้จะถูกบ่น แต่คุ้ม พอเก็บกลับมาแล้วคุณจะพบว่าสิทธิ์เขียนของ Agent บางตัวไม่เคยถูกใช้เลย นั่นคือความเสี่ยงล้วน ๆ ที่ไม่มีคุณค่าตอบแทน

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

อ่านต่อ: ก่อนนำ AI Agent มาใช้ ถามก่อนว่าข้อมูลมีกี่เวอร์ชัน พูดถึงการเตรียมด้านข้อมูล, AI เข้าห้องตรวจสอบ พูดถึงเส้นแบ่งของการตรวจสอบอัตโนมัติ, การสังเกตการณ์และการกำกับ AI Agent พูดถึงการมอนิเตอร์หลังขึ้นทำงาน

แหล่งข้อมูล

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• คำอธิบายผลิตภัณฑ์ทางการของ Pathlock

เรียบเรียงจากข้อมูลสาธารณะ อ้างอิงตามแหล่งทางการ บทความนี้เป็นคำแนะนำทั่วไป การออกแบบการควบคุมของแต่ละสภาพแวดล้อมโปรดดำเนินการตามการประเมินความเสี่ยงของตนเอง