การอนุญาต Agent

Agent authorization หมายถึงอะไร

Agent authorization คือการตัดสินว่า AI agent ได้รับอนุญาตให้ทำอะไรบ้าง: route ใดที่เรียกได้ ข้อมูลใดที่อ่านได้ การกระทำใดที่ทำได้ และในปริมาณเท่าใด โดยแยกจาก agent identity ซึ่งเกี่ยวกับการระบุว่า request นั้นมาจาก agent ใด หรือเป็น agent ของ operator คนใด

ทั้งสองอย่างนี้สับสนกันได้ง่าย เพราะมักมาพร้อมกัน Request ที่ลงนามแล้วบอกได้ว่าใครเป็นผู้ส่ง แต่ไม่ได้บอกว่าผู้ส่งนั้นควรได้รับอนุญาตให้เปลี่ยน account สั่งซื้อ หรือ export data หรือไม่ Identity คือ evidence ส่วน authorization คือ policy บทความของเราเรื่อง สิ่งที่ signed AI agent requests พิสูจน์ได้ และสิ่งที่พิสูจน์ไม่ได้ อธิบายความแตกต่างนี้อย่างละเอียด

เหตุใดความแตกต่างนี้จึงสำคัญ

แอปพลิเคชันส่วนใหญ่แยก authentication ออกจาก authorization สำหรับผู้ใช้ที่เป็นมนุษย์อยู่แล้ว: การล็อกอินพิสูจน์ได้ว่าคุณเป็นใคร ส่วน role และ permission เป็นตัวตัดสินว่าคุณทำอะไรได้บ้าง Agent ก็ต้องมีการแยกแบบเดียวกัน แต่ต้องเพิ่มความระมัดระวังอีกชั้น:

• Identity อาจแข็งแรง แต่ยังไม่มี permission. crawler ที่มี HTTP message signature ที่ถูกต้องทุกประการไม่ได้มีสิทธิ์โดยธรรมชาติในการเรียก write endpoint
• Permission อาจมีอยู่ แม้ identity จะไม่แข็งแรง. agent ที่ใช้ API key ของ customer ได้รับการอนุญาตจาก key นั้น แม้จะไม่มีอะไรระบุว่า software ของ agent ตัวใดกำลังถือ key นั้นอยู่
• คนที่อยู่เบื้องหลัง agent ก็มีความสำคัญ. เมื่อ agent ทำงานแทนใคร คำถามคือบุคคลนั้นมอบอำนาจให้หรือไม่ ดู delegated authority

การรวมสองเรื่องนี้เป็นการตรวจสอบครั้งเดียวทำให้เกิดปัญหาได้สองแบบ: บล็อก automation ที่ถูกต้องเพียงเพราะไม่มี human login หรือเชื่อถือ agent ที่ระบุตัวตนได้ชัดเจนเกินไปสำหรับการกระทำที่มันไม่เคยมีเจตนาจะทำ

โดยทั่วไปมีการแสดง authorization อย่างไร

แอปพลิเคชันส่วนใหญ่อนุญาต agent ด้วยกลไกที่มีอยู่แล้ว:

• Credentials และ scopes. API key หรือ token ของ OAuth 2.0 ที่จำกัด scope ไว้เฉพาะสิ่งที่ integration ต้องใช้ MCP server ใช้โมเดลเดียวกันนี้: MCP authorization specification มอง protected server เป็น OAuth 2.1 resource server
• Policy ระดับ route. route แบบ read-only เปิดให้ agent ที่รู้จัก ขณะที่ write route ต้องใช้ credential ที่ผูกกับ account
• Risk tier. การกระทำที่กระทบต่ำอนุญาตได้กว้างกว่า การกระทำที่กระทบสูงต้องใช้ credential ที่แข็งแรงกว่า การยืนยันเพิ่มเติม หรือการตรวจสอบ
• Rate limit และ quota แยกตาม operator ตาม credential หรือตาม route

หลักฐานด้าน agent identity เป็นหนึ่งใน input สำหรับการตัดสินใจเหล่านี้ หากต้องการแนวทางที่เป็นรูปธรรม ดู การออกแบบ policy ระดับแอปสำหรับมนุษย์และ AI agent ซึ่งช่วยให้คุณปฏิบัติต่อ operator ที่ได้รับการยืนยันแล้วต่างจาก client ที่ไม่เปิดเผยตัวตนได้ แต่ permission เองยังมาจาก policy ของคุณ

ความเข้าใจผิดที่พบบ่อย

• "Verified agent หมายถึงได้รับอนุญาต" การยืนยันระบุว่า request นี้เป็นของใคร ส่วน policy ของคุณยังเป็นตัวตัดสินว่าฝ่ายนั้นทำอะไรได้บ้าง
• "ควรบล็อก agent เว้นแต่จะพิสูจน์ได้ว่าเป็นมนุษย์" agent จำนวนมากเป็นผู้เข้าร่วมที่ชอบด้วยเหตุผล สิ่งที่ควรถามให้ดีกว่าคือ actor แต่ละประเภทควรทำอะไรได้บ้าง แยกตาม route
• "Authorization อนุมานจากพฤติกรรมได้" พฤติกรรมอาจเพิ่มหรือลดความมั่นใจว่า actor ที่อยู่ตรงหน้าคือประเภทใด แต่ไม่ควรมอบ permission ให้ได้ด้วยตัวเอง

Proof of Actor จัดการเรื่องนี้อย่างไร

Proof of Actor ตอบคำถามด้าน evidence: actor ที่อยู่ตรงหน้าคือประเภทใด อยู่บนพื้นฐานอะไร (Verified, Declared, Inferred หรือ Unknown) และอะไรที่รู้แล้วกับยังไม่รู้ ระบบตั้งใจไม่ตัดสิน permission เอง ผลลัพธ์ของ Agent แม้จะได้รับการยืนยันแล้ว ก็ไม่ได้หมายความว่าได้รับ authorization ใน Route แอปพลิเคชันของคุณจะนำผลลัพธ์ของ actor มารวมกับ credential, scope และ risk tier ของตัวเอง เพื่อ allow, adapt, challenge, review หรือ limit แต่ละ interaction โดยเริ่มในโหมด observation เพื่อให้คุณตรวจสอบผลลัพธ์ก่อนบังคับใช้สิ่งใดก็ตาม

เรียนรู้เพิ่มเติมเกี่ยวกับ วิธีที่การตัดสินใจทำงานร่วมกับแอปของคุณ ดู use case สำหรับ APIs และ MCP servers หรือ สมัครขอสิทธิ์เข้าถึงก่อน

แหล่งอ้างอิง

• RFC 6749: The OAuth 2.0 Authorization Framework: token ที่มี scope สำหรับ client
• MCP specification 2026-07-28: Authorization: การอนุญาตแบบ OAuth สำหรับ MCP server
• RFC 9421: HTTP Message Signatures: สิ่งที่ request ที่ลงนามแล้วระบุได้