https://thedotnetblog.com/ar/tags/agent-governance-toolkit/Articles, tutorials and insights from the .NET community.Hugoar@thedotnetblog (The .NET Blog)@thedotnetblogThu, 21 May 2026 00:00:00 +0000https://thedotnetblog.com/ar/news/emiliano-montesdeoca/agent-governance-toolkit-mcp-extensions-dotnet/Thu, 21 May 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ar/news/emiliano-montesdeoca/agent-governance-toolkit-mcp-extensions-dotnet/تأخذ امتدادات Agent Governance Toolkit الجديدة لـ MCP في .NET فرض السياسات، والفحص عند بدء التشغيل، وتنقية الاستجابات، وتضعها مباشرة ضمن مسار بناء خادم MCP. هذا بالضبط نوع القصة الآمنة افتراضيًا التي أريد رؤيتها.<blockquote> <p><em>تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، <a href="https://thedotnetblog.com/ar/news/emiliano-montesdeoca/agent-governance-toolkit-mcp-extensions-dotnet/">انقر هنا</a>.</em></p> </blockquote> <p>واحدة من أكبر المشكلات في أدوات الوكلاء حاليًا هي أن المسار السعيد غالبًا ما يكون المسار غير الآمن.</p> <p>يمكنك تشغيل خادم MCP. يمكنك عرض الأدوات بسرعة. يمكنك جعل العرض التوضيحي يعمل.</p> <p>ثم تصل الأسئلة المزعجة مباشرة بعد ذلك:</p> <ul> <li>من المسموح له باستدعاء ماذا؟</li> <li>ماذا يحدث إذا كانت بيانات الأداة الوصفية خبيثة أو مضلِّلة؟</li> <li>ماذا لو تدفّقت مخرجات غير آمنة مباشرة إلى النموذج؟</li> <li>كم من هذا سياسة، وكم منه مجرد عُرف؟</li> </ul> <p>لهذا السبب تُهمّ امتدادات <strong>Agent Governance Toolkit الجديدة لـ MCP في .NET</strong>.</p> <p>هي لا تحل كل مشكلة أمنية في نظام الوكلاء البيئي، لكنها تفعل شيئًا مهمًا جدًا: تجعل مسار بناء .NET الافتراضي أسهل بكثير في التحصين.</p> <h2 id="أهم-جملة-في-الإعلان">أهم جملة في الإعلان</h2> <p>يقول المنشور المصدري إن الحزمة تضيف &ldquo;<strong>حوكمة بنداء واحد</strong>&rdquo; (one-call governance) إلى <code>IMcpServerBuilder</code>.</p> <p>هذه هي العبارة بالضبط التي سأركّز عليها.</p> <p>لأن معظم الفرق لا تفشل في بناء حوكمة الوكلاء بسبب نقص الوعي. إنها تفشل لأن المسار الآمن يعني عملًا أكثر، وأسلاكًا أكثر، وكودًا مخصصًا أكثر، وفرصًا أكثر لتأجيل التنظيف إلى وقت لاحق.</p> <p>و&quot;لاحقًا&quot; هو المكان الذي تحب فيه المخاطر أن تعيش.</p> <h2 id="لماذا-هذه-قصة-جيدة-لـ-net">لماذا هذه قصة جيدة لـ .NET</h2> <p>ما يعجبني هنا هو مدى طبيعية اندماج الحزمة مع نموذج البناء (builder) الحالي.</p> <p>بدلاً من إجبار الفرق على:</p> <ul> <li>سيرفس جانبي (sidecar)</li> <li>وكيل منفصل (proxy)</li> <li>بنية غلاف مخصصة</li> <li>أو حزمة تطوير بديلة غريبة</li> </ul> <p>تُوسّع الحزمة مسار بناء MCP الرسمي بلغة C# مباشرة.</p> <p>هذا مهم جدًا.</p> <p>إذا تطلّب الأمان بهلوانيات معمارية، ينخفض التبني فورًا. أما إذا بدا الأمان جزءًا طبيعيًا من إعداد الخادم، يصبح التبني أكثر واقعية بكثير.</p> <h2 id="نموذج-التهديد-لم-يعد-نظريا">نموذج التهديد لم يعد نظريًا</h2> <p>شيء واحد لا أعتقد أن الفرق يجب أن تُقلّل من شأنه هو مدى سرعة تحوّل المخاطر المتعلقة بـ MCP إلى واقع في أنظمة الإنتاج.</p> <p>يطرح المقال المصدري أسئلة مثل:</p> <ul> <li>&ldquo;<strong>هل يجب أن تكون كل أداة مسجَّلة قابلة للاستدعاء من قِبل كل وكيل؟</strong>&rdquo;</li> <li>&ldquo;<strong>ماذا يحدث إذا تضمّن وصف الأداة تعليمات على غرار حقن الأوامر (prompt injection)؟</strong>&rdquo;</li> </ul> <p>هذه بالضبط الأسئلة الصحيحة.</p> <p>لأنه بمجرد أن تصبح الأدوات سطح التنفيذ للوكلاء، لم يعد النظام مجرد مولّد نصوص. إنه يتخذ قرارات يمكن أن تترتب عليها عواقب أمنية وموثوقية وحوكمة.</p> <p>هذا يغيّر معيار الحكم.</p> <h2 id="ما-تصيبه-الحزمة-بدقة">ما تُصيبه الحزمة بدقة</h2> <p>أقوى خيار تصميمي في هذا الامتداد هو أنه يجمع طبقات أمنية متعددة في مسار واحد متماسك:</p> <ul> <li>فحص عند بدء التشغيل لتعريفات الأدوات غير الآمنة</li> <li>فرض السياسات عند التنفيذ</li> <li>حوكمة واعية بالهوية</li> <li>تنقية الاستجابات قبل تدفّق المحتوى مرة أخرى إلى العميل أو النموذج</li> <li>ربط بالتدقيق والمقاييس</li> </ul> <p>هذا هو الشكل الصحيح.</p> <p>ليس &ldquo;وضع أمان&rdquo; واحدًا ضخمًا. بل مجموعة من الضوابط المحددة التي تغطي نقاط فشل مختلفة عبر دورة الحياة.</p> <h3 id="الفحص-عند-بدء-التشغيل-أهم-مما-تدرك-كثير-من-الفرق">الفحص عند بدء التشغيل أهم مما تدرك كثير من الفرق</h3> <p>يعجبني بشكل خاص أن بيانات الأداة الوصفية غير الآمنة يمكن أن تُفشل بدء التشغيل بشكل افتراضي.</p> <p>هذا رأي قوي، وأعتقد أنه الرأي الصحيح.</p> <p>كلما استطعت حظر تعريف أداة مسمومة أو مشبوهة مبكرًا، كان ذلك أفضل. الانتظار حتى وقت التشغيل يكون بالفعل متأخرًا جدًا بالنسبة لفئة كاملة من المشكلات.</p> <h3 id="تنقية-الاستجابات-طبقة-عملية-جدا-أيضا">تنقية الاستجابات طبقة عملية جدًا أيضًا</h3> <p>نقطة أخرى غير مقدَّرة بما يكفي في الإعلان هي التركيز على تنقية المخرجات.</p> <p>فرق كثيرة تفكر في المدخلات الخطرة.</p> <p>قليل منها يفكر بعناية كافية في المخرجات الخطرة العائدة من أداة ما والتي تُسلَّم مباشرة إلى حلقة الوكيل.</p> <p>هذا مكان سهل للوقوع فيه.</p> <h2 id="ما-سأظل-حذرا-بشأنه">ما سأظل حذرًا بشأنه</h2> <p>على الرغم من إعجابي الكبير بهذه الحزمة، سأظل حذرًا بشأن أمر واحد: أدوات الحوكمة لا تعمل إلا إذا حدّدت الفرق فعليًا سياسات ذات معنى وحافظت عليها.</p> <p>يجعل الامتداد ربط الآلية أسهل. هذا رائع.</p> <p>لكن الفرق لا تزال بحاجة إلى القيام بالعمل التنظيمي الأصعب المتمثل في تحديد:</p> <ul> <li>الأدوات المسموح بها</li> <li>الوكلاء أو الهويات المسموح لها بالاستدعاء</li> <li>ماذا يعني &ldquo;الرفض افتراضيًا&rdquo; فعليًا في بيئتهم</li> <li>كيفية التعامل مع الإيجابيات الكاذبة والاستثناءات</li> </ul> <p>لذا سأتعامل مع هذه الحزمة كطبقة إنفاذ قوية، وليست بديلاً عن الحكم المعماري.</p> <h2 id="رأيي">رأيي</h2> <p>هذا واحد من أوضح إعلانات وكلاء .NET <strong>الآمنة افتراضيًا</strong> التي رأيتها منذ فترة.</p> <p>ليس لأنه يَعِد بالسحر، بل لأنه يأخذ فئة من العمل الأمني كانت الفرق على الأرجح ستُنفّذه بشكل غير متسق، ويمنحها موطنًا أنظف وأكثر طبيعية في مسار البناء.</p> <p>هذا بالضبط نوع الحزمة الذي أريده في هذا النظام البيئي.</p> <p>إنه لا ينهي الحوار الأوسع حول الحوكمة. لكنه يفعل شيئًا أكثر عملية: يجعل من الصعب جدًا التظاهر بأن الحوكمة يجب أن تكون مهمة تنظيف لشخص آخر لاحقًا.</p> <p>وهذا تقدّم حقيقي.</p> <p>المصدر الأصلي: <a href="https://devblogs.microsoft.com/dotnet/announcing-agent-governance-toolkit-mcp-extensions-for-dotnet/">Announcing Agent Governance Toolkit MCP Extensions for .NET</a></p>