ปี 2025 กำลังเป็นปีที่ AI ก้าวสู่เป็นที่ยอมรับ ด้วยการเติบโตอย่างรวดเร็วของ LLMs และประสบการณ์จากตัวแทน พวกเรามักถูกถาม: ทำอย่างไรถึงจะยอมรับยุคใหม่นี้ได้? แล้วกรณีการใช้งานใหม่ๆ สำหรับการตรวจสอบสิทธิ์และการอนุญาตของ AI agent มีอะไรบ้าง? ในบทความนี้ เราจะสำรวจประสบการณ์ของตัวแทนทั่วไปและชี้ให้เห็นสถานการณ์ด้านความปลอดภัยและการตรวจสอบสิทธิ์ตามทาง
ประสบการณ์การตรวจสอบสิทธิ์ของตัวแทน ChatGPT#
ฉันได้ซื้อ ChatGPT Operator และสำรวจการทำงานทั่วไปบางอย่าง ตัวอย่างหนึ่งคือการจองที่พักในโตเกียว ประเทศญี่ปุ่น Operator ได้ทำให้การหาห้องที่เหมาะสมตามคำของฉันเป็นเรื่องง่ายมาก
ในระหว่างการชำระเงิน มันขอให้ฉันเข้าสู่ระบบแล้วส่งการควบคุมกลับมาที่ฉัน
ประสบการณ์นี้ทำให้ฉันรู้สึกไม่สะดวกใจ ถึงแม้ว่าฉันจะมีการควบคุมและตัวแทนไม่สามารถเข้าสู่ระบบให้ฉันได้ แต่ฉันยังคงต้องใส่อีเมลและรหัสผ่านในเบราว์เซอร์ของ Operator นี่หมายความว่าหากคุณเข้าสู่อีเมล (หรือบริการใดๆ) ผ่าน Operator ข้อมูลการเข้าสู่ระบบของคุณจะถูกเก็บในคุกกี้
OpenAI’s Operator ระบุว่ามันไม่เคยเก็บข้อมูลการเข้าสู่ระบบของผู้ใช้และปฏิบัติตามมาตรฐานความเป็นส่วนตัว เช่น SOC II อย่างไรก็ตาม เมื่อตัวแทนของบุคคลที่สามมีการโต้ตอบกับบริการภายนอกในนามของคุณ ความเสี่ยงด้านความปลอดภัยจะเพิ่มขึ้นอย่างมาก
โดยทั่วไปแล้ว การให้การเข้าถึงบัญชีและข้อมูลการเข้าสู่ระบบของคุณแก่ตัวแทนโดยตรงเป็นความคิดที่ไม่ดี
ยังมีโอกาสในการปรับปรุงอีกมาก ในส่วนถัดไป ฉันจะสังเคราะห์วิธีการต่างๆ ในการตรวจสอบสิทธิ์และการจัดการข้อมูลการเข้าสู่ระบบ พร้อมทั้งชั่งน้ำหนักข้อดีและข้อเสีย
เหมือนที่ X Threads
ข้อมูลการเข้าสู่ระบบถูกจัดการอย่างไร และมีความเสี่ยงด้านความปลอดภัยอะไรบ้าง?#
ให้ตัวแทน AI ข้อมูลการเข้าสู่ระบบของคุณโดยตรง#
ในวิธีนี้ AI ป้อนข้อมูลการเข้าสู่ระบบแบบข้อความธรรมดา (เช่น อีเมลและรหัสผ่าน) ในนามของคุณ ตัวอย่างเช่น ai agent อาจร้องขอรายละเอียดการเข้าสู่ระบบของคุณและใส่มันให้กับคุณ
อย่างไรก็ตาม วิธีนี้มีความเสี่ยงด้านความปลอดภัยเนื่องจากสามารถเปิดเผยข้อมูลสำคัญ หากการใช้งานเป็นสิ่งจำเป็น การผสานรวมกับผู้จัดการรหัสผ่านหรือระบบการจัดการความลับจะปลอดภัยกว่า นอกจากนี้ การจำกัดระยะเวลาที่ข้อมูลการเข้าสู่ระบบถูกจัดเก็บสามารถช่วยลดความเสี่ยงของการรั่วไหลได้
แทนที่จะเป็นข้อมูลการเข้าสู่ระบบแบบข้อความธรรมดา Personal Access Tokens (PATs)
การมอบอำนาจจากผู้ใช้ผ่าน OAuth#
OAuth (Open Authorization)
โดยสรุปแล้ว OAuth สามารถแก้ไขปัญหาการมอบอำนาจในการเข้าถึงอย่างปลอดภัยได้: ตัวอย่างเช่น คุณสามารถให้สิทธิ์แอปการเดินทางอ่าน Google Calendar ของคุณโดยไม่ต้องให้รหัสผ่าน Google ให้กับแอป ซึ่งทำได้โดยการให้ผู้ใช้ตรวจสอบสิทธิ์กับผู้ให้บริการข้อมูล (เช่น Google) แล้วจึงออกโทเค็นให้กับแอปของบุคคลที่สามแทนที่จะเปิดเผยข้อมูลการเข้าสู่ระบบของผู้ใช้
วิธีที่ดีกว่าในการจัดการสถานการณ์นี้ คือการอนุญาต ChatGPT Operator (หรือ agent ใดๆ) เพื่ออ่านและเขียนบน Airbnb โดยไม่ต้องแชร์รหัสผ่านหรือข้อมูลการเข้าสู่ระบบของคุณแทนการให้ Operator เข้าสู่ระบบโดยตรง คุณสามารถมอบอำนาจผ่านกระบวนการให้สิทธิ์ที่ปลอดภัย
ในมุมมองของฉัน หาก OpenAI Operator ต้องการเสริมสร้างความไว้วางใจและความปลอดภัยทางอัตลักษณ์ มีวิธีหลายอย่างที่สามารถทำได้
ย้ายกระบวนการเข้าสู่ระบบออกไปจาก Operator: การจัดการการเข้าสู่ระบบผู้ใช้นอก ChatGPT Operator นั่นหมายความว่าคุณอาจคลิกปุ่ม “เข้าสู่ระบบด้วย [บริการ]” และถูกเปลี่ยนเส้นทางไปยังหน้าการเข้าสู่ระบบที่ปลอดภัยของบริการเพื่อยืนยันตัวตนของคุณอย่างสมบูรณ์นอก chat หรือ ChatGPT Operator ตัวอย่างเช่น หากมีปลั๊กอินของ Airbnb คุณจะถูกส่งไปยังเว็บไซต์ Airbnb เพื่อใส่ข้อมูลการเข้าสู่ระบบและอนุญาต ChatGPT และจากนั้นปลั๊กอินจะได้รับโทเค็น ChatGPT จะได้รับโทเค็นหรือคีย์การเข้าถึงชั่วคราวเท่านั้น ที่ให้การเข้าถึงที่จำกัด (เช่น “อ่านเส้นทางการเดินทางของฉัน”) แทนที่การเห็นรหัสผ่านของคุณจริงๆ
ให้ผู้ใช้เสร็จสิ้นกระบวนการยินยอมก่อนที่ AI agent จะดำเนินงานใดๆ วิถีนี้คล้ายกับวิธีที่หลายผลิตภัณฑ์จัดการกับการผสานรวม ตลาด และบริการที่เชื่อมต่อ
นี่คือตัวอย่างอีกกรณีหนึ่ง เช่น การผสานรวมตลาดของ Slack กับ Notion Slack ขอสิทธิ์การเข้าถึงพื้นที่ทำงาน specific ของ Notion ซึ่งสามารถอ่านบทความและแสดงในช่องทางของ Slack ของคุณ
ในขณะเดียวกัน Slack ยังให้หน้าการยินยอมเพื่อให้ Notion สามารถเข้าถึงพื้นที่ทำงานได้ในกระบวนการนี้
ChatGPT Operator ควรใช้วิธีการคล้ายกันโดยการผสานรวม OAuth เพื่อให้งานตัวแทนสามารถเข้าถึงบริการภายนอกหลายแห่งอย่างปลอดภัย แบบนี้มันสามารถรับโทเค็นการเข้าถึงด้วยสิทธิ์ที่จำเป็นในการดำเนินงานได้อย่างปลอดภัย
การยืนยันตัวตนเพิ่มขึ้นสำหรับการดำเนินการที่อ่อนไหว#
AI agent สามารถจัดการกับงานประจำได้เองและอัตโนมัติได้ แต่สำหรับการกระทำที่มีความเสี่ยงสูง จำเป็นต้องมีการตรวจสอบเพิ่มเติมเพื่อให้มั่นใจความปลอดภัย — เช่น การส่งเงินหรือการปรับเปลี่ยนการตั้งค่าความปลอดภัย — ผู้ใช้ต้องยืนยันอัตลักษณ์ของตนผ่าน การยืนยันตัวตนหลายปัจจัย (MFA) รหัสผ่านครั้งเดียว (OTPs)
อย่างไรก็ตาม การยืนยันตัวตนเพิ่มขึ้นบ่อยครั้งสามารถนำไปสู่ความไม่พอใจของผู้ใช้ได้ โดยเฉพาะหากถูกกระตุ้นบ่อยเกินไป ดังนั้นประสบการณ์เฉพาะสำหรับตัวแทนควรคิดถึงประสบการณ์ของผู้ใช้ตลอดเส้นทางในกรอบใหม่นี้
เพื่อเพิ่มความปลอดภัยโดยไม่กระทบต่อประสบการณ์ของผู้ใช้ การยืนยันตัวตนแบบปรับเปลี่ยนและ MFA ควรใช้ในการตัดสินใจว่าจำเป็นต้องมีการยืนยันเพิ่มเติมเมื่อใด การกระตุ้นตามความเสี่ยง เช่น การเปลี่ยนแปลง IP หรือพฤติกรรมผิดปกติ ช่วยลดความจำเป็นในการขอการยืนยันที่ไม่จำเป็น
อัตลักษณ์เชื่อมโยงและการเข้าสู่ระบบครั้งเดียว (SSO) สำหรับระบบหลายตัวแทน#
ในระบบหลายตัวแทนสำหรับองค์กร AI agent มักจะต้องทำงานข้ามแพลตฟอร์มต่างๆ เพื่อให้การตรวจสอบสิทธิ์เป็นไปอย่างราบรื่น ผู้ใช้ยืนยันตัวตนหนึ่งครั้งผ่านผู้ให้บริการอัตลักษณ์ (IdP) เช่น Okta, Azure AD, หรือ Google Workspace ตัวแทนจะเข้าสู่ระบบโดยใช้ SAML OpenID Connect (OIDC) บทบาท (RBAC) การควบคุมการเข้าถึงตามแอตทริบิวต์ (ABAC)
วิธีการนี้ช่วยลดความจำเป็นในการที่ผู้ใช้จะต้องเข้าสู่ระบบหลายครั้งในขณะเดียวกันยังเพิ่มความปลอดภัยและการปฏิบัติตามผ่านการจัดการอัตลักษณ์ที่มีศูนย์กลาง นอกจากนี้ยังช่วยให้สามารถนโยบายการเข้าถึงที่ยืดหยุ่น มั่นใจว่าตัวแทนดำเนินการภายในสิทธิ์ที่กำหนด
การจัดการขอบเขตและการอนุญาต#
เนื่องจาก Operators และ Agents สามารถทำงานในนามของผู้ใช้ การให้ผู้มีมนุษฐานสิทธิ์เพียงพอและการกำหนดสิทธิ์ของ AI agent อย่างละเอียดรอบคอบเป็นสิ่งสำคัญ หลักการสองข้อที่ควรปฏิบัติคือ:
สิทธิ์น้อยที่สุด – ให้สิทธิ์ที่จำเป็นสำหรับการงานเท่านั้น
การเข้าถึงที่มีระยะเวลาจำกัด – จำกัดระยะเวลาการเข้าถึงเพื่อลดความเสี่ยงทางความปลอดภัย
การควบคุมการเข้าถึงแบบอิงตามบทบาท (RBAC) ช่วยจัดการขอบเขตของ agent โดยการกำหนดบทบาทเฉพาะสำหรับบางงาน สำหรับการควบคุมที่ละเอียดกว่า การควบคุมการเข้าถึงแบบอิงตามแอตทริบิวต์ (ABAC) ช่วยให้สามารถจัดการสิทธิ์ที่เข้าใจตามบริบทและพลวัต มั่นใจว่า AI agent สามารถเข้าถึงข้อมูลที่จำเป็นเฉพาะเมื่อพวกเขาต้องการ
เชื่อมต่อเซิร์ฟเวอร์ MCP กับ Auth#
MCP กำลังเป็นที่นิยมมากขึ้นในการเพิ่มประสิทธิภาพของ AI agents โดยให้ข้อมูลที่มีบริบทมากขึ้น ปรับปรุงประสิทธิภาพและประสบการณ์ของผู้ใช้
เหตุใดเซิร์ฟเวอร์ MCP จึงเกี่ยวข้องกับการรับรองสิทธิ์ และเหตุใดจึงสำคัญ?#
เราเขียนบทความมาก่อนหน้านี้เพื่อช่วยให้คุณเข้าใจว่า เซิร์ฟเวอร์ MCP คืออะไร
เซิร์ฟเวอร์ MCP เป็นส่วนสำคัญของ Model Context Protocol ซึ่งทำหน้าที่เป็นสะพานระหว่าง AI models และแหล่งข้อมูลภายนอก มันช่วยให้การทำข้อมูลเรียลไทม์และการดึงข้อมูลแบบเรียลไทม์จากบริการเช่น Slack, Gmail, และ Google Calendar โดยการสร้างเซิร์ฟเวอร์ MCP คุณสามารถเชื่อมต่อบริการระยะไกลเหล่านี้กับ LLMs เพิ่มประสิทธิภาพ AI-powered applications ของคุณด้วยข้อมูลที่เป็นบริบทและการดำเนินงานอัจฉริยภาพ
แตกต่างจาก ระบบการสร้างโดยการดึงข้อมูล (Retrieval-Augmented Generation, RAG) ซึ่งต้องการการสร้าง embeddings และการจัดเก็บเอกสารในฐานข้อมูลเวกเตอร์ เซิร์ฟเวอร์ MCP เข้าถึงข้อมูลได้โดยตรงโดยไม่ต้องมีการจัดทำดัชนีข้อมูลล่วงหน้า นั่นหมายความว่าข้อมูลไม่เพียงแต่แม่นยำและทันสมัยมากขึ้นแต่ยังผสานเข้ากับภาระการคำนวณต่ำกว่าและไม่ต้องเสียสละความปลอดภัย
https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained
สำหรับ AI agents ที่ใช้เซิร์ฟเวอร์ MCP จะเกิดการปฏิสัมพันธ์หลายรูปแบบระหว่าง เซิร์ฟเวอร์ MCP, LLM, agent, และ user
ในโลกที่ขับเคลื่อนโดย AI วันนี้ ที่ตัวแทนจัดการงานหลายรูปแบบข้ามบริการ การรวมพวกเขากับเซิร์ฟเวอร์ MCP หลายที่กำลังมีความต้องการมากขึ้น
การตรวจสอบสิทธิ์ของ agent กำลังปรากฏ — ผลิตภัณฑ์ของคุณควรปรับตัว#
ตัวอย่างที่ดีคือ Composio.dev แพลตฟอร์มการรวมที่มุ่งเน้นนักพัฒนาที่ง่ายต่อการเชื่อมต่อ ai agents และ LLMs กับแอปและบริการภายนอก ตั้งชื่อว่า “รับรองสิทธิ์สำหรับ ai agents ที่การปฏิบัติงานในนามของผู้ใช้” ซึ่งโดยพื้นฐานแล้วมีการให้บริการเซิร์ฟเวอร์ MCP (ตัวเชื่อมต่อ) ที่สามารถผสานรวมได้อย่างง่ายดายกับผลิตภัณฑ์ที่ขับเคลื่อนโดย AI
ในฐานะคนที่อยู่ในพื้นที่ของการรับรองสิทธิ์ แต่ในความเป็นจริง มันเป็นเพียงส่วนเล็กๆ ของสนาม CIAM (Customer Identity and Access Management) ที่กว้างกว่า สิ่งที่พวกเขาสร้างขึ้นจริงแล้วเป็นการรวมเซิร์ฟเวอร์ MCP (เชื่อมต่อ) — มีประโยชน์แต่เพียงเศษเสี้ยวของสิ่งที่ CIAM solutions ที่สมบูรณ์ประกอบด้วย
จากตัวอย่างก่อนหน้า ถ้าเราพิจารณา Google Drive (บริการระยะไกล) เป็นเซิร์ฟเวอร์ MCP แทนที่จะเป็น Airbnb มันกลายเป็นมากกว่าการผสานรวมของบุคคลที่สาม — หนนี้ทำหน้าที่เป็นแหล่งข้อมูลภายนอก ที่ให้ agent สามารถเข้าถึงข้อมูลทั้งที่มีบริบท ปฏิสัมพันธ์กับ LLM และอาจได้การอนุญาตให้สร้าง อ่าน อัปเดต และลบ (CRUD) ไฟล์
อย่างไรก็ตาม ความต้องการหลักในด้านการตรวจสอบสิทธิ์และการอนุญาตยังคงเหมือนเดิม
ใช้ Logto เพื่อจัดการการตรวจสอบสิทธิ์สำหรับผลิตภัณฑ์ผู้จัดจำหน่าย#
Logto คือโซลูชัน CIAM ที่หลากหลายที่สนับสนุนผลิตภัณฑ์ SaaS และผลิตภัณฑ์ ai agent ทำให้การตรวจสอบสิทธิ์และการอนุญาตเป็นไปอย่างราบรื่น นี่คือเหตุผล:
การจัดการการตรวจสอบสิทธิ์สำหรับผลิตภัณฑ์ ai agent – Logto สนับสนุน OAuth 2.0, SAML, คีย์ API, Personal Access Tokens, และ JWT ช่วยให้การเชื่อมต่อกับเซิร์ฟเวอร์ MCP หลายตัวเป็นเรื่องง่าย คุณสามารถสร้างเซิร์ฟเวอร์ MCP ของคุณเองและเชื่อมต่อกับ Logto ได้ด้วยแพลตฟอร์มที่เป็นมาตรฐานเปิด
ความสามารถของผู้ให้บริการอัตลักษณ์ (IdP) การอนุญาตขั้นสูง
การควบคุมการเข้าถึงโดยใช้บทบาท (RBAC) สำหรับการจัดการบทบาทของผู้ใช้
ABAC แบบกำหนดเองที่ใช้ JWT สำหรับการควบคุมการเข้าถึงที่ละเอียดอ่อนและเปลี่ยนแปลงได้
ความปลอดภัยที่เพิ่มขึ้น – คุณลักษณะที่เช่น การตรวจสอบสิทธิ์หลายปัจจัย (MFA) และการตรวจสอบสิทธิ์เพิ่มเติมช่วยปกป้องการดำเนินการที่สำคัญและปรับปรุงความปลอดภัยของตัวแทน
มีคำถาม? ติดต่อ
หน้าเชื่อมต่อของ Notion
อ้างอิง: