เมื่อเร็ว ๆ นี้ ฉันได้ทบทวนบทความนี้ และได้มีการกล่าวถึงการยืนยันตัวตนของเอเจนต์:
เราเห็นสัญญาณบางอย่างของสิ่งที่อาจจะเกิดขึ้น ตัวอย่างเช่น ข้อกำหนด MCP ล่าสุดมีเฟรมเวิร์กการอนุญาต framework
https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/
เพื่อนและคนหลายคนที่ไม่อยู่ในด้านความปลอดภัยหรือ CIAM มักจะคิดว่านี่คือสิ่งใหม่ แต่มันไม่ใช่ OAuth เป็นโปรโตคอลการอนุญาตที่มีพื้นฐานจากโทเค็นที่เกี่ยวข้องกับโทเค็นที่มีการกำหนดขอบเขต (โทเค็นการเข้าถึง) โทเค็นเหล่านี้มีความละเอียดอ่อนด้านเวลาและขอบเขต ซึ่งช่วยให้มั่นใจในความปลอดภัยและการควบคุมการเข้าถึงทรัพยากรและบริการที่เหมาะสม ในตลาด SaaS ระดับโลก (ก่อน AI) ระบบระบุตัวมืออาชีพส่วนใหญ่สร้างขึ้นบนสิ่งนี้แล้ว
เมื่อคุณเชื่อมต่อบัญชี Google ของคุณกับแอปของบุคคลที่สาม เช่น Notion หรือ Zoom มันจะใช้ OAuth เพื่อขออนุญาตที่จำเป็นเท่านั้น เช่น การเข้าถึงปฏิทินหรือผู้ติดต่อของคุณ โดยไม่เปิดเผยรหัสผ่าน Google ของคุณเลย คุณสามารถเพิกถอนการเข้าถึงได้ตลอดเวลาจากการตั้งค่าบัญชี Google ของคุณ รูปแบบการเข้าถึงแบบมอบหมายนี้เป็นสิ่งที่ OAuth ถูกออกแบบมาเพื่อและเป็นพื้นฐานเดียวกันที่กำลังขยายไปยังแอปพลิเคชันที่มีตัวแทนในปัจจุบัน
สิ่งที่ไม่เปลี่ยนแปลงในโลกของตัวแทน#
Auth ไม่ใช่เรื่องใหม่ ยังคงอิง OAuth 2.1#
มีสองโปรโตคอลหลักที่เกิดขึ้น: MCP A2A
MCP มุ่งเน้นไปที่การปฏิสัมพันธ์ระหว่าง LLMs และเครื่องมือและบริบทของแอปของคุณA2A มุ่งเน้นไปที่การเปิดใช้งานการแลกเปลี่ยนงานระหว่างตัวแทน
แต่เมื่อพูดถึงการยืนยันตัวตนและการอนุญาต ทั้งหมดนี้ยังคงพึ่งพามาตรฐานอุตสาหกรรมที่ได้รับการยอมรับอย่างดีเช่น OAuth
เซิร์ฟเวอร์อนุญาต MCP MUST นำ OAuth 2.1 มาใช้พร้อมกับมาตรการความปลอดภัยที่เหมาะสมสำหรับลูกค้าที่เป็นความลับและสาธารณะ
ลูกค้า A2A มีหน้าที่เตรียมวัสดุรับรองที่จำเป็น (เช่น โทเค็น OAuth 2.0, คีย์ API, JWTs) ผ่านกระบวนการภายนอกกับโปรโตคอล A2A เอง ซึ่งอาจเกี่ยวข้องกับขั้นตอน OAuth (รหัสการอนุญาต, ข้อมูลประจำตัวของลูกค้า), การจัดจำหน่ายคีย์ที่ปลอดภัย ฯลฯ
ตามที่ Google ได้กล่าวไว้:
แทนที่จะคิดค้นมาตรฐานใหม่ที่เป็นกรรมสิทธิ์สำหรับความปลอดภัยและการดำเนินงาน A2A มุ่งเน้นไปที่การรวมเข้ากับโครงสร้างพื้นฐานองค์กรที่มีอยู่และปฏิบัติที่ดีที่สุดที่ได้รับการยอมรับอย่างกว้างขวาง
ตัวแทนต้องมีเอกลักษณ์เฉพาะตัวหรือไม่?#
มีเนื้อหาและ FOMO มากมายที่ผลักดันไอเดียที่ว่าเมื่อเอเจนต์กลายเป็นปกติ เราต้องการระบบสำหรับ การจัดการตัวตนของตัวแทน
คำตอบคือ: ใช่และไม่ใช่.
ใช่ เพราะเรากำลังแนะนำชั้นใหม่ระหว่างมนุษย์และเครื่องจักร มีความต้องการจริงที่จะ:
จัดการและระบุตัวตนของตัวแทน
กำหนด ID ให้กับเอกลักษณ์
ติดตามบันทึก
ตรวจสอบการกระทำ (เพื่อรู้ว่าจริง ๆ แล้วบางสิ่งได้รับการดำเนินการโดยมนุษย์หรือเอเจนต์)
อย่างไรก็ตาม ในกรณีเทคนิคส่วนใหญ่ ไม่มีความจำเป็นในการสร้างแนวคิดอย่างเป็นทางการของ “ตัวตนของตัวแทน”.
ตัวแทน ≠ ผู้ใช้ ≠ บัญชีบริการ.
เบื้องหลังตัวแทนทุกรายยังมีผู้ใช้และปกติแล้วตัวตนของผู้ใช้ก็เพียงพอแล้ว
ในปัจจุบัน ตัวแทนส่วนใหญ่:
ดำเนินการตามการทดลองของผู้ใช้ (เช่น โทเค็น OAuth)
ดำเนินการตามตรรกะหรือเรียก API
ดำเนินงานที่มีอายุสั้นและเฉพาะที่ (ไม่จำเป็นต้องติดตาม)
ในความหมายนี้ ตัวแทนเพียงแค่อยู่ในบทของ เครื่องมือ และไม่จำเป็นต้องมี ID ที่เป็นเอกลักษณ์ทั่วโลก
ตัวอย่างเช่น:
เอเจนต์ GPT ที่เรียก API ปฏิทินของคุณจะต้องได้รับการอนุญาตที่คุณมอบหมายให้
เอเจนต์ LangChain ไม่จำเป็นต้องมีตัวตน ตราบใดที่มันเรียกใช้เครื่องมือที่ถูกต้องได้ก็เพียงพอแล้ว
แม้กระทั่งก่อน AI เราเคยมีแนวคิดของ machine-to-machine (M2M) auth
M2M หมายถึงการแลกเปลี่ยนข้อมูลอัตโนมัติโดยไม่มีมนุษย์เข้ามาเกี่ยวข้อง
ในบริบทนี้ การยืนยันตนใช้งานบ่อยๆ กับแอปไคลเอนต์หรือบัญชีบริการ
หากคุณต้องการให้ตัวแทนของคุณมีตัวตน (สำหรับการตรวจสอบ ฯลฯ) คุณสามารถใช้ ID ของแอปและนั่นก็เพียงพอแล้ว
คุณยังต้องวางโครงสร้างผลิตภัณฑ์ของคุณ#
สิ่งนี้ยังไม่ได้เปลี่ยนแปลง ไม่ว่าจะผลิตภัณฑ์ของคุณเกี่ยวข้องกับตัวแทนหรือไม่ โครงสร้างของระบบระบุตัวตนของคุณขึ้นอยู่กับใครเป็นผู้ใช้ของคุณและระบบของคุณใช้งานอย่างไรกับพวกเขา
ถ้าคุณกำลังสร้างผลิตภัณฑ์ที่มีตัวแทนสำหรับผู้บริโภค:
คุณจะต้องมีวิธียืนยันตัวตนที่เบา (เช่น อีเมล์, โทรศัพท์, ล็อกอินผ่านโซเชียล) และสระผู้ใช้อย่างเป็นเอกภาพเพื่อจัดการบุคคลที่ปฏิสัมพันธ์กับแอปของคุณและเอเจนต์ของมัน ตัวแทนกระทำในนามของผู้ใช้งานโดยใช้โทเค็นที่มอบหมายมา (เช่น ผ่าน OAuth)
ตัวอย่าง:
ลองนึกภาพว่าคุณกำลังสร้างผู้ช่วย AI จัดตารางเวลา หรือบอทปฏิทินที่ขับเคลื่อนด้วย AI
ผู้ใช้แต่ละรายเข้าสู่ระบบด้วยบัญชี Google ส่วนตัว ระบบของคุณใช้ OAuth เพื่อขออนุญาตเข้าถึงปฏิทินของพวกเขา ตัวแทนไม่มีตัวตนของมันเอง แต่มันใช้โทเค็นของผู้ใช้ในการจัดการนัดหมาย ตรวจสอบความพร้อม หรือส่งการเตือน โครงสร้างระบบระบุตัวตนเรียบง่าย: หนึ่งสระผู้ใช้ทั่วโลก การจัดเก็บโทเค็น และการติดตามการยินยอมต่อผู้ใช้
ถ้าคุณกำลังสร้างแพลตฟอร์มที่มีตัวแทน B2B :
คุณจะต้องสนับสนุนตัวตนในระดับองค์กร ไม่ใช่แค่ผู้ใช้ธรรมดาเท่านั้น ซึ่งรวมถึง:
SSO สำหรับลูกค้าองค์กร
การแยกระดับพื้นที่ทำงานหรือเท็นแนนต์
นโยบายการมอบหมายตัวแทนในระดับองค์กร (เช่น ควบคุมว่าตัวแทนสามารถทำอะไรได้บ้างในทีมต่างๆ)
การมองเห็นและบันทึกการทำงานทั้งหมดของตัวแทนในนามของพนักงาน
ตัวอย่าง:
ลองนึกภาพว่าคุณกำลังสร้างแพลตฟอร์มที่ให้บริการตัวแทน AI ในการทำงานอัตโนมัติ - เช่น บอทนักวิเคราะห์ความปลอดภัยที่ตรวจสอบบันทึกและส่งการแจ้งเตือน หรือผู้ช่วยการขายที่จัดทำemail จากข้อมูล CRM
แต่ละบริษัทที่ใช้แพลตฟอร์มของคุณต้องการ:
เข้าสู่ระบบด้วย SSO ที่มีอยู่
ควบคุมสิ่งที่ตัวแทนสามารถเข้าถึงได้ (เช่น เครื่องมือภายใน ระบบเอกสาร)
ดูว่าตัวแทนใดทำงานอะไร ภายใต้การอนุญาตของพนักงานคนไหน
ในกรณีนี้ โครงสร้างตัวตนของคุณจำเป็นต้องสนับสนุนการออกแบบแบบหลายเท็นแนนต์ สิทธิ์ของตัวแทนที่มีขอบเขต และนโยบายเฉพาะองค์กร ตัวแทนยังคงทำงานในนามของผู้ใช้ แต่สิทธิ์และขอบเขตตัวตนถูกบังคับใช้ต่อเท็นแนนต์ธุรกิจ
ในทั้งสองกรณี รูปแบบตัวตนกำหนดวิธีที่ตัวแทนทำงาน สิ่งที่พวกเขาสามารถเข้าถึงได้ และระบบของคุณรับรองความรับผิดชอบอย่างไร
ใช้คู่มือนี้เพื่อช่วยให้คุณวางแผนระบบระบุตัวและโครงสร้างผลิตภัณฑ์ของคุณ
https://docs.logto.io/introduction/plan-your-architecture/b2c
https://docs.logto.io/introduction/plan-your-architecture/b2b
คุณยังคงต้องการชั้นความปลอดภัยเพื่อรักษาความปลอดภัยในแอปที่มีตัวแทนของคุณ#
ไม่ว่าแอปจะเป็นตัวแทนหรือไม่ คุณยังคงต้องการชั้นความปลอดภัยพื้นฐานต่อไปเพื่อปกป้องผู้ใช้และระบบของคุณ:
การยืนยันตัวหลายปัจจัย (MFA)
ป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตแม้ว่าข้อมูลประจำตัวจะถูกขโมย
ตัวอย่าง: ถ้าตัวแทนช่วยคุณดำเนินการที่เสี่ยงสูง เช่น การทำธุรกรรมหรือเปลี่ยนแปลงการตั้งค่าตัวตน ควรรักษามนุษย์ในห่วงโซ่และใช้ MFA เพื่อยืนยันการกระทำก่อนดำเนินการต่อ
CAPTCHA
บล็อกการละเมิดแบบอัตโนมัติเช่นการยัดไส้ข้อมูลประจำตัวหรือการสมัครสมาชิกแบบบอท
ตัวอย่าง: แสดง CAPTCHA หลังจากความพยายามเข้าสู่ระบบล้มเหลวถึง 3 ครั้ง เพื่อป้องกันการโจมตีด้วยกำลัง
การควบคุมการเข้าถึงตามบทบาท (RBAC)
รับรองว่าผู้ใช้และตัวแทนเข้าถึงเฉพาะที่พวกเขาอนุญาตเท่านั้น
ตัวอย่าง: ผู้ช่วย AI ในพื้นที่การทำงานของบริษัทสามารถอ่านอีเวนต์ในปฏิทิน แต่ไม่สามารถเข้าถึงข้อมูลการเรียกเก็บเงินได้เว้นแต่จะได้รับบทบาทสูงกว่าโดยเฉพาะ
เข้าสู่ระบบโดยไม่ใช้รหัสผ่าน
ปรับปรุงการใช้งานและลดความเสี่ยงของรหัสผ่านการเลี้ยนง่าย
ตัวอย่าง: ให้ผู้ใช้ล็อกอินใช้ลิงก์มายากที่ส่งไปยังอีเมลของพวกเขาหรือตัวช่วยชีวภาพเช่น Face ID
ฟีเจอร์เหล่านี้ใช้ได้กับแอปแบบดั้งเดิมและแอปที่มีตัวแทน โดยเฉพาะอย่างยิ่งเมื่อตัวแทนเริ่มทำงานกับข้อมูลและระบบที่ละเอียดอ่อน
อะไรที่เปลี่ยนแปลงในโลกของตัวแทน#
การยืนยันตัวตนสำคัญกว่าเดิม#
เมื่อเกิดกระบวนการทำงานที่มีตัวแทนและหลายตัวแทนขึ้น เราจะเห็นการใช้ใหม่ที่ผู้ใช้ ตัวแทน API และเซิร์ฟเวอร์ MCP ทุกตัวเชื่อมต่อ จำนวนและรูปแบบของสถานการณ์เหล่านี้เพิ่มขึ้นอย่างรวดเร็ว มากกว่าแต่ก่อน
เมื่อการเชื่อมต่อเหล่านี้เกิดขึ้น การอนุญาตจะกลายเป็นสิ่งที่มีการมองเห็นชัดเจนมากขึ้น ผู้ใช้จะต้องให้ความยินยอมอย่างชัดเจน และการอนุญาตต้องถูกจัดการอย่างระมัดระวังในระบบต่างๆ นั่นคือเหตุผลที่ทุกคนตอนนี้พูดถึงการรักษา "มนุษย์ในห่วงโซ่" ทำให้แน่ใจว่าผู้ใช้มองเห็นและควบคุมได้เพียงพอเกี่ยวกับสิ่งที่ตัวแทนสามารถทำได้และขอบเขตที่พวกเขาได้รับการอนุญาต
แอป AI ของคุณอาจต้องการผสานรวมกับบริการภายนอกจำนวนมาก#
ระบบนิเวศ MCP กำลังขยาย และนั่นหมายความว่า คุณแอปไม่ได้เป็นเพียงบริการอิสระ: มันเป็นส่วนหนึ่งของเครือข่ายที่เชื่อมต่อกัน
เพื่อให้บริบทที่มีประโยชน์แก่ LLMs ตัวแทนของคุณอาจต้อง:
เข้าใช้เซิร์ฟเวอร์ MCP หลายตัว
ตัวอย่าง: ลองนึกภาพผู้จัดการโปรเจ็กต์ AI ที่ดึงข้อมูลอัปเดตงานจาก Jira ความพร้อมของทีมจาก Google Calendar และข้อมูลการขายจาก Salesforce และแต่ละสิ่งเหล่านี้สามารถขับเคลื่อนด้วยเซิร์ฟเวอร์ MCP ต่าง ๆ ในการสร้างสรุปรายสัปดาห์หนึ่งครั้ง ตัวแทนต้องมีปฏิสัมพันธ์กับแหล่งข้อมูลที่แตกต่างกันอย่างปลอดภัย นั่นคือที่มาของการยืนยันตัวตนและการอนุญาต เพื่อปกป้องการเชื่อมต่อทุกครั้งและควบคุมการแชร์ข้อมูล
เชื่อมต่อกับ API และเครื่องมือภายนอก
ตัวอย่าง: ตัวแทนสนับสนุนลูกค้าอาจต้องการเรียกดูประวัติการสั่งซื้อจาก Shopify อัปเดตตั๋วใน Zendesk และเริ่มกระบวนการใน Slack หากไม่มีการผสานรวม ตัวแทนจะถูกแยกและไม่มีประสิทธิภาพ
เมื่อเอเจนต์มีความรับผิดชอบมากขึ้น การผสานรวมจึงกลายเป็นกุญแจสู่ประโยชน์ แอป AI ของคุณไม่ได้เกี่ยวกับสิ่งที่สามารถทำได้เพียงลำพัง แต่เกี่ยวกับสิ่งที่มันสามารถเข้าถึงจัดการและวินิจฉัยในระบบนิเวศที่เชื่อมต่อกัน นั่นคือเหตุผลที่การสร้างความสามารถในรองรับการรวมเข้าด้วยกันอย่างปลอดภัยและยืดหยุ่นสำคัญกว่าที่เคย
คุณต้องเปิดรับมาตรฐานเปิด: OAuth/OIDC มีความสำคัญกว่าที่เคย#
ในยุค AI ความต้องการในการผสานรวมอย่างปลอดภัยยืดหยุ่นกำลังเพิ่มขึ้น นั่นทำให้ OAuth 2.0 และ OIDC มีความสำคัญกว่าที่เคย
กรณีการใช้งานหลักประกอบด้วย:
เซิร์ฟเวอร์ MCP ระยะไกล: ให้ตัวแทนบุคคลที่สามเข้าถึงผลิตภัณฑ์ของคุณอย่างปลอดภัยโดยใช้โทเค็นที่มอบหมาย
การรวมเข้าร่วมของบุคคลที่สาม: อนุญาตให้เครื่องมือหรือตัวแทนอื่นเชื่อมต่อกับแอปของคุณ (เช่น แพลตฟอร์มการจัดการโครงการ) โดยไม่ต้องใช้ข้อมูลการยืนยันครั้งแรก
การพัฒนาตัวแทน: สร้างตัวแทน AI ที่ดำเนินการอย่างปลอดภัยในนามของผู้ใช้ในบริการต่าง ๆ
อุปกรณ์สมาร์ท: ใช้ OAuth/OIDC สำหรับสิ่งต่าง ๆ เช่น เครื่องบันทึกหมายเหตุขับเคลื่อน AI เพื่อยืนยันตัวตนผู้ใช้และเชื่อมต่อกับคลาวด์ — โดยเฉพาะอย่างยิ่งที่มีอินเตอร์เฟซน้อย
โปรโตคอลเหล่านี้มอบการเข้าถึงที่ปลอดภัย มีพื้นฐานจากโทเค็น และการยืนยันจากผู้ใช้
สิ่งนี้มีความสำคัญในโลกที่มีระบบเชื่อมต่อมากมายในตัวแทน ดูบทความนี้เพื่อดู ทำไม OAuth และ OIDC ถึงสำคัญ
การออกแบบสำหรับความไว้วางใจและการขยายในยุคซอฟต์แวร์เอเจนต์#
เมื่อผลิตภัณฑ์ตัวแทนพัฒนา หลักการพื้นฐานของการระบุตัวตนและการอนุญาตยังคงเหมือนเดิม แต่บริบทกำลังเปลี่ยนแปลงไป ตัวแทนแนะนำพื้นผิวใหม่สำหรับการมอบหมาย ความยินยอมและการเข้าถึง นั่นคือเหตุผลที่การยึดถือตามมาตรฐานเปิดเช่น OAuth การสร้างโครงสร้างที่ชัดเจน และบังคับใช้แนวทางการรักษาความปลอดภัยที่แข็งแกร่งไม่ใช่แค่ปฏิบัติที่ดีที่สุด แต่เป็นพื้นฐาน การออกแบบด้วยการระมัดระวังในตอนนี้หมายถึงระบบของคุณจะสามารถขยายอย่างมั่นใจ ยืดหยุ่นและไว้วางใจได้ในอนาคตที่ขับเคลื่อนด้วย AI
