https://thedotnetblog.com/ar/tags/middleware/Articles, tutorials and insights from the .NET community.Hugoar@thedotnetblog (The .NET Blog)@thedotnetblogWed, 10 Jun 2026 00:00:00 +0000https://thedotnetblog.com/ar/news/emiliano-montesdeoca/fides-prompt-injection-deterministic-agent-security/Wed, 10 Jun 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ar/news/emiliano-montesdeoca/fides-prompt-injection-deterministic-agent-security/تكتسب قدرات FIDES الجديدة في Agent Framework أهميتها لأنها تنقل الدفاع ضد prompt injection بعيدًا عن الاستدلالات الحدسية ونحو سياسة قابلة للتنفيذ قائمة على المحتوى المسمى وفحوصات middleware.<blockquote> <p><em>تمت ترجمة هذه المقالة تلقائيًا. للنسخة الأصلية، <a href="https://thedotnetblog.com/ar/news/emiliano-montesdeoca/fides-prompt-injection-deterministic-agent-security/">انقر هنا</a>.</em></p> </blockquote> <p>غالبًا ما يبدو دفاع prompt injection وكأنه يقف على أرض غير ثابتة.</p> <p>تضيف system prompt أقوى. تضيف فلترًا. تضيف بعض قوائم السماح. وتأمل ألا يُفسد الإدخال الغريب التالي الافتراضات.</p> <p>لهذا السبب يثير <strong>FIDES</strong> الاهتمام.</p> <p>الجزء القوي في القصة أنه ينقل الأمان نحو شيء أكثر حتمية:</p> <ul> <li>تسميات على المحتوى</li> <li>انتقال التسميات عبر سير العمل</li> <li>فرض عبر middleware قبل تشغيل الأدوات ذات الصلاحيات</li> <li>حدود سياسة واضحة حول ما يمكن للسياق غير الموثوق التأثير فيه</li> </ul> <h2 id="المقال-الأصلي-مباشر-بالقدر-الصحيح">المقال الأصلي مباشر بالقدر الصحيح</h2> <p>يفتتح المقال بالقول إن prompt injection هو &ldquo;<strong>الخطر رقم 1 في OWASP LLM Top 10</strong>&rdquo;.</p> <p>جيد.</p> <p>أحب هذا النوع من الصراحة هنا، لأن كثيرًا من الفرق لا تزال تتعامل مع أمان الوكلاء كما لو كان قضية مستقبلية بدل أن يكون مشكلة تصميم تشغيلية حاضرة.</p> <p>ويتابع المقال بمقارنة عملية قوية: معظم الدفاعات الحالية حدسية، بينما يحاول FIDES نقل النظام نحو السياسة والفرض.</p> <p>هذا هو التحول الصحيح تمامًا.</p> <h2 id="ما-الذي-يجعله-أكثر-إقناعا-من-ورقة-بيضاء-أمنية-أخرى">ما الذي يجعله أكثر إقناعًا من ورقة بيضاء أمنية أخرى</h2> <p>كثير من الكتابات عن أمان الذكاء الاصطناعي تبقى مجردة.</p> <p>هذا المقال يفعل شيئًا أفضل. فهو يمر عبر مثال شديد الواقعية: وكيل فرز GitHub issues، ونص issue خبيث، وقراءة ملف بصلاحيات أعلى، ومحاولة تسريب تعليق عام.</p> <p>هذا مفيد لأنه يربط النقاش كله بسير عمل حقيقي.</p> <p>ومتى ما رأيت هذا السيناريو، تصبح قيمة الضوابط الحتمية أسهل بكثير في الفهم.</p> <h2 id="الفكرة-الأساسية-ليست-اجعل-النموذج-أذكى">الفكرة الأساسية ليست &ldquo;اجعل النموذج أذكى&rdquo;</h2> <p>أهم ما في الأمر هنا أن FIDES لا يطلب من النموذج أن يصبح أفضل سحرًا في اكتشاف الهجمات.</p> <p>إنه يغيّر عقد وقت التشغيل.</p> <p>هذا يعني:</p> <ul> <li>يتم تعليم المحتوى</li> <li>تنتقل التسميات</li> <li>تصرّح الأدوات بما تقبله</li> <li>يحظر middleware المسارات غير الآمنة قبل التنفيذ</li> </ul> <p>هذا نهج أفضل بكثير.</p> <p>لأنه بمجرد أن يصبح الوكيل قادرًا على استدعاء أدوات لها عواقب حقيقية، لا يمكن للأمان أن يعتمد فقط على ما إذا كان النموذج في يوم جيد أم لا.</p> <h2 id="وجهة-نظري">وجهة نظري</h2> <p>هذا بالضبط نوع الاتجاه في أمان الوكلاء الذي أريد رؤيته أكثر.</p> <p>ليس &ldquo;ثق بالنموذج ليتجاهل التعليمات السيئة&rdquo;، بل &ldquo;ابنِ سياج السياسة داخل وقت التشغيل&rdquo;.</p> <p>هذا نموذج أكثر صحة بكثير.</p> <p>وإذا كانت أطر الوكلاء تريد أن تؤخذ بجدية في الاستخدام الإنتاجي، فستحتاج المزيد منها إلى قصص كهذه.</p> <p>المقال الأصلي: <a href="https://devblogs.microsoft.com/agent-framework/fides/">Stop prompt injection from hijacking your agent, new security capabilities now released within Agent Framework</a></p>