حكومة وكلاء AI: خمسة أركان تبنيها ولا تكتفي بكتابتها

ما الذي تقوم حكومة الوكلاء بإدارته فعلياً

تقوم جين، وهي مهندسة دعم، بكتابة جملة واحدة في مساعد الدعم: قم بإعداد ملخص المبالغ المستردة للتذكرة #4521. يمرر المساعد الطلب إلى وكيل التخطيط، والذي يستدعي بدور وكيل البحث (تذكرة Zendesk، وخطأ Jira المرتبط) ووكيل الفواتير (سجل دفع Stripe). طلب بشري واحد، وستة استدعاءات من جهاز إلى جهاز، معظمها جرى بواسطة برمجيات قررت من تلقاء نفسها استدعاء المزيد من البرمجيات.

تلك السلسلة — المستخدم ← التطبيق ← الوكيل ← الوكيل الفرعي ← أداة MCP — هي مسار استدعاء الوكلاء (agentic call path)، وهو ما يجب أن تحكمه حوكمة الوكلاء. يعتمد كل نموذج وصول للمؤسسات على ثلاثة افتراضات: يقف المستخدم في مقدمة الطلب، والشخص الذي يجري الاستدعاء هو ذلك المستخدم، والنطاق هو ما وافق عليه المستخدم. بحلول القفزة الثالثة، تصبح جميع الافتراضات الثلاثة خاطئة، وبالتالي تتوقف ثلاثة أسئلة عن الحصول على إجابات:

• من هو الشخص الذي أُجري هذا الاستدعاء لأجله؟ تمت مصادقة المستخدم منذ ثلاث قفزات. هل لا تزال هويته موجودة في الطلب، أم حل محلها حساب خدمة؟
• من الذي يقوم بالاستدعاء؟ يثبت رمز الحامل (bearer token) حيازة الاعتماد، ولكن لا يحدد أي من وكلاءك المائتين يحتفظ به.
• ما الذي يُسمح له بفعله؟ إن الرمز المميز الذي تم إنشاؤه للمستدعى الأول يكون ذا صلاحيات مفرطة لكل مستدعى يليه.

إن الإجابة على هذه الأسئلة الثلاثة عند كل قفزة، مع وجود الأدلة، هو ما تعنيه حوكمة الذكاء الاصطناعي الوكيل (agentic AI governance) — خمسة أنظمة، وليست مجرد فقرة عن الاستخدام المسؤول.

الوكيل هو نوع ثالث من الكيانات الرئيسية

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

منح كل وكيل هويته الخاصة القابلة للتحقق هو القرار الذي تعتمد عليه بقية الأمور. فهو يوفر الإسناد (attribution)، لأن المتلقي يمكنه تحديد أي وكيل قام بالاستدعاء؛ وسياسة لكل وكيل، لأن مساعد جين الذي يقرأ Jira ووكيلها الهندسي الذي يكتب فيه هما كيانات مختلفة حتى لو كان كلاهما يعمل لصالح جين؛ وعدم وجود وكلاء مجهولين، لأن الأداة التي لا يمكن الوصول إليها إلا عبر هوية مسجلة تجعل التسجيل هو نقطة الإنفاذ.

إن الحاجة الماسة ليست أمراً استعراضياً: فالهويات الآلية تفوق عدد المستخدمين البشر في معظم المؤسسات بنسبة تزيد عن 40 إلى 1، وتتكاثر الوكلاء بشكل أسرع مما كانت عليه حسابات الخدمة — أي شخص لديه إطار عمل ومفتاح API يمكنه إنشاء واحد.

الأركان الخمسة

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

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

لماذا البوابة، وليس موفر الهوية (IdP)

يمكن أن يعيش كل ركن في أداة مختلفة. ما يربط النموذج معاً هو الإنفاذ عند بوابة على مسار الاستدعاء — المكون الوحيد الذي يرى كل قفزة بغض النظر عن إطار العمل أو السحابة، وينقل الهوية للأمام، ويضيق السلطة في كل خطوة، ومستقل عن المنصات. تحكم Entra وكلاء Entra، وتحكم Okta تطبيقات Okta، وتحكم Bedrock وكلاء Bedrock؛ لكن البوابة تحكم المسار عبر جميع هذه المنصات، وهو المكان الذي تكمن فيه المخاطر — وهي نقطة نطورها في حوكمة وكلاء AI عبر منصات متعددة. إن موفر الهوية بدون بوابة يصدر أوراق اعتماد مثالية يتم تمريرها بعد ذلك دون قيود؛ والسجل بدون بوابة ليس سوى وثائق.

أين تخطئ الفرق

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

تمرير رمز مميز قوي واحد في كل مكان. أسرع طريقة لجعل الاستدعاءات تعمل وأسرع طريق للتعرض للاختراق. يمكن إغراء الوكلاء عبر prompt injection لإساءة استخدام أي اعتماد يحملونه، لذا يجب ألا يكون أوسع مما تحتاجه القفزة التالية.

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

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

هل تريد هذا كنظام يعمل بدلاً من مجرد مخطط؟

قم بتسجيل وكيل، وامنحه هوية، وامنحه خادم MCP واحداً.

ابدأ مجاناً

الجزء الصعب: إجابتان على سؤال "من قام بهذا؟"

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

بالنسبة للوكلاء، فأنت تريد تقريباً التفويض دائماً. يحتفظ الرمز المفوض بالمستخدم كـ sub ويسمي الفاعل في act؛ وتعمل الاستدعاءات المتسلسلة على تضمين المطالبات داخل بعضها، حيث يكون الأطراف الأكثر خارجية هم أحدث الفاعلين:

مطالبتان مكملتان تقسمان المهمة. may_act هي البوابة الموجهة للمستقبل — هل يمكن لهذا الفاعل أن يعمل لصالح هذا الموضوع — ويتم التحقق منها قبل إنشاء الرمز المميز. أما act فتسجل من قام بالفعل. قم بالتفويض بناءً على الفاعل الحالي بالإضافة إلى الموضوع بالإضافة إلى السياسة؛ واحتفظ بالسلسلة المتداخلة للتحقيقات الجنائية الرقمية.

الآلية المتبعة تحت ذلك هي تبادل الرموز المميزة (token exchange). يحدد RFC 8693 ذلك: تقديم رمز الموضوع ورمز الفاعل اختيارياً، واستلام رمز جديد مخصص لنطاق الجمهور المستهدف. يطلق الموردون على ذلك اسم On-Behalf-Of. هناك خاصية واحدة تستحق الحفظ — التبادل لا يضخم السلطة أبداً. يمنح الرمز الصادر تقاطع ما يمكن للمستخدم فعله، وما يمكن للوكيل فعله، وما يقبله الهدف، لذا فإن كل قفزة تكون مقيدة أكثر من التي قبلها. عبر مجالات الثقة، تتولى منحة ID-JAG الخاصة بـ IETF (المعروفة بـ Cross App Access في Okta) المهمة، حيث تصدر منحة قصيرة الأجل عند موفر الهوية الخاص بك يستردها خادم التفويض الخاص بالهدف.

كيف يعمل هذا في TrueFoundry

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

السجل

يحصل كل وكيل على إدخال، بغض النظر عن النظام الذي يعمل عليه — Bedrock, Vertex, LangGraph، خدمة HTTP مخصصة، وكيل A2A، أو مساعد في برنامج SaaS لشخص آخر. لا شيء ينقل، ولا شيء يعاد كتابته.

التسجيل عبارة عن معالج من أربع خطوات: البيانات الوصفية (Metadata)، هوية الوكيل (Agent Identity)، التكوين (Config)، والتحكم في الوصول (Access Control).

الهوية

تحدد الخطوة الثانية كيفية إثبات الوكيل لهويته. المدعوم من TrueFoundry يعني أن TrueFoundry تصدر الرمز وتوقعه، وهو الخيار الافتراضي الصحيح للوكلاء الذين تقوم بتشغيلهم بنفسك. المدعوم من موفر الهوية يعني أن الوكيل يقدم رمزاً من Okta, Entra، أو أي موفر OIDC، أو نقطة نهاية SPIFFE/SPIRE، مع تعيين قيم المطالبات للوكيل.

تحدد خطوة التكوين ما إذا كانت بوابة الوكيل (Agent Gateway) تقف في المقدمة. الوكيل عبر البوابة (Proxy via Gateway) يعني أن المستدعين يطرقون عنوان URL لـ TrueFoundry وتقوم البوابة بالمصادقة والإنفاذ التمرير. المضمن (Embedded) يعني الحوكمة فقط: هوية ومنح، بدون توجيه مسبق للطلبات الواردة. هذه هي الطريقة التي تحكم بها مساعداً داخل منتج لجهة خارجية — لا يمكنك التحكم في بابه الأمامي، ولكن استدعاءاته الخارجية ستظل تعبر بواباتك.

التحكم في وصول الوكلاء

الوصول قائم على القائمة المسموح بها؛ لا يوجد إعداد للرفض، لأن الغياب هو الرفض تلقائياً. يمكن أن يكون المشاركون مستخدماً، أو فريقاً، أو وكيلاً آخر، مع صلاحية Agent Manager (العرض والتعديل) أو Agent Access (الاستدعاء، والعمل نيابة عنه). المالك هو حقل منفصل اختياري يجب أن يكون فريقاً — وهو مرساة المساءلة.

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

الاتجاه الآخر يعمل بنفس الطريقة تماماً: أضف الوكيل كمشارك في كل خادم MCP أو نموذج، مع الموضوع agent:<name>، في نفس المنتقي المستخدم للمستخدمين والفرق.

لحظر وكيل على مجموعة فرعية من أدوات الخادم، قم بتنسيق تلك المجموعة الفرعية كـ Virtual MCP Server وامنح الوصول إليها بدلاً من ذلك؛ ميزة تحديد نطاق الأدوات لكل وكيل بناءً على المنح قادمة قريباً.

حواجز الحماية، عند كل قفزة

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

الحد الأدنى القابل للعمل: إعادة صياغة معلومات PII وكشف prompt-injection على مدخلات LLM، وكشف الأسرار على المخرجات، ومنظف SQL ومطابق معايير سلامة الأكواد قبل استخدام الأداة، وإعادة الصياغة بعد الاستخدام. ابدأ كل قاعدة في وضع التدقيق (Audit)، ثم قم بالترقية — فقفزة حظر واحدة يمكن أن تفشل سلسلة بأكملها.

التدقيق

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

يظهر كل حاجز حماية تم تشغيله كنطاق (span) مستقل: ما تم الفحص عنه، وهل نجح، وما الذي تم العثور عليه أو تعديله. تسجل الطلبات المحظورة أيضاً — فالقفزة المرفوضة هي دليل وليست ثغرة.

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

مثال عملي

حوكمة مساعد ملخص المبالغ المستردة المذكور في بداية هذا المقال.

تسجيل الوكلاء. يحصل كل من وكيل التخطيط، ووكيل البحث، ووكيل الفواتير على إدخال يحتوي على الوصف وفريق المالك. يتم تسجيل مساعد المورد كـ Embedded — بدون عنوان URL، حوكمة فقط، ولكن استدعاءاته الخارجية أصبحت الآن محكومة.

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

منح أقل صلاحية، في كلا الاتجاهين. في وكيل البحث، أضف فريق الدعم بصلاحية Agent Access — لتحديد من يمكنه استدعاؤه ومن يمكنه العمل نيابة عنه. ثم أضف agent:research-agent كمشارك في خوادم Zendesk و Jira MCP، ولا شيء غير ذلك. ويحصل وكيل الفواتير على Stripe. لا يمكن لأي منهما الوصول إلى أدوات الآخر، لأن غياب المنح يعني 403.

حمل الهوية في كل استدعاء. يحمل الاستدعاء المفوض رمزي حامل (bearer tokens): المستخدم في Authorization، والوكيل في x-tfy-agent-authorization. يستبدل كل وكيل رأس الوكيل الخاص به ويمرر رمز المستخدم، لذلك تتحقق البوابة من كل قفزة مقابل الوكيل الذي يجريها بالفعل.

تشغيل حواجز الحماية والمراقبة. ارفق كشف prompt-injection بالنماذج وتعديل ما بعد الأداة بالخوادم، ثم تأكد في تتبعات الطلبات من أن استدعاء research-agent يظهر research-agent كـ مستدعي و جين كـ مستخدم تم العمل نيابة عنه.

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

هل أنت مستعد لوضع وكيل خلف نقطة إنفاذ حقيقية؟

قم بتسجيله، وتحديد نطاقه لخادم MCP واحد، واقرأ التتبع.

ابدأ مجاناً على TrueFoundry

مشاكل غير متوقعة يجدر معرفتها

لا يمكن للوكيل إكمال تدفق كود تفويض OAuth2. لا يوجد عنصر بشري للموافقة على شاشة الموافقة، وسيصبح الرمز ملكاً لذلك الشخص على أي حال. يعيد مثل هذا الخادم خطأ MCP server authentication required لرمز الوكيل حتى عندما يكون الوكيل مشاركاً. استخدم اعتماد العميل (client credentials) بدلاً من ذلك.

تتخطى حواجز الحماية الخاصة بالمخرجات الاستجابات المتدفقة (streamed responses). فهي تحتاج إلى الاستجابة الكاملة للتقييم، لذلك بالنسبة لخطوات الوكيل التي تغذي مخرجاتها استدعاء أداة، يُفضل استخدام stream: false.

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

قراءات ذات صلة

• حوكمة وكلاء AI عبر منصات متعددة — عندما تتوقف الحوكمة عند حافة المنصة
• هندسة الرسوم البيانية لوكلاء AI — تقييم العقدة مقابل حوكمة الحواف
• التحكم في الوصول إلى MCP باستخدام بوابة MCP — أذونات على مستوى الأدوات والخوادم
• RBAC مقابل ABAC لوكلاء AI — نموذج الوصول الموجود أسفل المنح
• بناء إطار عمل حوكمة الذكاء الاصطناعي — الصورة العامة للسياسة بشكل أوسع

الخاتمة

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

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

قم بحوكمة وكيلك الأول على TrueFoundry

البدء مجاني