هوية وكيل الذكاء الاصطناعي: منح كل وكيل هوية غير بشرية

ما هي هوية وكيل الذكاء الاصطناعي؟

هوية وكيل الذكاء الاصطناعي هي اعتماد قابل للتحقق يقدمه الوكيل المسجل في كل مكالمة يجريها. إنها تجيب على سؤال لا يمكن للرموز (tokens) وحدها الإجابة عليه: ليس "هل تم تقديم اعتماد صالح"، بل "أي وكيل يتصل، ولمن يعمل في هذه اللحظة".

تتعرف TrueFoundry بالفعل على نوعين من الموكلين، وتعتبر هوية الوكيل النوع الثالث.

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

الهوية غير البشرية، ولماذا تعتبر فئة مستقلة

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

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

لماذا يحتاج كل وكيل إلى هويته الخاصة

إن منح كل وكيل هوية مميزة هو قرار واحد يفتح الباب أمام نموذج الحوكمة بالكامل.

• النسب (Attribution). يمكن للمتلقي معرفة ما إذا كان المتصل بشراً، أو خدمة، أو وكيلاً محدداً. تصبح الإجراءات قابلة للإثبات بعد وقوعها، وهو ما يتطلبه التدقيق الفعلي.
• سياسة خاصة بكل وكيل. يدير شخص واحد العديد من الوكلاء، ولا ينبغي لهم جميعاً أن يرثوا كامل صلاحيات ذلك الشخص. إن مساعد "جين" للدعم الذي يقرأ Jira ووكيلها الهندسي الذي يكتب فيه هما موكلان مختلفان، على الرغم من أن كلاهما يعمل لصالح "جين". تتيح لك الهويات المميزة تحديد نطاق صلاحيات كل منهما بشكل مختلف.
• لا وجود لوكلاء مجهولين. إذا كان الوكيل لا يستطيع الوصول إلى أداة إلا من خلال تقديم هوية مسجلة، فإن التسجيل يصبح نقطة الإنفاذ. ستحصل على جرد على مستوى المؤسسة بالكامل مجاناً، ويمكنك إلغاء صلاحية وكيل واحد مارق دون التأثير على البقية.

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

كيف تصدر TrueFoundry هوية الوكيل وتديرها

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

‍

لقطة شاشة للمنتج من وثائق TrueFoundry: خطوة "هوية الوكيل" (Agent Identity) أثناء تسجيل الوكيل.

مصدر بيانات الاعتماد

أثناء التسجيل، يمكنك اختيار الطريقة التي يثبت بها الوكيل هويته:

‍

• مدعومة من TrueFoundry. تقوم TrueFoundry بإصدار وتوقيع رمز الوكيل المميز. هذا هو الخيار الأبسط وهو الإعداد الافتراضي المناسب للوكلاء الذين تقوم ببنائهم وتشغيلهم بنفسك.
• مدعومة من مزود الهوية. يقوم الوكيل بالمصادقة باستخدام رمز مميز من مزود الهوية الخاص بك، مثل Okta أو Microsoft Entra أو أي مزود OIDC أو نقطة نهاية SPIFFE وSPIRE. يمكنك تعيين قيم مطالبات محددة للوكيل بحيث يتم ربط الرمز المميز الوارد به. يتيح هذا المسار تفويض "النيابة عن" (OBO)، مما يسمح للوكيل بنقل المستخدم عبر سلسلة العمليات.

‍

الهوية تعني الشيء نفسه في كلتا الحالتين. الاختلاف يكمن فقط في جهة الإصدار، ويمكنك الجمع بين جهات إصدار مختلفة لكل وكيل داخل مستأجر واحد.

TrueFoundry كوسيط للهوية

عندما لا يمتلك مزود الهوية الخاص بك إمكانية تحديد هوية الوكيل بعد، يمكن لـ TrueFoundry القيام بأدوار مستوى التحكم الثلاثة. فهي تصدر هوية كل وكيل، وتصرح بكل استدعاء عند بوابة الوكيل (Agent Gateway) وبوابة MCP، وتقوم، من خلال تبادل الرموز المميزة، بإنشاء بيانات اعتماد محددة النطاق لكل خطوة. يستمر نظام تسجيل الدخول الموحد (SSO) الخاص بمؤسستك في أداء وظيفته المعتادة، وهي مصادقة المستخدمين البشريين. عند إجراء استدعاء، يقدم الوكيل هويته الخاصة إلى جانب هوية المستخدم، بحيث تظهر كلتا الهويتين في نفس الوقت:

‍

curl https://gateway.truefoundry.ai/api/llm/chat/completions \

  -H "Authorization: Bearer $USER_TOKEN" \

  -H "x-tfy-agent-authorization: $AGENT_TOKEN" \

  -H "Content-Type: application/json" \

  -d '{

        "model": "openai-main/gpt-4o",

        "messages": [{"role": "user", "content": "لخّص مشكلاتي المفتوحة"}]

      }'

‍

يجلب الوكيل رمزه المميز (Token) الخاص به من السجل (عبر إجراء "الحصول على الرمز" في الوكيل)، تماماً كما يفعل الحساب الافتراضي.

من يحق للوكيل التصرف نيابةً عنه

التفويض ليس مطلقاً، بل مقيد بمتعاوني الوكيل الذين يتم تحديدهم في خطوة "التحكم في الوصول" عند التسجيل. القائمة نفسها التي تحدد من يمكنه استدعاء الوكيل هي التي تحدد أيضاً من يمكن للوكيل التصرف نيابةً عنهم.

‍

لقطة شاشة للمنتج، وثائق TrueFoundry: متعاونو الوكيل وأدوارهم.

‍

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

‍