ربط العميل البشري بعميل الذكاء الاصطناعي: دليل تقني

النقاط الرئيسية

• لا يتم حل مشكلة معرفة عميلك (KYA) عن طريق تسمية العميل. التحكم الدائم هو سلسلة تفويض تربط شخصًا موثقًا، وعميلًا مسجلًا، ونطاقات ممنوحة، وسياق مؤسسي، وكل إجراء ناتج.
• نقطة نهاية بروتوكول سياق النموذج (MCP) المستضافة من Didit تعرض 115 أداة عبر 19 نطاقًا وتستخدم Open Authorization (OAuth) 2.1 مع Proof Key for Code Exchange (PKCE) وتسجيل العميل الديناميكي.
• يعمل MCP كمستخدم Didit الذي قام بتسجيل الدخول. ويرث دور هذا المستخدم في المؤسسة، بحيث لا يمكن للعميل المتصل الحصول على أذونات لم يكن الشخص يمتلكها بالفعل.
• مفتاح التطبيق المخزن في ملف التكوين يثبت حيازة بيانات الاعتماد، وليس من فوض إجراءً معينًا. المفاتيح المشتركة تجمع عدة مشغلين وعملاء في هوية تطبيق واحدة.
• تتطلب المساءلة كلاً من التنفيذ والأدلة: رموز مميزة محددة النطاق وفحوصات الدور قبل الإجراء، ثم سجلات تدقيق توضح من غيّر ماذا.

لقد قامت Didit بالفعل بتوفير الآلية. يقوم خادم MCP المستضاف بربط عميل الذكاء الاصطناعي بعمليات الهوية والاحتيال من خلال مستخدم قام بتسجيل الدخول، بدلاً من التعامل مع العميل كحامل مجهول لسر التطبيق. نقطة النهاية مجانية، وتستخدم Streamable HTTP عديمة الحالة، وتكشف عن 115 أداة. التنفيذ متاح أيضًا في مستودع GitHub العام المرخص بموجب MIT.

هذه القطعة الأثرية تغير السؤال المفيد. بدلاً من طلب تعريف آخر لـ KYA، اسأل: عندما يقوم عميل بإنشاء جلسة تحقق، أو قراءة قرار، أو تغيير بيانات مساحة العمل، فما الذي يثبت من قام بتفويضه، وماذا سمح هذا الشخص، وأي مؤسسة قبلت الإجراء؟

الربط البشري هو سلسلة تفويض

يمكن أن يساعد اسم العميل أو معرف النموذج أو المفتاح العام أو إثبات البرنامج في تحديد الجهة الفاعلة للآلة. لا شيء منها، بمفردها، يحدد من هو المسؤول عما يفعله العميل. يحتاج الربط البشري إلى سلسلة ذات روابط مميزة:

• الرئيسي: المستخدم الموثق أو مالك الخدمة الذي يتصرف العميل نيابة عنه.
• العميل: تطبيق الذكاء الاصطناعي الذي طلب الوصول.
• التفويض: النطاقات والموافقة الممنوحة لهذا العميل.
• سياق التفويض: دور المؤسسة وحدود التطبيق المطبقة على الطلب.
• الدليل: سجل قابل للمراجعة للإجراء ونتيجته.

يجيب كل رابط على سؤال مختلف. المصادقة تخبر من قام بتسجيل الدخول. OAuth تخبر أي عميل تلقى وصولاً مفوضًا. النطاقات تخبر أي فئات من العمليات تمت الموافقة عليها. الأدوار تخبر ما يمكن للمستخدم فعله داخل المؤسسة. سجلات التدقيق تخبر ما حدث بالفعل. يؤدي دمج هذه الضوابط في شارة "عميل موثق" واحدة إلى إخفاء الجزء الأكثر أهمية: السلطة سياقية وقابلة للإلغاء.

العميل الجدير بالثقة ليس مجرد قابل للتحديد. يجب أن يكون قادرًا على إظهار مسار غير منقطع من رئيس مسؤول إلى إجراء محدد ومسموح به.

لماذا يفشل المفتاح في ملف التكوين في اختبار المساءلة

يمكن أن يكون مفتاح API للتطبيق مناسبًا للتكامل المتحكم فيه بين الخادم والخادم. إنه ليس، بحد ذاته، آلية ربط بين الإنسان والعميل. يجيب المفتاح المنسوخ عادة على سؤال واحد: "هل يمتلك هذا المتصل بيانات اعتماد مقبولة لهذا التطبيق؟" لا يجيب على من أطلق العميل، أو من وافق على المهمة الحالية، أو ما إذا كانت مكالمتان تستخدمان نفس المفتاح قد أتت من أشخاص مختلفين.

أوضاع الفشل يمكن التنبؤ بها. تشارك الفرق مفتاحًا عبر البيئات المحلية. يرث عملية عميلها من ملف تكوين. يتلقى عميل ثانٍ نسخة. ثم تعزو السجلات كل مكالمة إلى نفس بيانات اعتماد التطبيق. يؤدي إلغاء بيانات الاعتماد هذه إلى تعطيل كل عبء عمل يستخدمها، مع ترك حدث التفويض الفردي غير واضح.

Didit لا يقدم عمداً مسار مفتاح التطبيق لنقطة نهاية MCP المستضافة. لا يزال بإمكان عمليات التكامل الخلفية استخدام واجهات برمجة تطبيقات REST الخاصة بـ Didit مع بيانات اعتماد التطبيق، ولكن الوصول عن بعد إلى MCP يتطلب تدفق OAuth للمستخدم. هذا الفصل مهم: تمثل بيانات اعتماد REST تكامل التطبيق؛ يمثل رمز MCP وصولاً مفوضًا من مستخدم قام بتسجيل الدخول.

OAuth 2.1، PKCE، وتسجيل العميل الديناميكي

OAuth هو بدائي التفويض في هذا التصميم. لا يمرر التدفق كلمة مرور المستخدم إلى العميل، ولا يضع سر منصة قابل لإعادة الاستخدام في تكوين MCP. بدلاً من ذلك، يحصل عميل الذكاء الاصطناعي على رمز وصول محدود بعد مصادقة المستخدم مع Didit والموافقة على الوصول.

1. تسجيل العميل

يتيح تسجيل العميل الديناميكي لعميل MCP المتوافق التسجيل لدى خادم تفويض Didit دون معرف عميل تم توفيره يدويًا مسبقًا. يمنح هذا خادم التفويض تسجيل عميل مميز يمكنه إصدار الوصول إليه. يحدد التسجيل عميل OAuth؛ ولا يضمن، بحد ذاته، أن برنامج العميل جدير بالثقة.

2. ربط استجابة التفويض بالعميل

ينشئ PKCE محققًا وتحديًا لمرة واحدة لمحاولة التفويض. يجب على العميل الذي يبدأ التدفق تقديم المحقق عند تبادل رمز التفويض. هذا يحد من قيمة الرمز المعترض لأن عملية أخرى لا يمكنها استرداده بدون المحقق.

3. المصادقة والموافقة

يقوم المستخدم بتسجيل الدخول إلى Didit Business Console، الذي يعمل كخادم تفويض، ويوافق على النطاقات المطلوبة. تعلن Didit عن didit:verification لعمليات التحقق و didit:management لإدارة مساحة العمل. يجب أن يطلب العميل النطاق المطلوب للمهمة فقط.

4. التحقق من صحة كل مكالمة

يتحقق خادم موارد MCP المستضاف من صحة رمز الحامل قبل إرسال استدعاء الأداة. ينتقل رمز المستخدم الذي تم التحقق منه وسياق المؤسسة مع الطلب إلى Didit. يقوم الخدمة النهائية بعد ذلك بتقييم الدور والأذونات الموجودة لهذا المستخدم. والنتيجة هي دلالات العمل كمستخدم، وليست هوية مستخدم خارق جديدة تم إنشاؤها للعميل.

يوثق دليل مصادقة MCP التدفق، بينما يشرح نظرة عامة على MCP نقطة النهاية المستضافة ونموذج العميل.

العمل كمستخدم يجعل السلطة واضحة

لنفترض أن مشغل امتثال يربط عميل ذكاء اصطناعي بـ Didit. يقوم العميل أولاً باستدعاء didit_context_get، الذي يعرض المؤسسات والتطبيقات التي يمكن للمستخدم الذي قام بتسجيل الدخول الوصول إليها. إذا كان لدى المستخدم مؤسسة وتطبيق واحد لا لبس فيهما، فيمكن حل السياق تلقائيًا. إذا كان هناك العديد من الخيارات المتاحة، فيمكن تضييق نطاق العملية إلى مؤسسة وتطبيق صريحين.

يمكن للعميل بعد ذلك استدعاء didit_session_create لإنشاء جلسة تحقق و didit_session_get_decision لاسترداد نتيجتها. هذه هي أسماء أدوات حقيقية ذات أولوية في المجال في كتالوج MCP الحالي. المستخدم الذي يفتقر إلى الإذن المطلوب لا يحصل عليه عن طريق ربط عميل؛ لا يزال يتم تطبيق نفس حدود تفويض المؤسسة.

هذا هو الاختلاف المركزي عن بيانات اعتماد التطبيق المشتركة. في نموذج OAuth، يصل الطلب كمستخدم معروف يعمل من خلال عميل مسجل بنطاقات معلنة. في نموذج المفتاح المشترك، يرى النظام النهائي بيانات اعتماد التطبيق، بينما يظل الإنسان والعميل خلف مكالمة معينة غير قابلين للتمييز ما لم يوفر مستوى تحكم منفصل هذا السياق.

قابلية التدقيق: من "من يمكنه التصرف؟" إلى "من فعل ماذا؟"

التفويض يمنع إجراءً خارج النطاق. تشرح قابلية التدقيق الإجراء بعد حدوثه. تعرض Didit didit_audit_log_list بحيث يمكن للمستخدم المصرح له فحص إدخالات تدقيق التطبيق التي تصف من غيّر ماذا. نظرًا لأن كل طلب MCP مستضاف يحمل رمز الحامل للمستخدم الذي قام بتسجيل الدخول وسياق المؤسسة الذي تم حله، يمكن عزو الإجراء إلى هذا المتصل بدلاً من عملية عميل مجهولة.

يجب أن يحافظ السجل الجنائي الكامل أيضًا على أدلة من جانب العميل. بالنسبة لمهام سير العمل عالية التأثير، سجل معرف تشغيل العميل، وتسجيل العميل، والنطاق المطلوب، والمؤسسة والتطبيق المستهدفين، واسم الأداة، والطابع الزمني، وحالة الموافقة، وتمثيل آمن للمدخلات والمخرجات. لا تسجل رموز الوصول أو حمولات الهوية الحساسة. يجب أن يكون مسار تدقيق المنصة وسجل تنفيذ العميل قابلين للارتباط دون تكرار الأسرار أو البيانات الشخصية المنظمة.

الإسناد ليس هو نفسه عدم التنصل، وسجل التدقيق ليس بديلاً عن الحد الأدنى من الامتيازات. تعزز الضوابط بعضها البعض:

• استخدم الوصول قصير الأجل والتحديث المتحكم فيه بدلاً من بيانات الاعتماد المشتركة الدائمة.
• امنح أضيق نطاق OAuth وأقل دور مؤسسي امتيازًا.
• تتطلب تأكيدًا بشريًا للعمليات المدمرة أو ذات التأثير العالي بشكل غير عادي.
• حافظ على سياق المؤسسة والتطبيق صريحًا عندما يتوفر أكثر من هدف واحد.
• قم بإلغاء جلسة المستخدم أو منح العميل عند انتهاء التفويض.
• راقب سجلات التدقيق بحثًا عن الجهات الفاعلة أو الأدوات أو الأهداف أو التوقيت غير المتوقع.

ما يثبته الربط—وما لا يثبته

يثبت هذا النمط أن حساب Didit موثق فوض وصولاً محدود النطاق إلى عميل OAuth وأن كل طلب يتم تقييمه بأذونات مؤسسة هذا المستخدم. إنه يخلق مساءلة عملية لحساب وسلسلة قابلة للمراجعة لإجراءات المنصة.

لا يثبت تلقائيًا أن صاحب الحساب لديه هوية مدنية موثقة، أو أن ثنائي العميل المعتمد لم يتم تعديله، أو أن الإنسان يراقب بنشاط كل خطوة. تتطلب هذه الأمور ضمانات إضافية. إذا كانت ضمانات الهوية القانونية ضرورية، فتحقق من الرئيسي أثناء الإعداد باستخدام ضوابط معرفة عميلك (KYC) واربط هذه النتيجة بالحساب. إذا كانت أصل البرنامج مهمًا، فأضف إثبات العميل والإصدارات الموقعة. إذا كانت الحضور مهمة، فاطلب موافقة تصعيد في لحظة الإجراء الحساس.

هذا المنظور متعدد الطبقات يحافظ على صدق KYA. هوية العميل، هوية الإنسان، التفويض المفوض، سياسة وقت التشغيل، وأدلة التدقيق هي ضوابط ذات صلة، وليست تسميات قابلة للتبديل.

تطبيق عملي يمكنك فحصه

يوفر تطبيق Didit مرجعًا ملموسًا للفرق التي تصمم نفس حدود المساءلة. يصادق الخادم المستضاف كمستخدم Didit الذي قام بتسجيل الدخول، ويرث دور هذا المستخدم في المؤسسة، ويطبق هذه الهوية على كل استدعاء أداة. تشمل أدواته المستضافة البالغ عددها 115 أداة 19 نطاقًا، من سياق وجلسات التحقق إلى مهام سير العمل والمؤسسات والتحليلات وسجلات التدقيق. يسرد كتالوج الأدوات الحالي السطح الدقيق.

للسياق المتعلق بالمنتج، تبلغ تكلفة حزمة KYC الكاملة 0.33 دولار وتجمع بين التحقق من الهوية، والتحقق من الحيوية السلبية، ومطابقة الوجه، وتحليل IP. تتضمن Didit 500 عملية تحقق مجانية شهريًا وتستخدمها أكثر من 2000 شركة في الإنتاج. خادم MCP نفسه مجاني، لذا يمكن للفرق تقييم نموذج التفويض والأذونات دون إضافة رسوم موصل منفصلة.

لمعرفة كيف تتناسب هذه الآلية مع مهام سير عمل العميل الأوسع، اقرأ كيف يعمل MCP للهوية والاحتيال لعملاء الذكاء الاصطناعي و مرجع أدوات Didit MCP.

اربط العميل قبل أن تثق في الإجراء

المشكلة الصعبة في هوية العميل ليست اختراع اسم دائم للبرنامج. إنها الحفاظ على المساءلة البشرية بينما يعبر البرنامج الواجهات ويتصرف بسرعة الآلة. يوفر OAuth 2.1 وصولاً مفوضًا. يحمي PKCE تبادل التفويض. يحدد تسجيل العميل الديناميكي العميل المتصل. تحد النطاقات وأدوار المؤسسة السلطة. تجعل سجلات التدقيق النتيجة قابلة للمراجعة.

يمكنك فحص البنية في مستودع Didit MCP، ومراجعة وثائق المصادقة، أو ربط Didit بـ Claude. الاختبار المفيد بسيط: لأي إجراء عميل مقترح، هل يمكنك تحديد المستخدم المسؤول، والعميل، والنطاق الممنوح، وحدود المؤسسة، وأدلة التدقيق الناتجة؟ إذا كان أي رابط مفقودًا، فإن العميل غير مرتبط بالكامل.