การยืนยันตัวตน (Authentication) คือการตรวจสอบว่าคุณคือใคร ส่วนการกำหนดสิทธิ์ (Authorization) คือการตัดสินว่าคุณสามารถทำอะไรได้บ้าง แอปพลิเคชันที่ขับเคลื่อนด้วย AI จำนวนมากขึ้นเรื่อยๆ มักจะยืนยันตัวตนของผู้ใช้เพียงครั้งเดียวตอนเข้าสู่ระบบ จากนั้นก็ปล่อยให้เอเจนต์ (agent) ที่อยู่เบื้องหลังสามารถดำเนินการกับทรัพยากรใดๆ ก็ได้ตลอดช่วงเวลาที่ใช้งาน ซึ่งเปรียบเสมือนการมอบ "เช็คเปล่า" ให้กับมัน การออกแบบเช่นนี้เปิดช่องโหว่ให้เกิดข้อมูลรั่วไหลโดยไม่ตั้งใจ, การส่งอีเมลที่ไม่พึงประสงค์ หรือแม้แต่การอัปเดตฐานข้อมูลที่สร้างความเสียหาย และความเสี่ยงจะเพิ่มขึ้นทุกครั้งที่ผู้ช่วย AI สามารถเรียกใช้เครื่องมือหลายอย่างพร้อมกันด้วยความเร็วในระดับมิลลิวินาที
ทำไมความผิดพลาดนี้จึงยังเกิดขึ้นซ้ำๆ
นักพัฒนา AI ส่วนใหญ่มองว่าหน้าจอเข้าสู่ระบบเป็นประตูรักษาความปลอดภัยเพียงบานเดียว โค้ดจะถามหารหัสผ่านหรือโทเค็น ทำเครื่องหมายว่าเซสชันนั้น "ได้รับการยืนยันตัวตนแล้ว" และจากนั้นก็ทึกทักเอาเองว่าคำขอหลังจากนั้นทั้งหมดจะปลอดภัย ในเว็บแอปพลิเคชันแบบดั้งเดิม การคลิกที่เชื่องช้าของผู้ใช้ที่เป็นมนุษย์จะช่วยชะลอการทำงานโดยธรรมชาติ (natural throttling point) เพราะมนุษย์จะหยุดคิดก่อนที่จะกด "ลบ" แต่สำหรับเอเจนต์ AI นั้นสามารถเรียกใช้เครื่องมือ (tool calls) ได้หลายสิบรายการภายในไม่กี่วินาที หากแพลตฟอร์มถามเพียงแค่ว่า "ผู้ใช้เข้าสู่ระบบแล้วหรือยัง?" ทุกการเรียกใช้ก็จะได้รับสิทธิ์ที่ไม่มีข้อจำกัดเหมือนกันทั้งหมด
สาเหตุหลักคือความสะดวกสบาย ทีมงานมักจะจัดเตรียมบัญชีบริการ (service account) ที่มีอายุการใช้งานยาวนานเพียงบัญชีเดียวสำหรับทั้งแอปพลิเคชัน เพื่อที่โค้ดจะได้ไม่ต้องจัดการกับโทเค็นหรือขอบเขตสิทธิ์ (scopes) หลายตัว บัญชีดังกล่าวมักจะมีสิทธิ์ที่กว้างขวาง เช่น อ่าน, เขียน, ลบ ในทุกๆ โปรเจกต์ เมื่อผู้ช่วย AI ทำงานภายใต้เซสชันนั้น มันจะได้รับสิทธิ์เหล่านั้นโดยอัตโนมัติ โดยไม่คำนึงว่างานที่กำลังทำอยู่นั้นจำเป็นต้องใช้สิทธิ์เหล่านั้นจริงหรือไม่
สิ่งที่อาจได้รับความเสียหาย
- การเปิดเผยข้อมูล – เอเจนต์ที่สามารถอ่านไฟล์ใดก็ได้หลังจากผู้ใช้เข้าสู่ระบบ อาจดึงเอกสารลับเข้าไปอยู่ในคำตอบที่ถูกแชร์ออกไปนอกองค์กรโดยไม่ตั้งใจ
- การดำเนินการที่ไม่ตั้งใจ – ผู้ช่วย AI ของวิศวกรฝ่ายสนับสนุนอาจรันคำสั่ง SQL query ต่อฐานข้อมูลจริง (production) เพียงเพราะเซสชันของวิศวกรยังคงทำงานอยู่ แม้ว่าคำสั่งนั้นจะไม่เกี่ยวข้องกับตั๋ว (ticket) ที่กำลังจัดการอยู่ก็ตาม
- การปฏิบัติตามกฎระเบียบ – กฎการคุ้มครองข้อมูลหลายฉบับกำหนดให้การเข้าถึงข้อมูลต้องจำกัดอยู่เพียงเท่าที่จำเป็นเท่านั้น โมเดลการให้สิทธิ์แบบเหมาเข่ง (blanket permission model) อาจละเมิดหลักการเหล่านี้ และนำไปสู่การตรวจสอบหรือการถูกปรับได้
- ต้นทุนการดำเนินงาน – ความผิดพลาดที่ลบหรือแก้ไขข้อมูลทำให้ทีมต้องย้อนกลับการเปลี่ยนแปลง (roll back), ตรวจสอบหาสาเหตุ และสร้างความเชื่อมั่นกับผู้ใช้ใหม่ ซึ่งทั้งหมดนี้เป็นการสิ้นเปลืองทั้งเวลาและเงินทอง
ขั้นตอนที่ขาดหายไป: การกำหนดสิทธิ์ตามการกระทำ (per-action authorization)
การกำหนดสิทธิ์ควรได้รับการประเมินที่ "ประตู" ทุกบานภายในระบบ ไม่ใช่แค่ที่ประตูทางเข้าหลัก คำถามจะเปลี่ยนจาก "นี่คือใคร?" เป็น "การกระทำเฉพาะเจาะจงนี้บนทรัพยากรเฉพาะเจาะจงนี้ สามารถทำได้ในตอนนี้หรือไม่?" การนำการตรวจสอบนี้มาใช้ไม่จำเป็นต้องออกแบบระบบใหม่ทั้งหมด เพียงแค่ต้องเปลี่ยนจากการใช้แฟล็กเซสชัน (session flag) เพียงตัวเดียว มาเป็นการใช้โทเค็นที่มีขอบเขตและมีอายุการใช้งานสั้น (short-lived, scoped tokens) แทน
วิธีการทำงานในทางปฏิบัติ
- ขอโทเค็นที่มีการกำหนดขอบเขต (scope) ที่ชัดเจน – เมื่อเอเจนต์ AI จำเป็นต้องเรียกใช้เครื่องมือ มันจะต้องขอโทเค็นที่ระบุสิทธิ์ที่จำเป็นต้องใช้พอดี (เช่น
read:ticket,execute:sql_query) - ตรวจสอบความถูกต้องของโทเค็นในทุกการเรียกใช้ – ก่อนที่เครื่องมือจะทำงาน บริการจะตรวจสอบว่าโทเค็นนั้นมีขอบเขตที่ต้องการและโทเค็นยังไม่หมดอายุ
- จับคู่ทรัพยากรกับขอบเขตสิทธิ์ – หากคำขอพุ่งเป้าไปที่โปรเจกต์หรือฐานข้อมูลเฉพาะ โทเค็นจะต้องได้รับอนุญาตให้เข้าถึงตัวระบุ (identifier) นั้นอย่างชัดเจน
- ปฏิเสธหรืออนุญาต – หากการตรวจสอบใดล้มเหลว การเรียกใช้นั้นจะถูกปฏิเสธ และเอเจนต์จะได้รับข้อผิดพลาดเพื่อแจ้งให้ผู้ใช้ทราบ
ความแตกต่างของโค้ดนั้นตรงไปตรงมา แนวทางที่ "ไม่ดี" อาจเป็นดังนี้:
if session.is_authenticated():
tool.run(params)
แนวทางที่ "ดี" จะขยายการตรวจสอบออกไป:
token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
tool.run(params)
else:
raise PermissionError
รูปแบบที่สองเพิ่มโค้ดขึ้นเพียงไม่กี่บรรทัด แต่บังคับให้ระบบต้องถามคำถามที่ถูกต้องสำหรับการทำงานทุกครั้ง
มาตรฐานที่ช่วยให้ง่ายขึ้น
OAuth 2.0 scopes เป็นวิธีที่ได้รับการยอมรับอย่างแพร่หลายในการจำกัดสิ่งที่โทเค็นสามารถทำได้ การออก access tokens ที่มีอายุการใช้งานสั้นและเข้ารหัสขอบเขตสิทธิ์ เช่น project:1234:write หรือ email:send จะช่วยให้นักพัฒนาสามารถใช้ไลบรารีที่มีอยู่แล้วในการดำเนินการขั้นตอนการตรวจสอบได้
Rich Authorization Requests (RFC 9396) ที่ใหม่กว่าได้ต่อยอดแนวคิดนี้ โดยอนุญาตให้ไคลเอนต์ (client) สามารถขอสิทธิ์ที่ละเอียด (granular permissions) ได้ในขณะรันไทม์ (runtime) แทนที่จะต้องกำหนดรายการแบบคงที่ไว้ล่วงหน้า ความยืดหยุ่นนี้มีประโยชน์มากเมื่อเวิร์กโฟลว์ของ AI อาจจำเป็นต้องเพิ่มหรือลดความสามารถได้ทันทีตามความต้องการของผู้ใช้
ข้อโต้แย้ง: ความเรียบง่ายเทียบกับความปลอดภัย
บางทีมโต้แย้งว่าการตรวจสอบในแต่ละการกระทำ (per-action checks) เพิ่มความหน่วง (latency) และความซับซ้อนของโค้ด โดยเฉพาะอย่างยิ่งเมื่อผู้ช่วย AI ต้องเรียกใช้เครื่องมือหลายอย่างอย่างต่อเนื่องและรวดเร็ว พวกเขาชี้ให้เห็นว่าการใช้ session token เพียงอันเดียวช่วยหลีกเลี่ยงภาระ (overhead) ในการดึงและตรวจสอบความถูกต้องของโทเคนใหม่ในทุกๆ การเรียกใช้งาน อย่างไรก็ตาม สิ่งที่ต้องแลกมาคือความเสี่ยงต่อการใช้งานในทางที่ผิดที่เพิ่มสูงขึ้นอย่างมาก บริการตรวจสอบความถูกต้องของโทเคนในปัจจุบันถูกออกแบบมาให้ทำงานในระดับไมโครวินาที และการรับส่งข้อมูลผ่านเครือข่าย (network round-trip) ที่เพิ่มขึ้นมานั้นสามารถทำแบบรวมกลุ่ม (batching) หรือทำแคช (caching) ได้ โดยไม่สูญเสียหลักการสิทธิ์ขั้นต่ำที่จำเป็น (principle of least privilege) ในสภาพแวดล้อมที่ความถูกต้องของข้อมูล (data integrity) และการปฏิบัติตามกฎระเบียบ (compliance) เป็นเรื่องที่ต่อรองไม่ได้ ต้นทุนด้านประสิทธิภาพที่เพิ่มขึ้นเพียงเล็กน้อยนั้นถือว่าคุ้มค่าเมื่อเทียบกับการลดความเสี่ยงที่เกิดขึ้น
สิ่งที่ควรจับตามองต่อไป
- การนำ scoped tokens มาใช้ใน AI SDKs – คอยติดตามการอัปเดตชุดเครื่องมือ (toolkits) ของแพลตฟอร์ม AI รายใหญ่ ซึ่งหลายแห่งเริ่มเปิดให้ใช้งานฟังก์ชันช่วยเหลือ (helper functions) สำหรับขอบเขตการเข้าถึง (scopes) ที่อิงตาม OAuth แล้ว
- เฟรมเวิร์กแบบ Policy-as-code – โซลูชันที่กำลังเกิดขึ้นใหม่ช่วยให้ทีมสามารถประกาศกฎการอนุญาตสิทธิ์ (authorization rules) ในไฟล์แบบ declarative ซึ่งจะบังคับใช้กฎเหล่านั้นโดยอัตโนมัติในขณะรันไทม์ (runtime)
- บันทึกการตรวจสอบ (Audit logs) ที่แสดงการตัดสินใจในแต่ละการกระทำ – เมื่อแพลตฟอร์มต่างๆ เริ่มบันทึกการตรวจสอบสิทธิ์ในแต่ละครั้งมากขึ้น องค์กรจะสามารถมองเห็นภาพรวมได้ว่าการกระทำใดของ AI ที่ได้รับอนุญาตหรือถูกบล็อก ซึ่งจะช่วยเป็นข้อมูลในการปรับปรุงนโยบายในอนาคต
บทสรุป
การปฏิบัติกับเซสชันที่ล็อกอินอยู่เสมือนว่าเป็นสิทธิ์ในการทำทุกอย่าง คือสูตรสำเร็จที่นำไปสู่ผลลัพธ์ที่ไม่พึงประสงค์ ด้วยการย้ายการตัดสินใจอนุญาตสิทธิ์จากช่วงเวลาที่ล็อกอิน ไปเป็นการตรวจสอบในทุกๆ การเรียกใช้เครื่องมือ—และด้วยการใช้ scoped tokens ที่มีอายุสั้น—แอปพลิเคชัน AI จะสามารถรักษาความสะดวกสบายของเอเจนต์อัตโนมัติ (autonomous agents) ไว้ได้ ในขณะที่ยังสามารถปกป้องข้อมูล ปฏิบัติตามกฎระเบียบ และหลีกเลี่ยงความผิดพลาดที่มีมูลค่าความเสียหายสูง โค้ดที่เพิ่มขึ้นมาไม่กี่บรรทัดถือเป็นราคาที่ถูกมากสำหรับระบบที่รู้จักตั้งคำถามที่ถูกต้องในทุกครั้งที่มีการพยายามดำเนินการใดๆ