ความหมายของอำนาจที่มอบหมาย
อำนาจที่มอบหมายคือการอนุญาตที่บุคคล (หรือองค์กร) ให้แก่ AI agent เพื่อกระทำการแทนตน เมื่อผู้ช่วยจองการประชุมในปฏิทินของคุณ ยื่น ticket ขอรับการสนับสนุนในนามของคุณ หรือดึงใบแจ้งหนี้จากพอร์ทัลของผู้ให้บริการ นั่นคือการใช้อำนาจที่เริ่มต้นจากคุณ
การมอบหมายที่ดีมี 3 คุณลักษณะ คือ มีขอบเขต (agent ทำได้บางอย่าง ไม่ใช่ทุกอย่าง), จำกัดเวลา (หมดอายุหรือเพิกถอนได้) และ ระบุที่มาได้ (แอปที่รับเรื่องสามารถบอกได้ว่าใช้อำนาจของใคร)
เหตุผลที่เรื่องนี้สำคัญสำหรับแอป
จากมุมมองของแอป คำขอจาก agent ทำให้เกิดคำถามแยกกัน 3 ข้อ:
- ไคลเอนต์ใดเป็นผู้ส่งสิ่งนี้? นั่นคือตัวตนของ agent ซึ่งคำขอที่ลงนามสามารถยืนยันได้ (ดู HTTP Message Signatures)
- กำลังใช้อำนาจของใครอยู่? นั่นคือการมอบหมาย
- อำนาจนั้นเพียงพอสำหรับการกระทำนี้หรือไม่? นั่นคือ authorization ซึ่งตัดสินโดยนโยบายของแอปเอง
คำขอที่ลงนามจากผู้ให้บริการผู้ช่วยที่เป็นที่รู้จักสามารถตอบคำถามแรกได้ดี แต่มันไม่ได้บอกอะไรเกี่ยวกับคำถามที่สองด้วยตัวมันเอง ผู้ช่วยอาจกำลังทำงานให้กับผู้ใช้คนหนึ่งของคุณ ให้กับคนที่ไม่ใช่ผู้ใช้ของคุณ หรือทำตามการตัดสินใจของตัวเองล้วน ๆ การถือว่าตัวตนของไคลเอนต์คือหลักฐานว่าบุคคลนั้นยินยอม เป็นหนึ่งในความผิดพลาดที่พบบ่อยที่สุดในการออกแบบระบบที่ทำงานกับ agent ดู สิ่งที่คำขอจาก AI agent ที่ลงนามพิสูจน์ได้ และสิ่งที่พิสูจน์ไม่ได้
การแสดงการมอบหมายที่พบบ่อย
- การมอบสิทธิ์แบบ OAuth บุคคลลงชื่อเข้าใช้แอปของคุณและมอบ token ให้ agent พร้อม scope ที่จำกัด ตามที่กำหนดไว้ใน OAuth 2.0 (RFC 6749) จากนั้นแอปของคุณจะรู้ชัดเจนว่า token นั้นถืออำนาจของใคร และสามารถเพิกถอนการมอบสิทธิ์นั้นได้ (RFC 7009)
- API keys ที่ผูกกับบัญชี ซึ่งผู้ใช้สร้างขึ้นสำหรับการเชื่อมต่อเฉพาะ โดยควรมีสิทธิ์แคบที่สุดเท่าที่จำเป็น
- การยืนยันในแอป สำหรับการกระทำที่มีผลกระทบสูง ซึ่งบุคคลอนุมัติการกระทำเฉพาะที่ agent เตรียมไว้
- การอ้างสิทธิ์การมอบหมายระดับ token OAuth 2.0 Token Exchange (RFC 8693) กำหนด
act(actor) claim สำหรับบันทึกว่าฝ่ายหนึ่งทำงานแทนอีกฝ่าย งานใหม่ ๆ ที่เกี่ยวกับการแสดงการมอบหมายของ agent ในคำขอยังคงพัฒนาอยู่ และแอปควรตรวจสอบ delegation claim ใด ๆ เทียบกับบันทึกของตนเอง แทนที่จะยอมรับตามหน้าตา
ความเข้าใจผิดที่พบบ่อย
- "ถ้า agent ผ่านการยืนยันแล้ว แปลว่าผู้ใช้อนุมัติแล้ว" การยืนยันระบุตัวไคลเอนต์ ส่วนการอนุมัติต้องมาจากบุคคล ผ่านช่องทางที่แอปของคุณเชื่อถือ
- "agent ใช้ session ของผู้ใช้ฉันก็โอเค" อาจจะใช่ แต่ session นั้นถูกออกให้สำหรับการใช้งานแบบโต้ตอบโดยมนุษย์ หลายแอปจึงชอบใช้การมอบสิทธิ์เฉพาะที่มีขอบเขตสำหรับงานอัตโนมัติ เพื่อให้การกระทำระบุที่มาได้และเพิกถอนได้
- "การมอบหมายมีแค่ทั้งหมดหรือไม่ก็ไม่มีเลย" การมอบหมายที่ปลอดภัยที่สุดคือแบบแคบ: ให้สิทธิ์อ่านได้กว้าง แต่ให้สิทธิ์เขียนเฉพาะการกระทำที่กำหนด และให้ยืนยันสำหรับสิ่งที่ย้อนกลับไม่ได้
Proof of Actor เกี่ยวข้องอย่างไร
Proof of Actor ช่วยให้คุณเห็นว่าเมื่อใดปฏิสัมพันธ์ขับเคลื่อนโดย agent หรือได้รับความช่วยเหลือจาก AI และบนพื้นฐานใด: verified, declared, inferred หรือ unknown บริบทนั้นจะบอกคุณว่าคำถามเรื่องการมอบหมายเกิดขึ้นที่ใด เช่น autonomous agent ที่ทำงานภายใน session ของบัญชีมนุษย์ Proof of Actor ไม่ได้ออกหรือยืนยันข้อมูลรับรองการมอบหมาย และผลลัพธ์แบบ Agent ไม่ได้หมายความว่าบุคคลได้อนุญาตการกระทำนั้น แอปของคุณเองต่างหากที่กำหนดผ่าน grants, scope และการยืนยัน และ Route ช่วยให้คุณใช้นโยบายที่เหมาะสมต่อแต่ละ route ได้ เมื่อคุณได้สังเกตทราฟฟิกจริงแล้ว สำหรับรูปแบบนโยบาย ดู การออกแบบนโยบายระดับแอปสำหรับมนุษย์และ AI agent
อ่าน สิ่งที่หลักฐานสามารถและไม่สามารถยืนยันได้ หรือ สมัครเข้าถึงก่อนใคร
แหล่งอ้างอิง
- RFC 6749: The OAuth 2.0 Authorization Framework: การมอบสิทธิ์แบบมีขอบเขตจาก resource owner ไปยัง client
- RFC 7009: OAuth 2.0 Token Revocation: การเพิกถอน token ที่มอบหมาย
- RFC 8693: OAuth 2.0 Token Exchange:
act(actor) claim สำหรับการมอบหมาย