มีอะไรเปลี่ยนแปลงและอะไรที่ยังไม่เปลี่ยนแปลงใน Auth และ Identity สำหรับแอปที่มีตัวแทน

เมื่อเร็ว ๆ นี้ ฉันได้ทบทวนบทความนี้ และได้มีการกล่าวถึงการยืนยันตัวตนของเอเจนต์:

เราเห็นสัญญาณบางอย่างของสิ่งที่อาจจะเกิดขึ้น ตัวอย่างเช่น ข้อกำหนด MCP ล่าสุดมีเฟรมเวิร์กการอนุญาต framework ตาม OAuth 2.1 ซึ่งชี้ให้เห็นถึงความเป็นไปได้ในการมอบโทเค็นที่มีขอบเขตที่สามารถเพิกถอนได้ให้แก่เอเจนต์ AI แทนที่จะเป็นกุญแจลับดิบๆ เราสามารถจินตนาการถึงสถานการณ์ที่เอเจนต์ AI ไม่ได้รับกุญแจ AWS ที่แท้จริงของคุณ แต่จะได้รับใบรับรองชั่วคราวหรือโทเค็นความสามารถที่ทำให้สามารถดำเนินการที่มีการระบุไว้อย่างแคบๆ ได้

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:

คุณจะต้องสนับสนุนตัวตนในระดับองค์กร ไม่ใช่แค่ผู้ใช้ธรรมดาเท่านั้น ซึ่งรวมถึง:

1. SSO สำหรับลูกค้าองค์กร
2. การแยกระดับพื้นที่ทำงานหรือเท็นแนนต์
3. นโยบายการมอบหมายตัวแทนในระดับองค์กร (เช่น ควบคุมว่าตัวแทนสามารถทำอะไรได้บ้างในทีมต่างๆ)
4. การมองเห็นและบันทึกการทำงานทั้งหมดของตัวแทนในนามของพนักงาน

ตัวอย่าง:

ลองนึกภาพว่าคุณกำลังสร้างแพลตฟอร์มที่ให้บริการตัวแทน AI ในการทำงานอัตโนมัติ - เช่น บอทนักวิเคราะห์ความปลอดภัยที่ตรวจสอบบันทึกและส่งการแจ้งเตือน หรือผู้ช่วยการขายที่จัดทำemail จากข้อมูล CRM

แต่ละบริษัทที่ใช้แพลตฟอร์มของคุณต้องการ:

1. เข้าสู่ระบบด้วย SSO ที่มีอยู่
2. ควบคุมสิ่งที่ตัวแทนสามารถเข้าถึงได้ (เช่น เครื่องมือภายใน ระบบเอกสาร)
3. ดูว่าตัวแทนใดทำงานอะไร ภายใต้การอนุญาตของพนักงานคนไหน

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

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

ใช้คู่มือนี้เพื่อช่วยให้คุณวางแผนระบบระบุตัวและโครงสร้างผลิตภัณฑ์ของคุณ

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